I know an LDAP search base suffix generally matches the directory server's host name. In other words, I know if the host name is od.foobar.com
, I should use the search base suffix: dc=od,dc=foorbar,dc=com
It bothers me to not understand why I'm doing this. Could someone provide some background and explain precisely what I'm doing?
Others have explained why using a domain name is a good idea (but is not mandatory). I just add that the question is wrong: having a base suffix based on the name of a machine is not recommended at all (for obvious reasons: what if you replace
gandalf.example.com
bysarouman.example.com
?). You typically only use the delegated domain name so, if you haveexample.com
, you usedc=example,dc=com
.Prior to Microsoft 'embracing, extending, and changing' LDAP, most implementations had objects to represent the root of the tree. I.e. You have to start from somewhere.
For reasons I am not completely clear on, in Active Directory, each Domain in the tree/forest is rooted with a name that dc=domain,dc=com that is not really two separate objects, rather it is a virtual root of the directory name space.
I think that some of it comes from the fact, that regardless of what is said about Active Directory, it is still a series of linked domains, and each domain needs to be treated as a standalone entity.
Now there are automatic transitive trusts within an AD tree, so that makes it matter less to end users, but even though the namespace looks kind of contiguous, it isn't really.
This becomes more evident with some of the naming rules with AD. For example sAMAccountName must be unique within a domain, regardless of whether they are in the same container or not. I.e. The full distinguished name must be unique, (you cannot have two John Smith users in the same container) but the shortname that is used for many things internally (sAMAccountName) needs to be unique within the entire domain.
Other directory services either have somewhat similar requirements, like uniqueID should really be unique within the entire directory, but that is more because applications usually make that assumption, as application writers have been too lazy to deal with the complex issue (I don't blame them, it is a hard problem) of how to handle two users with short names of jsmith trying to use a service, but existing in two different containers. (I.e. Perhaps cn=jsmith,ou=London,dc=acme,dc=com and cn=jsmith,ou=Texas,dc=acme,dc=com).
How should your application using this directory decide which user to use? The usual answer is let the user decide. But that means catching this case, presenting a UI to the user choose from and whatnot.
Most application writers just ignore that possibility and just use uniqueID or sAMAccountName because that is unique (sort of) and easier to do.
The difference between uniqueID and sAMAccountName would be that uniqueID should be unique throughout the directory name space. Whereas sAMAccountName is only guaranteed unique within the domain. If the AD tree has several domains, there is no guarentee there of uniqueness, between domains.
The root of the directory has to be set to something. It could be set to whatever you like. Setting it to the domain name is simply a useful convention that ensures your directory name space is unique.
Short version: Match your domain-name as a guarantee that the base path is unique.
Do it, and you won't look like a newb admin if your company merges with another one, and you need to merge systems :)
Ok, that was a very short version =)