[Date Prev][Date Next]
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:
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...)
- The RootDN
- From: Joseph D Carroll Jr <email@example.com>