Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm looking for guidance in structuring an LDS directory and finding only best practices targeted at Domain Services. Does anyone here have references for the hierarchical structure we set up in the directory?

I'm interested in small items, like whether to name the top node with "DC" tags or "O" tags, etc. E.g., should it be "DC=CompanyName,DC=local" when we're not actually using any specific domain? Shouldn't it be "O=CompanyName"? And I'm interested in whether this question is even worth considering.

share|improve this question

closed as not constructive by Brent Pabst, MDMarra, Michael Hampton, pauska, dunxd Sep 20 '12 at 10:53

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

2 Answers

I usually use only DC tags for the root DN. For example:

DC=something,DC=example,DC=COM

I also match part of the root with the domain (in this case, it would be example.com). It is just a habit, it will not help or hinder your ability to use proxy accounts, for example.

Every LDAP enabled product I can think of allows you to specify the full DN of the path were your users are located. So the components you use don't matter as much as the structure itself (called the Directory Information Tree or DIT). You basically have to balance two things :

  • A flat structure is future proof
  • A deeply nested structure allows greater control (delegation, segregation of users)

A flat DIT, where for example all users would be under :

OU=Users,DC=something,DC=example,DC=COM

Will fit whatever organisational structure you have to work against. But you will sacrifice some ability to segregate users between applications using your LDS.

Here is an example. If you have two applications, you could have :

OU=Application_A,OU=Users,DC=something,DC=example,DC=COM
OU=Application_B,OU=Users,DC=something,DC=example,DC=COM

But what will happen if a user from Application_A wants to use Application_B ? Same goes for groups :

OU=Groups_A,OU=Users,DC=something,DC=example,DC=COM
OU=Groups_B,OU=Users,DC=something,DC=example,DC=COM

In short, don't worry about components, but give some thought about how well your DIT will fit in different reuse scenario.

share|improve this answer
add comment

To understand the difference between dc= and o= in Active Directory you need to remember that Active Directory is an LDAP implementation at its core.

DC= in LDAP parlance specifies a Domain Component. It should be used if and only if you are defining something that exists within the DNS space.
If your organization is foobarco.example.com in DNS it is perfectly legitimate to use dc=foobarco,dc=example,dc=com as your root.

O= in LDAP parlance specifies an Organization. It should be used when defining an organizational item which exists outside of other hierarchies like DNS.
For example if foobarco.example.com had a subsidiary company called Shiny Widgets with its own AD domain, but not its own DNS domain, you would root that tree at o=ShinyWidgets,dc=foobarco,dc=example,dc=com.


Generally it is assumed that an AD Domain will have a corresponding DNS namespace, so the most common configuration you will see with Active Directory is that the tree root will be defined by a series of Domain Components.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.