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
Estimated lesson time: 45 minutes
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.
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:
As an alternative, you can manually delegate permissions from the Advanced option on any Active Directory container's Security tab.
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
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.
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
Figure 2.7 Delegate administrative control higher in the OU hierarchy
Combining these four factors will lead you to an OU structure that supports your delegation requirements.
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.
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.
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:
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.
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.
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.
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.
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.
Your OU design should meet the following Group Policy requirements to assist in troubleshooting Group Policy application problems:
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.
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.
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.