When to Use OUs

Deciding when to use OUs in your hierarchy design is the first step in determining your Active Directory structure. Chapter 11 discussed that OUs should be used to map the actual organizational structure rather than simply as a way to segment objects for administration. This chapter examines when you should create a new OU and when you should create a new domain instead in closer detail.

The typical reason that the inexperienced Active Directory administrator creates an OU is for delegation of administrative authority. This is because under Windows NT version 4.0 and earlier, it was necessary to create a completely new domain truly delegate administrative authority. Now with the new concept of an OU, many administrators are tempted to pile OU on top of OU within a single domain to subdivide and distribute the administration of objects. It is critical that this not be the starting point for an administrator designing an Active Directory hierarchy.

Delegation of Administration

Delegation of administration should not be the primary motivating factor for segmenting the Active Directory hierarchy into multiple OUs. If that is the case, then what administration strategy should be used to delegate authority within an Active Directory hierarchy that has multiple administration requirements?

The starting point for defining an administration strategy for the delegation of authority should be the existing administration strategies for the organization. If your current company administration paradigm is one of distribution versus centralization, then that is where the design of the Active Directory hierarchy should start. However, that is only where it should start. The design process should continue with a critical examination of the existing administration configuration to ensure that it still meets the needs of the organization. Administration might currently be distributed to subsidiary organizations because that was the only model that could be supported under Windows NT 4.0. Now, with Windows 2000, it is possible to support a truly centralized model.

When examining your administrative model, it is important to consider the following:

• Identify all the administrative tasks that current system administrators carry out in all the different parts of the organization.

• Map the existing administrative tasks to the new functionality and, consequently, to the new administration tasks under Windows 2000.

• Identify which tasks will change with the implementation of Windows 2000 and Active Directory.

• Re-examine the administrative model to make sure that it still meets the needs of the organization.

For example, your organization might currently have a set of administrators who perform the task of creating new user accounts on the network and creating new mailboxes in Exchange. They are administrators for both the network and the Exchange environment. The administration model was set up this way because under Windows NT 4.0 and Exchange 5.5 it was easier to have mail administrators also be account administrators, so that they could create both the NOS account and the Exchange mailbox. Now, with Active Directory, it is possible to provide mail administrators with the ability to create user accounts in specific user OUs without providing them with complete administrative control of the domain.

In Active Directory, users, security groups, computers, and resources registered in the directory are referred to as security principles. (Please refer to Chapter 15, "Developing a Network Security Strategy," for a discussion of security principles and Kerberos.) Access control permissions can be granted and assigned to security principles. In this way, it is possible to restrict administrative control over specific objects in the directory without establishing multiple levels of OUs in which to store the security principles. However, this obviously is a tedious way to administer an environment if there are multiple security and administration policies to be applied to a wide number of security principles.

Consequently, OUs should be utilized for the segmentation of administration of security principles when there are a large number of individual user objects in the directory, and they require a diverse set of security policies for operation.

First-Level OUs

First-level OUs should be utilized for segmenting security principles and group policies in to units that are relatively static with regards to business requirements and administration requirements. As discussed in Chapter 11, first-level OUs can be based on the geographic segmentation of the organization in which Active Directory is being implemented. First-level OUs can also be based on organizational segmentation.

Design considerations for first-level OUs should center on how to apply administrative policy to the Active Directory hierarchy. If every user in the organization were to have the same access and administrative requirements, there would be little need for a segmented hierarchy with multiple first-level OUs. Because this is rarely the case, the reality is that there are multiple first-level OUs created for most organizations. First-level OUs should be utilized as home containers for most organization-wide group policies. It is possible to significantly reduce administrative overhead by establishing as many organization-wide group policies at the first-level of the hierarchy and enabling inheritance on second- and third-level OUs.

To establish your first-level OU structure, consider the following process:

While planning your OU structure, it is important to note that OUs have no specific visible impact on users. OUs are exposed to users for browsing, but browsing should not be a design consideration when developing an Active Directory hierarchy. The OU structure is not exposed in the result set from query to Active Directory, by default. Furthermore, OUs are not exposed as part of the domain name system (DNS) service providing name resolution for Active Directory.

Second-Level OUs

Second-level OUs should be used if it is necessary to segment resources, including both users and computers, into groups that are more granular than those implied by the delegation of security and administration discussed in the previous section. This might be required by the structure of the organization. For example, all the sales force might have the same security policies applied and they might conform to the same security model, but it might be necessary to isolate different sales groups based on geography.