UPCOMING versions of many Microsoft products such as Exchange Server, Site Server, and SQL Server will rely on Active Directory (AD) instead of standalone directories. This shift will force many enterprises to deploy an AD infrastructure, thus creating the challenges of planning an AD implementation and managing it to meet the many needs of users and applications.
One of AD's most important features—its ability to support delegated administration of directory objects to groups of specified users—requires you to understand AD security and the complexities of managing permissions in AD. You also need to understand the AD ACL Editor and the Delegation of Control Wizard, and you need to be aware of the challenges and pitfalls you'll likely encounter as you devise your AD delegation strategy.
AD Concepts and Definitions
Objects and their attributes make up AD. For example, a user object has attributes such as First Name and Address, and an organizational unit (OU) object has attributes such as Description and Address. AD lets you set permissions for entire objects and individual attributes of objects. This granularity allows a variety of possibilities when you assign permissions for your objects. Moreover, each object class can have a different set of security rights. If an application adds a new object class or attribute and extends the AD schema, the schema extension might require additional security rights. Security rights are the types of operations (e.g., read, write, delete) that you permit for a particular object. Nineteen standard security rights are available within AD, and an object class can have any number of extended rights that are specific to that class. For example, the right Create Site Link Objects is relevant and applicable only to classes of objects that can contain site links.
Establishing permissions for objects and their attributes is at the heart of AD delegation. You use the AD security model to control who can make changes to certain objects. To manage delegation within AD, you need to become proficient with the Windows 2000 ACL Editor.
Each object in AD has an ACL that contains access control entries. ACEs are composed of rights or permissions that apply to an object or attribute. An AD object stores its ACL in the ntSecurityDescriptor attribute. ntSecurityDescriptor usually isn't visible when you use typical AD administrative tools to view objects.
You can use the ACL Editor to view objects' ACLs. Some documentation distinguishes between a discretionary access control list (DACL) and a System Access Control List (SACL). You can define DACLs to control who has access to an object and the level of access that users have. An SACL defines a list of users whose access to an object will raise an audit event. AD supports using SACLs to audit object access.
Every object class in the AD schema contains a default ACL, which resides in the object class' DefaultSecurityDescriptor attribute. If a newly created AD object doesn't inherit permissions from a parent object or receive permissions from another source, it will receive an ACL based on the DefaultSecurityDescriptor attribute.
The process of defining AD ACLs gives you more flexibility than file-system permission procedures do. When you add an ACE for a particular user group to an AD object, you decide which rights to allow and deny, and you also decide the scope of those rights. A right can apply to the entire object or only to an object's individual attributes. The object and the object's attributes can have different sets of rights. For example, if you're setting security for an OU, you'll have the option to grant rights such as Create Printer Objects and Delete Computer Objects. However, if you're setting security on the OU's particular attributes, then you'll have the option to set simple read or write access to each attribute. Figure 1 shows permissions, such as Read countryCode, for the Finance OU object.
You can also control the scope of the security changes. For example, Figure 1 shows an Apply onto drop-down list, which lets you choose the type of object that the ACE applies to. You can apply the ACE to only this OU, to all objects within this OU (including other OUs, groups, and users), or to individual types of objects within the OU (e.g., computers, users). If you're not careful, you can create a complicated web of permissions by using this level of AD security control.
Inheritance
AD supports an inheritance model similar to Win2K's NTFS 5.0 (NTFS5) file system. If you enable inheritance, newly created objects will inherit permissions from parent objects. If you've defined permissions for the entire domain (i.e., at the AD domain level) and you create a new OU within the domain, the OU inherits the permissions you've defined at the domain level. Inheritance is powerful because it lets you control who can do what within your AD infrastructure as the infrastructure expands. When you're working in the ACL Editor, you can easily tell which ACEs are inherited from a parent object. Inherited ACEs appear gray, and you can't modify them unless you disable inheritance.
You can disable inheritance from either the child object or the parent. To disable inheritance, open the ACL Editor on an AD object, then clear the Allow inheritable permissions from parent to propagate to this object check box. After you click OK, a Security dialog box appears. If you decide that a particular object won't inherit permissions from the parent domain, you can either copy or remove inherited permissions. If you choose Copy, all existing inherited ACEs on the object are copied to the object; you can then modify those permissions because they're no longer inherited. If you select Remove, all inherited ACEs are removed from the object and only the ACEs that you specifically defined on the object will remain.
To control permissions that flow from parent objects to child objects, open Properties on a parent object's ACE. This dialog box contains the Apply these permissions to objects and/or containers within this container only check box. If you select this check box, the ACE will propagate only to objects or containers within the current container and won't replicate downward into subcontainers.
For example, suppose your company's Finance OU contains a sub-OU called Accounting. You want to delegate the rights to create and delete computer objects within the Finance OU to an administrative group, Finance Admins, but you don't want Finance Admins to have the same right within the Accounting OU. Typical inheritance would cause the ACE that you define for the Finance OU to flow down into the Accounting OU. To prevent that typical inheritance, create the appropriate ACE for the Finance OU, set the Apply onto drop-down list to Computer Objects, and select Apply these permissions to objects and/or containers within this container only. As a result, the Finance Admins group will have control over only computer objects within the Finance OU.
The ACL Editor
If you work with the ACL Editor, you're likely to encounter some quirks in its operation. Win2K's AD ACL Editor isn't Microsoft's friendliest interface.
To open the ACL Editor from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in menu, select View, Advanced Features. Then, right-click an object, choose Properties from the context menu, and click the Security tab, which Figure 2 shows. When you open the ACL Editor, you'll notice that you can't scroll horizontally through security group names or usernames that appear in the upper window. If a name is wider than the window, you can't scroll to the right to see the rest of the name. You'll need to work around this quirk.
In the Permissions window are sets of standard security rights that are available for the object that you're highlighting. If you're highlighting an OU, these rights are Full Control, Read, Write, Create All Child Objects, and Delete All Child Objects. If you're highlighting the domain, a user object, or a computer object, a longer list of different standard rights appears. If you're assigning basic access to an object, you never need to stray from the ACL Editor's first page. However, when you need to do more than the basics, click Advanced, which produces the Access Control Settings dialog box that Figure 3 shows.
From this dialog box, you can perform several tasks. You can set auditing for an AD object. If you have the right to take AD ownership, you can do so, which lets you reset permissions on the object. You can also view and edit individual ACEs within the ACL. To modify an ACE or set permissions on an object or a property, select an ACE in the Permission Entries window and click View/Edit.
In certain circumstances, the ACL Editor might lead you to erroneously believe that an ACE has no assigned permissions. If you use Advanced options to create or edit an ACE and set the ACE's Advanced permissions to a different combination than the ACE's standard permissions, the ACL will appear to have no standard permissions when you view it in the ACL Editor. This appearance occurs because none of the standard permissions reflect the Advanced permissions that you selected.
The Delegation of Control Wizard
Using the ACL Editor to delegate AD object administration is a complex process, so Microsoft supplemented the ACL editor with the Delegation of Control Wizard. The wizard walks through the process of assigning to users or groups an AD object's set of rights. To use the Delegation of Control Wizard, open any MMC AD snap-in and right-click a container object. On the resulting menu, you can start the wizard by selecting Delegate Control. The wizard is available only for container objects, (e.g., domains, OUs), which can contain other container objects, and leaf objects (i.e., objects, such as users and groups, that have no descendants). You won't see the wizard option if you right-click a user object.
The Delegation of Control Wizard, which Figure 4, page 82, shows, gives you two options for assigning rights. The first option presents you with a set of predefined tasks such as Create, delete, and manage user accounts. The second option lets you customize a task by defining the scope and set of rights.
The wizard is less than intuitive when it creates ACEs. For example, suppose you want to delegate the Create, delete, and manage user accounts task for an OU. Using the wizard, you assign the task to two user groups, Finance Admins and EastCoast Admins. Table 1 shows the resulting four ACEs that the wizard creates.
The wizard creates two ACEs for each user group. You tell the wizard that you want to let Finance Admins and EastCoast Admins create, delete, and manage user accounts on an OU. The wizard creates two ACEs whose scope includes the OU and all of the OU's child objects. Each ACE grants Create User Object and Delete User Object rights to a user group. The wizard also creates two ACEs whose scope includes only user objects. Each of these ACEs gives a user group Full Control rights over user objects.
The wizard makes some assumptions in creating the ACEs. The wizard assumes that you want to grant your user groups Create User Object and Delete User Object rights to the current OU and all child OUs, which might not be correct. The wizard also assumes that your user groups need access only to user objects, which also might not be correct. If you want more control over what the wizard does, you can choose the Create a custom task to delegate option in the wizard's opening dialog box. That option lets you step through each part of the ACE-building process.
You can't use the Delegation of Control Wizard to modify rights that you previously used the wizard to assign. The wizard doesn't store any information about the previous action that it performed. For example, suppose you use the wizard to grant the Finance Admins group the ability to read and write all properties on user objects within the Finance OU. Then, you decide that you want Finance Admins to read and write only the users' department property. If you run the wizard again and select only those rights, the wizard doesn't change the ACL. The wizard fails to change the ACL because the wizard looks at the current ACL and sees that read and write rights for the OU's department property are already in place; the wizard doesn't understand that you want to limit those rights only to the department property. If the wizard supported placing a deny ACE on objects, you could first deny all properties except the department property, then grant rights to the department property field. However, the best way to modify rights after you've run the wizard is to use the ACL Editor to directly modify the ACE.
Challenges and Pitfalls
AD delegation is a challenge, especially with the tools that Microsoft has provided for the task. The Delegation of Control Wizard is of little help when you begin to delegate control to administrators. And the ACL Editor's complexities can challenge the most seasoned administrators' patience. After dealing with the frustrations of managing AD ACLs, many enterprises will place administrators in the Domain Admins group because, by default, Domain Admins has rights to an entire AD domain. But this action defeats the purpose of using AD's delegation capabilities.
Managing AD security is only half the delegation story; resource security is the other half. Granting an administrator Full Control rights over an AD object (e.g., a server) gives that administrator no automatic control over the server's resources because administrative groups other than Domain Admins have no explicit permissions over a server's resources. If you want an administrative group to have administrative control over a server's resources, you need to explicitly make the administrative group a member of the server's local administrators group. Alternatively, you can use Group Policy's ability to set security policy centrally. Group Policy lets you manage who can access the physical resources behind the AD security rights you've granted. For information about Group Policy, see "Introducing Group Policy," September 1999.
Win2K needs a capability so that when you use the ACL Editor to grant rights to administer an AD server object, those rights also give the administrative group the ability to start and stop services, manage printers, and create or delete shares on the server. In Win2K's current version, those tasks require separate processes.
Delegation of administration in Win2K involves granting rights not only on AD objects but also on local system resources, such as the file system, system services, and local security policy. However, Win2K doesn't connect these tasks and instead relies on the complicated ACL Editor to set AD security and Group Policy to set resource security. In addition, few tools are available to help administrators cope with AD's complicated security model.
As enterprises implement large, complex AD infrastructures, the need for such tools, either from Microsoft or third parties, will grow. In the end, enterprises might decide to minimize complexity and errors by not using AD's full delegation capability or might look to third parties to help manage AD to maximize the product's inherent capabilities.
