Crash Course in Active Directory Organizational Unit Design

In this article the author discusses Active Directory Organizational Unit design and gives tips on the design strategy and how they are best utilized.

Introduction

Active Directory has not changed too much over the years. Since it was first introduced in 2000, the concepts around the organizational structure of Active Directory have not changed. There are still organizational units (OUs) within the Active Directory structure that are used to help administrators…. administer. It has come to my attention that many organizations are deciding to make rash decisions for their OU design in order to attempt efficiency, ease of use, ease of administration, and application of lessons learned. I am the first to admit that some suggestions by Microsoft and Microsoft evangelists don’t hit the mark every time, but in some cases I find that they are perfect and will remain that way until the technology changes to prove it wrong. This is the case with using OUs within Active Directory to the extent for what they are designed for and how they are best utilized.

What is an OU?

An OU is an Active Directory object that is used to organize other objects that are created and contained within the Active Directory infrastructure. OUs are unique from Containers, which are another type of organizational object that is contained within Active Directory. OUs differ from Containers primarily because an OU can have a Group Policy Object (GPO) linked to it, where a Container cannot. This might not sound all that important, but it is paramount.

OUs primarily will be used to organize the following objects:

• User accounts
• Group accounts
• Computers

Yes, OUs can also be used to organize shared folders and printers, but control of these objects within an OU is not all that common or useful for that matter.

OU Defaults

When Active Directory is initially installed there is only one OU. The Default Domain Controllers OU is the only OU that comes as a default. This OU is designed to contain and manage the domain controllers for the domain. The domain administrator can create an unlimited number of OUs for the domain over time, but too many OUs can become cumbersome and cause management issues.

Reasons To Create an OU: Reason #1

The first reason to create an OU is for managing objects. The objects that can be managed include user accounts and group accounts. There is very little that can be managed for a computer or server in an OU, this management must be done at the server itself. Examples of management that can be granted over user accounts and group accounts include:

• Users – Creation, deletion, modification of user properties
• Groups – Creation, deletion, modification of group membership

When an OU is used to grant administrative privileges over an object that is contained with it, this is called delegation. There is a delegation wizard for each OU, shown in Figure 1, as well as an administrator can modify permissions on the OU directly. This latter option is very difficult, as there are approximately 15,000 individual Allow permissions for each OU.

Figure 1: Delegation Wizard for an OU.

Reasons To Create an OU: Reason #2

The second reason to create an OU is to deploy GPO settings. When a GPO is linked to an OU, the settings within the GPO only apply to the objects in that OU and child OUs to that OU. This allows for easy and efficient deployment of GPO settings to only the users and computers that need the settings.

GPOs can be linked to the domain and Active Directory sites, but it is more difficult to manage and configure GPOs deployed at these locations within Active Directory. For efficiency of GPO management, deployment, and troubleshooting, it is suggested to design OUs for the deployment of GPOs.

Designing the OU Structure

When it comes time to design the OU structure, many questions and discussions need to occur. It is far better to design the OU design before implementing the overall Active Directory infrastructure, compared to after Active Directory is up and running in production. Far too often companies feel it is easier to “redesign” Active Directory “again” than do it right the first time.

Things to consider when designing the OU structure include:

• Who will be involved in the administration of users, groups, and computers?
• Will everyone who is responsible for managing users, groups, and computers be in control of all objects, or just a portion of the objects?
• Which user accounts need to have the same settings and which user accounts need to have different settings?
  o   These settings would need to be categorized into categories that make sense for your organization. Categories might include: drive mappings, printer mappings, security configurations, IE settings, application settings, etc.
• Which computer accounts need to have the same settings and which computer accounts need to have different settings?
  o   You should break up servers from desktops before considering these options.
  o   Desktop categories might include: IT, Executives, developers, Finance, HR, HelpDesk, etc.
  o   Server categories might include: DCs, SQL, Web, Intranet, Finance, HR, etc.

How Many OUs?

I receive this question often when considering the Active Directory design. There is no definite answer. The answer lies within your overall goals for Active Directory and how you will manage delegation and GPO deployment. There are really three rules of design, which your organization might develop for OU design.

1. Too few OUs – this is a design that is going to cause a lot of overhead with configurations. If there are too few OUs the delegation model will be very difficult to manage, as all users and groups are in the same OU. In the same light, the GPO management will need to occur within the security filtering that is available for each GPO. This type of management is very difficult to deploy and even more difficult to troubleshoot. Not to mention that managing the GPOs this way will cause additional overhead on the GPO application.
2. Too many OUs – this is a design that is typically a result of bad planning and too many administrators. If you go with the design philosophy of there are only two reasons for an OU, then you can stay clear of this design. However, when the OU structure is used for logical placement of objects and structural design, then it can get out of hand very quickly.
3. Just enough OUs – this is where your organization needs to fall with your OU design. I highly suggest you fall on the “too few OUs” side first, as removing OUs can be difficult.

Summary

OUs for your Active Directory design are essential. If they are not used, the management, efficiency, and troubleshooting of issues that might arise will be more difficult. On the opposite side of the spectrum, if too many OUs are implemented, the same issues will arise with management, efficiency, and troubleshooting. Therefore, falling somewhere in between is key for your OU design. Try not to over think the design, rather logically consider how you want to delegate and how you want to deploy GPOs. Don’t’ forget that some GPO settings (Group Policy Preferences and other GP extensions) allow for linking GPOs high in the structure and still gain efficiency of the GPO application.