It’s tempting just to create an OU structure that is based on geographic locations or on the organizational chart of your IT department. However, using such political bound aries to create an OU structure does not really achieve a design that enhances the administration of Active Directory objects—and easing the administrative burden should be the goal behind your OU design.
Remember that you are not creating an OU structure to make things easier for users or simply to be more organized. You are creating an OU structure to make it easier for administrators to manage the objects placed in those OUs and to make it easier to assign the appropriate permissions to those administrators. Thus, you should create an OU hierarchy that follows the administrative and security needs of the business. Keep the design as simple as possible and use OU names that mean something to the people who will use them—the administrators.
There are two basic OU designs you can use to delegate administration: an object- based design or a task-based design. These designs are covered in the following sections.
Using an Object-Based Design
In an object-based OU structure, shown in Figure 4-1, delegation of control is assigned according to the type of object that is stored in the OUs. You might choose to group OUs around the following types of objects:
■ Users ■ Computers ■ Sites ■ Domains ■ Organizational units Builtin Computers Domain Controllers Users Accounts Domain User Accounts Admin Accounts Groups
Delegate the administration of objects within the OU to a specific individual or group by using the following general steps:
1. Place the individual or group that needs administrative rights into a security group (see Lesson 2 for more on using security groups).
2. Place the set of objects to be controlled into an OU.
3. Delegate the administrative tasks for the OU to the group you configured in step 1. Using a Task-Based Control Design
In a task-based design, delegation of control is assigned based on the administrative tasks that need to be accomplished instead of being based on the objects that need administration. Such tasks include:
■ Creating, deleting, and modifying user accounts ■ Resetting passwords
■ Defining group policy
■ Controlling group membership and permissions Planning the OU Structure
Active Directory directory service lets you control the delegation of administrative tasks to a precise level. For example, you could assign one group full control of all objects in an OU. You could then give another group the rights only to create, delete, and manage a certain type of object in the OU. You could then give another group the right to control a certain attribute of a certain type of object (such as the ability to reset pass- words for user accounts). You can also make these permissions inheritable so that they apply not only to a single OU, but also to any lower-level OUs that are created. This granularity of control allows a great degree of flexibility.
If you choose an object-based OU structure, this means you can place all the objects of a certain type into the same container. You can then assign a fairly complex set of administrative permissions on the OU that control what each administrator can do. You can then create lower-level OUs that control Group Policy application or perform some other task, yet still have the same permissions structure inherited by the lower-level OUs. An example of a structure like this one is shown in Figure 4-2.
Domain Builtin Computers Domain Controllers Users Accounts User Accounts Admin Accounts Groups
Figure 4-2 You can create complex permissions for a relatively simple OU structure.
A well-designed OU structure allows administrators to delegate authority effectively. You should give careful consideration to the top-level OUs in a structure. Top-level OUs should always be based on a relatively static aspect of the organization to prevent the need to change the top-level OUs during a reorganization of the company. For example, the following types of top-level organization are based on static aspects that are less likely to change:
■ Physical locations Often, different physical locations (especially those over a wide area such as different countries) have different IT staffs and, therefore, dif ferent administrative needs. Creating a separate top-level OU for each location is really an application of a task-based design; it’s just that the different administra tive tasks are based on location, as shown in Figure 4-3.
■ Types of administrative tasks Basing the top-level structure on administrative tasks ensures a relatively static structure. No matter how your company might reorganize itself, the basic types of administrative tasks are unlikely to change much.
■ Types of objects As with a task-based structure, basing your top-level OUs on types of objects ensures a plan that is resistant to change.
Group Control Objects
Domain Full Admins User Full Objects Admins Group Full Objects Admins All User Group
Builtin Computers Domain Controllers Users Dallas Memphis Portland
Figure 4-3 Administrative tasks are based on location in this top-level OU design.
Each of these options represents a better top-level OU structure than, for example, bas ing OUs on divisions of the company, which are more likely to change.
When planning the top-level OU structure in a multidomain environment, consider cre ating a top-level design that is consistent across every domain on the network. Using an object-based or task-based design (described in the next sections) is particularly effective in this situation. Creating a top-level OU structure that is consistent across domains keeps administration and support consistent throughout the network.
Lower-level OUs (those created inside the top-level OUs) should represent more detailed levels of administrative authority within your organization or should be used for other purposes such as Group Policy application. Remember that by default, lower- level OUs inherit the permissions of their parent OUs. When you are constructing your plan, you also need to plan where you want inheritance to happen and where you don’t.
When designing lower-level OUs, it’s easy to get carried away. Remember that your main goal is to design a structure that simplifies the administration of accounts and resources as much as possible. To this end, keep your design as simple as possible. If you create a nested OU structure that is too deep, you not only create a more confus ing structure, but also may reduce performance. An OU may have multiple levels of Group Policy being applied to it—from the domain, site, and any parent OUs. The more policies that need to be applied, the longer the response time and the slower the perceived performance.
Exam Tip Initially, you should create an OU structure that effectively enables delegation of administration, whether you create an object-based or a task-based design. Once you have completed this initial OU design, you should then create additional OU structures to control the application of Group Policy to users and computers and to limit the visibility of objects.