Designing the Active Directory Structure
Designing the Active Directory Structure |
|
In versions of Windows NT previous to Windows 2000, delegation of administration within a domain was limited to the use of built-in local groups, such as the Account Administrators group. These groups had predefined capabilities, and in some cases the capabilities did not fit the needs of a particular situation. As a result, there were situations where administrators in an organization needed high levels of administrative access, such as Domain Administrators rights.
In Windows 2000, delegation of administration is more powerful and flexible. This flexibility is achieved through a combination of organizational units, per-attribute access control, and access control inheritance. Administration can be delegated arbitrarily by granting a set of users the ability to create specific classes of objects, or modify specific attributes on specific classes of objects.
For example, your human resources department can be granted the ability to create user objects in a particular OU, but nowhere else. Helpdesk technicians can be granted the ability to reset the passwords of users in that OU, but not the ability to create users. Other directory administrators can be granted the ability to modify the address book attributes of a user object, but not be allowed to create users or reset passwords.
Delegating administration in your organization has several benefits. Delegating specific rights enables you to minimize the number of users who must have high levels of access. Accidents or mistakes made by an administrator with restricted capability will only have an impact within their area of responsibility. Previously, in your organization it might have been necessary for groups other than IT to submit change requests to high-level administrators, who would make these changes on their behalf. With delegation of administration, you can push responsibility down to the individual groups in your organization and eliminate the overhead of sending requests to high-level administrative groups.
To delegate administration, grant a group specific rights over an OU. To do this, you need to modify the access control list (ACL) of the OU. The access control entries (ACEs) in the ACL of an object determine who can access that object and what kind of access they have. When an object is created in the directory, a default ACL is applied to it. The default ACL is described in the schema definition of the object class.
ACEs can be inherited by child objects of a container object. If any of the child objects are also containers, the ACEs are applied to the children of those containers as well. With inheritance, you can apply a delegated right to an entire subtree of OUs instead of a single OU. You can also block ACE inheritance on an object to prevent ACEs from a parent container from applying to that object or any child objects. Inheritable ACEs only apply within a domain and do not flow down to child domains.
To delegate control over a set of objects in an OU subtree, you edit the ACL on the OU. The easiest way to do this is by using the Delegation of Control wizard in the Microsoft Management Control (MMC) snap-in for Active Directory Users and Groups. To view the ACL on an object or to perform advanced editing of an ACL, use the Security tab on the property page for the object.
Always reference groups in ACLs, not individual users. Managing the membership of a group is simpler than managing an ACL on an OU. When users change roles, it is much easier to discover and change their group memberships than to check the ACLs on every OU. Where possible, delegate to local groups instead of global or universal groups. Unlike global groups, local groups can have members from any trusted domain, making them better suited for granting resource permissions. Unlike universal groups, local group membership is not replicated to the global catalog, making local groups less resource intensive.
The OU structure that you create will depend entirely on how administration is delegated within your organization. Three ways to delegate administration are:
These three dimensions are frequently combined. For example, as shown in Figure 9.13, there can be an administrative group that is responsible for computer account objects in Atlanta for the Automotive business unit.
Figure 9.13 Two-Tiered Delegation
Whether or not the Atlanta OU is the child of the Automotive OU depends on whether the Automotive administrators delegate authority to the Atlanta administrators, or vice versa. It is also possible that the Atlanta administrators are completely autonomous from the Automotive administrators; therefore, the two OUs would be peers.
Note
Some organizations have geographically distributed administrative groups in order to support 24-hour operation. The combined normal work hours of all administrative groups gives the organization 24-hour coverage. In this situation, the scope of each administrative group is not specific to location, because the administrators must be able to assist users all around the world. Even though this scenario has administrators distributed over many locations, it is not an example of location-based delegation.
Starting with the default structure inside a domain, create an OU structure using the following primary steps:
To begin, only domain administrators have full control over all objects. Ideally, domain administrators should only be responsible for:
Domain administrators not only have full control by default, they also have the right to take ownership of any object in the domain. Using this right, domain administrators can gain full control over any object in the domain, regardless of the permissions that have been set on the object.
Only members of the domain administrators group can create additional domain controllers for a domain.
Because domain administrators can have limited and specific duties, the membership of the group can be kept small and controlled.
If you have units in your organization that need to be allowed to determine their own OU structure and their own administrative model, use the following steps:
The Automotive unit of the Reskit company is the result of a merger of two companies, where the Automotive unit retained a fully autonomous IT group. In this situation, the Automotive unit gets its own OU from the root of the domain. Because they are also allowed to define the membership of their administrators group, the group is placed into the Automotive OU. If the Automotive unit itself had completely autonomous operations in Atlanta and Toronto, the Automotive administrators might again create OUs and delegate full control. As shown in Figure 9.14, the Automotive administrators have retained the ability to set the membership of the Atlanta and Toronto administrators groups.
Figure 9.14 Delegating Full Control
If you do not have any units in your organization that need full control, domain administrators will determine the remainder of the OU structure.
Groups with full control can decide if additional OUs are necessary to delegate more restrictive control. A simple way to do this is to consider each object class that will be created in the directory, and determine if management of that object class is delegated further in the organization. Although the schema defines many different kinds of object classes, it is only necessary to consider the object classes that your administrators will create in the Active Directory. At minimum, you should consider:
As you examine each object class, separately consider:
In each case that you decide to delegate control, you will:
Note
To move an object between two OUs, the administrator performing the move must have the ability to create the object in the destination container and to delete the object from the source container. For these reasons, you might want to create a separate group for administrators that can move objects, and grant them the necessary rights on a common parent OU.
The list of objects to be considered can grow as you deploy more Active Directory–aware applications. However, some applications will create objects in the directory that do not require hands-on management. For example, print servers running Windows 2000 automatically publish print queues in the directory. Because the print server takes care of the management of the print queue object, it is not necessary to delegate management to a special administrators group.
By modifying the ACL on the default Computers container, you can delegate the ability to create computer account objects to all users, with no administrative attention required. Computer accounts would be created when users join a computer to a domain in the default Computers container.
The Atlanta location for the Automotive unit of the Reskit company is home to two Windows NT 4.0 resource domains, Powertrain and Chassis. Part of the Windows 2000 migration will involve consolidating those two domains into the noam.reskit.com domain.
The Powertrain and Chassis administrators use the domain today to:
Using delegation of administration, it is simple to replace resource domains with OUs. In this case, groups are created to administer each kind of object, and they are granted full control in a project-specific OU. Project-specific OUs are necessary to prevent Powertrain administrators from being able to manipulate Chassis objects, and vice versa. Figure 9.15 illustrates this concept.
Figure 9.15 Replacing Resource Domains
