I am relatively new to LDAP, and have seen two types of examples of how to set up your structure.
One method is to have the base being: dc=example,dc=com
while other examples have the base being o=Example
. Continuing along, you can have a group looking like:
dn: cn=team,ou=Group,dc=example,dc=com cn: team objectClass: posixGroup memberUid: user1 memberUid: user2
... or using the "O" style:
dn: cn=team, o=Example objectClass: posixGroup memberUid: user1 memberUid: user2
My questions are:
- Are there any best practices that dictate using one method over the other?
- Is it just a matter of preference which style you use?
- Are there any advantages to using one over the other?
- Is one method the old style, and one the new-and-improved version?
So far, I have gone with the dc=example,dc=com
style. Any advice the community could give on the matter would be greatly appreciated.
The
dc
style generally indicates a dns-based LDAP tree of some kind. This is the style Active Directory (AD) uses. If you don't care about dns-based LDAP trees, then other types can be used just fine. Novell's eDirectory is anO
based tree. Some caveats:O
based trees. I've had trouble getting these clients to talk to O-style LDAP trees.O
at all, so some LDAP clients/parsers may not support it as a result. The same goes forL
(location).dc=example,dc=com
, and you use an O-style tree under that. DN's could very well be,cn=bobs,ou=users,o=company,dc=example,dc=com
In general, your need to be compatible with 3rd party LDAP client is what should drive your structure. If it needs a dialect, it'll probably need to look as active-directory like as possible. If they're pure LDAP clients, in that they really do support the entire spec, then structure shouldn't matter.
I don't know of any ldap tree-structure standards, but I'm sure others will pipe up if there are any.