[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: The RootDN

On Wed, 28 Aug 2013, Joseph D Carroll Jr wrote:
articles, even much of the Zytrax book, and I still cannot figure out what this rootdn is. 

IMO best definition is the slapd.conf(5) man page:

       rootdn <dn>
Specify the distinguished name that is not subject to access control or administrative limit restrictions for operations on this database. This DN may or may not be associated with an entry. An empty root DN (the default) specifies no root access is to be granted. It is recommended that the rootdn only be specified when needed (such as when initially populating a database). If the rootdn is within a namingContext (suffix) of the database, a simple bind password may also be provided using the rootpw directive. Many optional features, including syncrepl, require the rootdn to be defined for the database.
If any of that could be clarified, we'd like to hear about potential doc improvements. I know that there are references to OpenLDAP terms; however those are defined elsewhere in that man page or others. Some of the non-OpenLDAP terms (like "distinguished name") you'll learn about in docs like RFC4512 and its references. All of them are sitting in the doc/ directory of your source tree, no need to go hunting.
You can also find some English explanations relating to the rootdn in the OpenLDAP Quick Start Guide and section 8 ("Access Control") of the OpenLDAP 2.4 Administrator's guide.
I get that it is a user, so maybe better stated, I don't understand where the user exists.  Is it an OS user with filesystem privileges? Is it a user that exists in every DIT? If so, when/where is it used, can you have multiple, is it only usuable/accesible when you "include" the core.schema, .. ?
OpenLDAP Software imposes no realistic constraints between any of its entries and the underlying OS users/filesystem (perhaps one could come up with some rare ACL/domain socket examples, but even those are administrator-configured, not a software restriction).
In the slapd.conf(5) man page, it's noted that "Options in this section only apply to the configuration file section for the database in which they are defined." So you get one rootdn definition per database. And the scope, as written in the description quoted above, is (unsurprisingly) "operations on this database." You can configure multiple databases, therefore you can have multiple rootdns. 


If I had to guess, I would say:
  - A rootdn exists in the DIT as a completely arbitrary user (absolutely no relation to the OS)
  - There can only be one rootdn per DIT
  - (Consquently) If a parent defines a rootdn, any referral cannot
  - The rootdn is used for some kind of system action (who knows what)
The rootdn is entirely locally processed; any references to referrals or anything else involving other servers are out of scope.
I know this is the "technical" forum, but I am more so interested in the "why to's" and "reasons behind" than the "how to's". 

Just as a couple motivating examples:
* you're starting slapd(8) from scratch, day zero. You need to populate it, with its very first entry. How do you get that in there? You can use slapadd(8) offline but that doesn't perform the full weight of schema enforcement, etc. You put the first entry in with ldapadd(1) and your rootdn/rootpw, and you have that protection available. (And if it's the first LDIF you ever wrote in your life, you probably want those checks!)
* you're using back-config to modify the configuration hot, and misconfigure an ACL. Or maybe you accidently modified an admin/manager userPassword. With a rootpw you might have a last-ditch back door into the system to put things back as intended. Without it, you're probably back to slapcat/$EDITOR/slapadd, and the slapadd has to be done cold. Which one of these is the more acceptable situation depends on your local site and risk tolerance. (Of course "just get it right the first time" is ideal but...)