Lesson 3: Designing an OU Structure | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

Within every domain in your forest you must create an OU structure. This OU structure must provide the framework for delegating administration to portions of your Active Directory. It also must provide the necessary structure to allow Group Policy deployment.

After this lesson, you will be able to

Design an OU structure that meets both delegation of administration and group policy deployment needs for your organization

Estimated lesson time: 45 minutes

Planning for Delegation of Administration

One of the more common Active Directory designs is based on the capability of delegating administration to specific organizational units, to specific objects within an OU, or to specific attributes of an object.

The ability to delegate administration is a major enhancement to Windows 2000. In previous versions of Windows NT, you had to delegate administration by creating a resource domain, selecting those users you wished to delegate administrative responsibilities to, and making them administrators of the resource domain. This often led to the assigning of excessive user rights to these resource domain administrators and the creation of excess resource domains to allow for delegated administration.

Delegating Control to an Organizational Unit

In Windows 2000, you can delegate administration to a specific OU by using the Delegation of Control Wizard.

The Delegation of Control Wizard allows you to delegate management of Active Directory objects to a user or security group that isn't explicitly a member of the Administrators local group. You access the Delegation of Control Wizard by right-clicking a container in Active Directory Users And Computers and selecting Delegate Control, as shown in Figure 2.5.

Figure 2.5 Accessing the Delegation of Control Wizard

The Delegation of Control Wizard allows you to set the following default options:

Users Or Groups. You can select which users or groups will be delegated administrative control over the container you're delegating control to.
Tasks To Delegate. You can select from a list of common tasks that include management of user accounts, resetting passwords, reading user information, managing groups, modifying membership of groups, and managing Group Policy links. Or you can select to create custom tasks for delegation.
Custom Tasks. If you select custom tasks for delegation, you can choose to delegate full control of all objects in the folder or specifically reference the object classes that the user or security group can manage.
Custom Permissions. If custom tasks are selected, you can then define the permissions that will be delegated to the user or security group selected.

As an alternative, you can manually delegate permissions from the Advanced option on any Active Directory container's Security tab.

TIP
The Security tab is available only when Advanced Features are enabled in Active Directory Users And Computers.

In the Permission Entry dialog box, shown in Figure 2.6, you can then configure custom permissions for the container. You can apply the custom permissions to the container and to all child objects, to just the container, or only to specific objects that exist in the container.

Figure 2.6 Assigning custom permissions for delegation of control

Making the Decision

When it actually comes time to create your delegation of administration design, you must ensure that only the minimum rights are delegated to the selected security principals.

You can test your design by delegating the desired permissions to an empty security group. You can then create a new user account that's only a member of the newly created security group. When logged on as the newly created user, be sure to attempt not only the tasks that you want the delegated administrator to perform, but also tasks that you don't want the delegated administrator to perform. This ensures that only the correct permissions are delegated.

To ensure that only approved management functions take place, it's recommended that you configure the audit policy to audit success and failures for account management. Because the OUs are stored on DCs, you should configure these audit settings on the Default Domain Controllers policy (assuming that all DCs remain in the OU). The audit policy is applied to the computers located within the OU where the Group Policy object is applied.

NOTE
For more information on configuring auditing, see Lesson 4: Designing an Audit Strategy, later in this chapter.

Delegation of administration requires you to give careful thought to which rights to delegate to specific users or groups. With Windows 2000 you don't have to assign rights based on all encompassing groups, such as Account Operators or Server Operators. Your delegation of administration design must include

Which users should have administration privileges delegated to them. Be sure to select only the users that require delegated user rights for delegation. The best strategy is to create a separate security group and delegate the permissions directly to that group rather than to assign the permissions directly to a user. That way, if the role of a user changes, you have to change only the membership of the security group, not the delegated permissions on the OU.
Where to delegate administration in the OU hierarchy. It's often best to delegate control higher in the OU hierarchy. This reduces the number of places in which delegation must take place. For example, if the security group Marketing Admins requires the ability to manage users in the Marketing OU, the USA OU, and the Canada OU, as shown in Figure 2.7, it's more efficient to delegate administration of user accounts to the Marketing Admins group at the Marketing OU, rather than individually at each of the three OUs.

Figure 2.7 Delegate administrative control higher in the OU hierarchy
Which types of objects should be delegated for administration. Delegated administration is often only required for a specific class of objects. Rather than delegating full control of all classes of objects, limit delegation to the classes of objects that the delegated user will manage. For example, if the delegation is simply to manage the membership of group accounts, don't delegate administrative privileges for user accounts to that user or group.
The minimum set of rights that are required. Although the Delegation of Control Wizard allows delegation to administration based on an entire object, the best solution often is to provide administration rights to only a subset of attributes for an object. For example, the Helpdesk security group may require only the ability to reset a user's password. By delegating only the ability to reset the password for user accounts to the Helpdesk group, you ensure that excess privileges aren't delegated on the network.

Combining these four factors will lead you to an OU structure that supports your delegation requirements.

Applying the Decision

Wide World Importers wants to create an OU structure for the Engineering domain that will allow each distribution center's Engineering department to nominate an engineer to manage the user accounts. The nominated manager will also be responsible for maintaining group memberships of the Engineering user accounts for her distribution center.

At the head office in Washington, the head of the IT department for engineers, Kim Abercrombie, is required to manage all Engineering accounts within the domain. This will allow her to disable accounts when necessary without having to contact an IT administrator at each distribution center.

Based on these criteria, you could create the OU structure shown in Figure 2.8 for the Engineering department within the engineering.wideworldimporters.tld domain.

Figure 2.8 Proposed OU structure for the Engineering department

This OU facilitates the delegation of authority that the Engineering department needs. For the Engineering Users OU, a domain local group can be given the ability to manage all user accounts. The head of the IT department for engineers can be made a member of this group in order to manage the users. Because delegation of authority is inherited by default, the head of the Engineering IT department will be able to manage all user accounts in the Engineering department.

Likewise, you can delegate user account administration to separate domain local groups for each distribution center OU. You can make the nominated engineers at the distribution centers members of the domain local group so that they are limited to managing user accounts from their own distribution center.

This design is based on an OU structure that facilitates delegation of administration.

Planning for Group Policy Deployment

Another factor that affects your organizational unit design is planning for the deployment of Group Policy. Group Policy can be applied to local computers, sites, domains, and OUs, as shown in Figure 2.9.

click to view at full size.

Figure 2.9 Applying Group Policy in a specific order to arrive at the effective policy

Group Policy is always processed in a specific order:

If local policy is defined at the Windows 2000 computer, that local policy is applied.
If any site policies are defined, they're applied to the object.
If any domain policies are defined, they're applied to the object.
If any top level OU policies are defined, they're applied to the object.
If any child OU policies exist, they're applied until the OU where the object exists is located.

You can configure Group Policy settings for both users and computers. When you design your OU structure, you may arrive at an OU structure that ultimately puts computers and users in separate OUs.

By default, Group Policy is inherited. If a policy is defined at the domain level, all OUs under that domain will have the Group Policy setting applied, unless the Group Policy setting is defined in an OU closer to the user that overrides the previous setting. Likewise, a Group Policy setting defined at a parent OU will be inherited by child OUs in the OU hierarchy, as shown in Figure 2.10.

click to view at full size.

Figure 2.10 Group Policies inherited by child OUs by default

If you defined the security option as not displaying the last user name in the logon screen at the nwtraders.tld domain, Group Policy inheritance would assure that this setting is inherited by all computers within the Marketing, Canada, and USA OUs. The only case where they wouldn't be inherited is if the Do Not Display Last User Name In Logon Screen policy was disabled at one of the OUs closer to the user account.

TIP
While Group Policy settings are inherited within a domain, they aren't inherited between domains. If a Group Policy is defined at the forest root domain, it isn't inherited by child domains created below the forest root. A domain can inherit only site Group Policy settings.

In some cases it may be desirable to prevent the default inheritance of Group Policy. In Figure 2.9, we saw that all of the OUs in the nwtraders.tld domain inherited the Group Policy Do Not Display Last User Name In Logon Screen. It's possible to block the inheritance of a Group Policy from a parent container by configuring the Block Policy Inheritance option within the Group Policy Properties page tab, as shown in Figure 2.11.

Figure 2.11 Configuring block policy inheritance at the OU level

Blocking inheritance will prevent Group Policy settings defined in parent containers from being applied at child containers. For example, if the Canada OU blocked policy inheritance, the Do Not Display Last User Name In Logon Screen policy wouldn't be enabled for any computers in the Canada OU.

Some administrators may not appreciate these settings being blocked at lower-level OUs. This is especially true for policy settings applied at the domain level that are intended to affect all computers in the domain. In this case it's possible for a higher-level policy to prevent lower-level Group Policy objects from overriding the policies defined at higher levels of the Active Directory structure by enabling the No Override option, as shown in Figure 2.12.

Figure 2.12 The No Override option prevents lower-level OUs from blocking inheritance

If both the No Override and Block Policy Inheritance settings are selected, the No Override option takes precedence.

TIP
Always try to design your OU structure so that blocking policy inheritance isn't required. The use of blocking policy inheritance makes it very difficult for administrators to troubleshoot Group Policy application errors.

The final option that you can use to further configure which Group Policy is applied to objects within a container is to apply filtering to Group Policy. Filtering allows you to limit the application of a Group Policy to specific Windows 2000 security groups. You do this in the Security tab of the Group Policy object, as shown in Figure 2.13.

Figure 2.13 You can filter Group Policy so that the policy is only applied to specific security groups

To apply the Group Policy, you must assign the security group two specific permissions: Read and Apply Group Policy. The Read permission allows the members of the security group to read the properties and settings of the Group Policy object, and the Apply Group Policy permission indicates that those properties and settings will be applied to the security group.

TIP
When you're troubleshooting Group Policy application problems, you can use the Microsoft Windows 2000 Server Resource Kit tool Gpresult.exe to determine exactly which Group Policies are being applied to a specific computer and user account. This will limit the troubleshooting to the Group Policies that were actually applied to the user or computer object.

Making the Decision

Your OU design should meet the following Group Policy requirements to assist in troubleshooting Group Policy application problems:

Create an OU structure that doesn't require blocking inheritance. When Group Policy inheritance is blocked, the default application model for Group Policy doesn't take place. This makes it difficult to troubleshoot Group Policy applications and may require tools such as Gpresult.exe from the Microsoft Windows 2000 Server Resource Kit for resolution.
Limit the use of Site Group Policies in a multiple-domain environment. Site Group Policies are stored in the domain where the Site Group Policy was defined. This can result in a user or computer having to contact a remote DC to load the Site Group Policy, and this can cause slower authentication to the network.
Limit the number of levels where Group Policy is applied in order to increase logon performance. The number of OU levels doesn't affect logon performance; rather, it's the number of OUs where Group Policy is applied. If too many Group Policy objects are defined, the time to authenticate with the network can be lengthy as each Group Policy is downloaded to the computer.
Apply only the necessary settings. When you design your Group Policy objects, you should prevent user settings from being applied if the Group Policy object is only supposed to apply computer settings. Applying both computer and user settings when only computer settings are required increases processing time and prevents extraneous information from accidentally being added to the Group Policy.

Applying the Decision

Two requirements make it necessary for you to configure Group Policy: the deployment of software for users and the deployment of consistent security configuration for all computers.

To facilitate the deployment of the security templates, you need to create an OU structure that groups the computers into OUs based on security templates. You will create separate OUs for each security template that must be applied as shown in Figure 2.14.

Figure 2.14 Proposed OU Structure for the deployment of security templates

Domain controllers will be located in the Domain Controllers OU. A separate OU for all other computers named Wide World Importers Computers will contain two sub-OUs: Workstations and Servers. This configuration will allow the deployment of the three security templates with the least amount of configuration. The Basicdc.inf template would be deployed at the Domain Controllers OU. The Basicwk.inf would be deployed at the Workstations OU. Finally, the Basicsv.inf template would be deployed at the Servers OU.

To facilitate the deployment of applications, you must define only a single OU. In Figure 2.15, this OU is located directly below the domain, but in reality it can be anywhere within the OU structure.

Figure 2.15 Proposed OU Structure for the deployment of applications

The Accounting users OU would contain all of the Accounting department user accounts. For this OU you can define a Group Policy object that assigns the Accounting software to all user accounts within the OU.

For the distribution of Office 2000, you can deploy this at the domain Group Policy object. This will ensure that all users in the domain will have the software assigned to their user accounts.

NOTE
A Group Policy object cannot be defined for the Users container because the Users container is not an OU. Group Policy objects can be defined for domains, sites, and OUs, but not for container objects.

Lesson Summary

Designing an OU structure takes a long time. The design must allow for both delegation of administration and deployment of Group Policy. Be aware that the process is lengthy and that you must test it before deploying it.