LDAP Structure: dc=example,dc=com vs o=Example

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:

1. Are there any best practices that dictate using one method over the other?
2. Is it just a matter of preference which style you use?
3. Are there any advantages to using one over the other?
4. 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.

Solution 1:

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 an O based tree. Some caveats:

• DC-style is what AD uses. A lot of 3rd party products that support AD LDAP sources like this style of tree a lot better than O based trees. I've had trouble getting these clients to talk to O-style LDAP trees.
• AD doesn't use O at all, so some LDAP clients/parsers may not support it as a result. The same goes for L (location).
• If you're not DNS-rooting your tree, DC-style is much less important
• Hybrid styles are just fine. Your LDAP root is 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.