In the previous post in this series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, I looked at forest and domain design. This post continues with a look at organizational unit (OU) structure.
The OU structure is not exposed to users but can make a big difference to the management of Active Directory objects. It is very flexible and therefore easy to change but change costs money and has a potential to impact on production applications (so should be avoided where possible.
Consequently, there are a couple of guiding principles to be followed:
- Design the OU structure for the delegation of administrative responsibility.
- Design the OU structure for group policy object (GPO) application.
Delegation of administration should be given priority, because GPO application can also be filtered using security groups, but Microsoft does also recommend the following:
- Do not move domain controllers out of their own OU (some applications may rely on well-known GUIDs and default GPOs).
- Do not move built-in users and groups from the Users container (due to the potential impact on the monitoring of ACL changes using AdminSDHolder – see Microsoft knowledge based article 232199).
- If Windows Server 2008 is being used protect OUs from accidental deletion (this will be enabled for new OUs but not for legacy OUs from an in-place upgrade.
There is no “correct” way to design an OU structure – as the appropriate model varies from organisation to organisation but one approach to OU design is to base the top level OUs on the object type and then subdivide by role. Another approach is a geographic top level (countries do not change very often…) but the most important point is to follow an appropriate administrative model and where different objects are managed by different administrative teams, consider delegation. One thing that is almost universally agreed upon is not to replicate the organisational structure – security groups can be used for this (and are much easier to manage – e.g. for filtering GPO application).
In the next post in this series, I’ll take a look at design considerations for group policy objects.