Windows Administration

Delegating Authority in Active Directory

Joel Yoker and Rob Campbell

At a Glance:

• Defining administrative roles
• Developing an OU and security group model
• Using secondary accounts
• Tools for delegating rights

The delegation capabilities in Active Directory are quite powerful, addressing a number of security issues and simplifying management tasks. By properly delegating rights within Active

Directory®, you can enforce specified roles in the environment, limit the impact and likelihood of administrative error, and apply the principle of least privilege throughout your infrastructure. Yet many of the organizations that rely on Active Directory have yet to tap into the power of delegation. In part, this is because, on the surface, developing an Active Directory delegation model for your enterprise appears to be fairly complex. While the largest hurdle is to develop a delegation model that fits the unique needs of your organization, the truth is that there are very simple models that can be applied to most IT infrastructures with little modification.

Although every environment is different in some way, shape, or form, the reality is that most large enterprises are similar in many ways and face the same IT challenges. For instance, many organizations are divided into geographic regions, have evolved from separate IT engineering or operational support teams, and have independent business units. And many large organizations must deal with such matters as privilege escalation, service account abuse, and "trust."

Trust is an interesting term and often becomes the justification for having multiple Active Directory forests. Trust issues frequently stem from one division's or region's ability to impact the system availability of another division or region. It's common for skill levels to differ across organizational boundaries and for there to be a lack of in-depth knowledge of specific systems required to support a particular region or business unit. Thus, divisions typically don't want to give up their administrative rights to a central group.

Meanwhile, for any Active Directory implementation, the administrators must define the rules of engagement for applications that utilize the Active Directory infrastructure. Unfortunately, a common approach-one that is often cited in application installation guides-is to make a service account a member of the Domain Admins group. The problem with this approach is that service accounts are essentially generic accounts. By granting these accounts Domain Administrator rights, you present a significant threat to the IT environment. Service accounts can easily fall prey to improper use by malicious or careless administrators or be leveraged by attackers who exploit underlying security issues within an application.

While these hurdles may seem insurmountable, they represent a prime scenario for implementing an Active Directory delegation model. Developing a delegation model is an iterative design process and we suggest you follow these steps:

1. Define the IT administrative roles within your organization.
2. Develop an Organizational Unit and Security Group model.
3. Establish secondary accounts for IT administrators.
4. Delegate rights.

Let's take a closer look at these steps.

Define Roles

The role definition process starts with a thorough understanding of both service administration and data administration. These concepts are the cornerstone of any Active Directory delegation model.

At its core, service administration is the management of critical directory service infrastructure components, such as Exchange servers and domain controllers. Data administration is the management of objects, such as mailboxes and user accounts that reside within these services. Within the scope of Active Directory, service administrators are ultimately responsible for the delivery and availability of directory services while data administrators manage user and server accounts, groups, and other domain resources.

Active Directory supports granular delegation of authority through Organizational Units (OUs). OUs can frequently be tailored to provide the same level of authority that is available to administrators within the existing directory service or domain models. But it is important to understand that some functions simply cannot be delegated and must be managed by a single, well-trusted group or entity.

Task analysis is also critical. You need to know which Active Directory tasks are carried out by administrators and how those tasks are mapped to roles. For example, Active Directory site creation is a service administration task, while modification of security group membership generally falls under data administration. Each task should be evaluated for frequency, importance, and difficulty. These are vital aspects of task definition because they govern whether a right should be delegated. Tasks that are performed routinely, have limited risk, and are trivial to complete are excellent candidates for delegation. On the other hand, tasks that are performed rarely have great impact across the organization, and require high skill levels are poor candidates for delegation. Instead, escalation (temporarily elevating an account to the required role or reassigning the task) is the proper path for these tasks.

Since many characteristics of large organizations are similar, it's safe to assume that a common delegation model can be implemented. For the purposes of this article, we'll provide a sample set of roles that enable management capabilities while respecting organizational boundaries and attempting to mitigate trust issues (such as the availability of enterprise wide assets like domain controllers). Note that this model is just an example-it's a great start for roles discussion within your organization, but you shouldn't plan on using this guidance verbatim.

Some roles are already defined by Active Directory and some must be created from scratch to round out the delegation model. An example set of roles that would fit many large Active Directory environments might include Enterprise Admins, Domain Admins, and Tier4 Admins for service administration, and Tier3 Admins, Regional Admins, Tier2 Admins, and Tier1 Admins for data administration. See Figure 1 for a list of these roles and their responsibilities.

Figure 1 Define Roles and Responsibilities

Service Administrators

Let's take a closer look at the service administrator roles. Service administrators manage critical infrastructure components and all of the admins who fall into this category are highly privileged. Therefore, a strategy of least privilege, which means only granting the minimum set of permissions necessary to perform the required tasks, is highly recommended in this case.

Enterprise and Domain Admins Active Directory defines two groups of special administrators whose security context is required for critical functions within the directory. These groups-Enterprise Admins and Domain Admins-are responsible for top-level service administration. To mitigate the risks inherent in such highly privileged groups, we strongly advise constraining membership to these groups. In fact, the Enterprise Admins group should have no permanent members and the Domain Admins groups should contain only a small, manageable number of trusted individuals who work for the organization on a full-time basis.

When enterprise administration tasks such as DHCP server authorization or Active Directory site creation need to be performed, the Domain Admins in the root domain of the Active Directory forest can escalate privileges by managing the membership of the Enterprise Admins group. These privileges should only be granted for short periods of time in order to avoid the creation of permanent members in the Enterprise Admins group. Of course, all members of a Domain Admins group in a given Active Directory forest must be trusted equally.

A common pitfall that catches most organizations when developing a delegation model is disabling or crippling these built-in roles. Modification of the default roles can cause unpredictable results, and there is no guarantee that service pack revisions or product upgrades would retain these settings. In addition, this type of modification creates an unsupported environment outside the organization. A practical approach is to use the built-in groups and roles but limit membership. To do this, you'll probably have to create new roles for administrators who previously relied on membership in groups like Domain Admins.

Tier4 Admins The Tier4 Admins group should consist of centralized service administrators who provide support for all enterprise services. Since this is a created role, directory service and system access permissiions can be tailored to the specific requirements of your organization. While members of this group are service administrators, they may also perform occasional forest-wide data management tasks. Since there are many classes of systems and different areas of responsibility, Tier4 roles are broken into various sub-groups within the directory. For example, separate Tier4 groups should be created to provide discrete management of specific systems, such as Exchange servers. This group also serves as an escalation point for data administrators.

One reason people often want to be granted membership in the Domain Admins group is to gain administrative rights over every system in a given domain. The trick to making these service administrators run in least-privilege mode is to grant Tier4 Admins control of enterprise servers without making them Domain Admins. In order to prevent privilege escalation, Tier4 Admins should not be granted membership in the BUILTIN\Administrators group on domain controllers since that group has many underlying rights to the directory service that cannot be separated. For instance, a member of the BUILTIN\Administrators group of a given domain can manage the membership of the Domain Admins group, allowing members to escalate privileges without any checks and balances.

Remembering our rule about not crippling default permissions, this risk can be mitigated by making the Tier4 groups nested members of the Server Operators and DNS Admins built-in domain groups. This allows for the local management of domain controllers while limiting the ability of Tier4 Admins to escalate privileges. For most systems (other than Domain Controllers, Certificate Servers, and so on), you should make the Tier4 Admins group a member of the local Administrators group. Automation of nested local group membership can be achieved with the Restricted Groups functionality in Group Policy.

Data Administrators

Now let's dive into the data administration roles. These should be designed with cumulative rights, meaning that a Tier2 Admin should have all of the rights of a Tier1 Admin along with some additional privileges, and so on. For that reason, we'll look at these groups from the bottom up.

Tier1 Admins The Tier1 Admins group should provide general management of previously created directory objects. This group is for the minimally trained administrator or for those performing isolated tasks, such as password resets. Grant this group the rights within their organizational unit to modify user account properties, reset user account passwords, unlock accounts, enable/disable user accounts, add and reset workstation computer accounts, and modify group object membership for non-administrative groups.

Tier2 Admins This group should enable selective management and creation of objects, allowing for objects to be created only where they can be managed by Tier1 Admins. (For example, security groups may only be created in the Groups OU). Tier2 Admins can add and modify Tier1 Admin accounts; add, modify, and delete user accounts for an OU; delete Workstation computer objects; and add, modify, and delete Server, Contact, and Shared Folder objects.

Regional Admins This group is granted exclusive rights over their regional OU structure. They cannot, however, manage other regional OU structures within the directory. Regional Admin accounts should be considered highly privileged and, as a result, the accounts are stored in a separate OU hierarchy and managed by the Tier4 Admin service administrators. Regional Admins are permitted to create most objects without restrictions within their OU structure (a notable exception is the creation of other organizational units), which carries the additional risk of creating objects that may not be manageable by lower tiers.

Tier3 Admins Many organizations have a centralized or upper-tier help desk. This role fills out the list of data administrators, providing a data administrator group over all Regional Admins. Rights aren't delegated to these groups specifically within the directory; rather, they are made via nested membership in each Regional Admins group. This provides a top-level escalation point for all data administrators as well as a point of entry for issues to be escalated to the service administration groups.

Build an OU and Security Group Model

Once roles are defined in the organization, an OU and security group model must be defined. There are two primary reasons to create an OU in Active Directory: delegation of rights and creation of a point where Group Policy Objects can be linked. OUs define a scope-of-management (SOM) within the directory and these can be used to constrain rights to objects at various levels. As a result, how you choose to delegate authority should be a primary factor in how you implement your OU structure.

With this in mind, a top-level OU (or series of OUs) should be created directly beneath the domain to house all objects. This OU serves the specific purpose of defining the highest-level SOM for the Tier4 Admins. By creating a top-level OU, rights over the directory service can start explicitly at the OU level rather than at the domain level. Delegation from a top-level OU rather than from the domain mitigates the risk of users having the ability to escalate privileges through the manipulation of the built-in domain groups we noted earlier.

Below the top-level OUs, you should create separate sub-OU hierarchies to represent each region or business unit that has a discrete data management team. Each regional sub-OU should have a common, non-extensible OU hierarchy for management of directory objects. Uniformity is critical to ongoing management since much of the delegation of rights will be automated. This is a tall order, as each region may desire unique OUs. But IT administrators must stick to their guns, and if an extension is required for one region, the sub-OU structure should be extended for all regions. This may seem hard in the beginning, but if the organization provides generic housing for objects, outlying situations tend to fall in place over time.

Finally, create separate sub-admin groups and accounts to remove administrators ability to escalate their privileges-a Tier1 Admins, Tier2 Admins, and Regional Admins group for each sub-OU hierarchy. Placing these accounts in separate OUs allows the restriction of management to their level or below. Thus, if all Tier1 Admins accounts and the associated security group reside in an OU where they do not have rights, admins won't be able to hijack other admin accounts or escalate the privileges of other administrators to their level. Any member of the Domain Admins group, for example, can make any other user account in the domain a Domain Admin. However, with this OU model in place, that risk is mitigated. An example OU structure with associated security groups is shown in Figure 2.

Figure 2 OU Structure and Associated Security Groups

Establish Secondary Accounts

The key to a successful delegation model is enforcing the principle of least privilege. In practice, this means that a security principal should have only the ability to perform the tasks required for its given role and nothing more. Unfortunately, many IT administrators use the same security principal for directory administration and for everyday tasks like Web browsing and reading e-mail. Having separate accounts decreases the likelihood that a tiered administrator will damage the directory service by mistake or fall victim to an attack that is delivered via everyday applications but targeted at the directory administrator.

To accomplish this without requiring the user to log off and back on, you use the Secondary Logon service (Runas.exe). This allows users to elevate their privileges by providing an alternate set of credentials when executing scripts or executables on servers and workstations.

While the concept of using least-privileged accounts is relatively simple, organizations sometimes find it hard to enforce as old IT habits may be rather difficult to break. A straightforward approach to preventing the use of privileged accounts for everyday tasks is to not provide mail access to these accounts in Exchange Server, enforcing this through administrative policy within the organization. This relatively simple approach significantly reduces the likelihood that such accounts will be used for routine, non-administrative tasks.

Delegate Rights

The final step in developing a delegation model is the actual delegation of rights within Active Directory. This entails the manipulation of access control entries (ACEs) and access control lists (ACLs) on data stored within the directory. ACLs on Active Directory containers define what objects can be created and how those objects are managed. Delegation of rights involves basic operations on objects, such as the ability to view an object, create a child object of a specified class, or read attribute and security information on objects of a specified class. Besides these basic operations, Active Directory defines Extended Rights, which enable operations such as Send As and Manage Replication Topology.

In previous steps, we discussed creating security groups that map to defined organizational roles. This means that for every role there is an associated security group by sub-OU structure. To implement the delegation model, these groups need to be assigned permissions over the objects in the directory. At this point in the process, you don't want to reinvent the wheel and create a highly customized environment. Instead, try to leverage built-in groups and rights where possible. Say a particular role needs to manage DNS records for the forest. Don't attempt to delegate rights over the containers and naming contexts related to Active Directory-integrated DNS; instead, simply leverage the BUILTIN\DNS Admins group in the domain. In addition, User Rights and other permissions can be extended through Group Policy to provide the additional rights required to manage a specific class of system by a given role.

When assigning permissions using delegation, you should limit or even completely eliminate the use of Deny ACEs within the directory. These can get tricky when it comes to troubleshooting. A better approach is to make use of explicit Allow ACEs to grant rights to the custom groups representing your roles. Remember that user-defined roles, such as Tier4 Admins, will only have the explicit rights defined by that role.

Inheritance is critical to Active Directory security and defines how a particular ACL applies to child objects in a given container or sub-container. Always be specific about the scope of inheritance by ensuring inheritable ACEs are applied as close to the target objects as possible. Inheritable deny permissions applied on the parent object will precede any inheritable deny permissions applied on the grandparent object, which is one of the main reasons why Deny ACEs are not recommended for practical delegation. Moreover, inheritable permissions cannot override an explicit ACE on an object. For that reason it is recommended that you limit or eliminate the ability for tiered administrators to modify the discretionary access control list (by removing the Write DACL privilege) on directory objects. (Note that the creator of the object has these rights implicitly.) The rule of thumb is that if an administrator has the ability to change the DACL on an object, he probably will. Don't let the hard work your organization has put into its delegation model go to waste by introducing choice and potential administrative error.

There are a number of tools you'll need to use to properly implement an Active Directory delegation model. For most large organizations, using the built-in Delegation Wizard for assigning permissions in the directory is a daunting task rife with the possibility of administrative error. Instead, automation should always be used to ensure that the delegation model is well documented, that it's supportable, and that it provides a recovery option in case settings are somehow lost or changed inadvertently.

The primary tool required for implementing delegation is DSACLS.EXE, a command-line tool used to manipulate directory service ACLs on objects. This tool also allows for the inheritance flags for a DACL to be specified on the parent object. (Inheritance flags include this object and sub-objects, sub-objects only, and propagate inheritable permissions one level only.) DSACLS commands will ultimately fail if an inheritance flag is set improperly, so testing is crucial when using this tool. Here's an example of the DSACLS syntax for delegating the ability to create computer objects in the target demo OU:

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS is case-sensitive with respect to object types. This means that attempting to delegate permissions for the "cn=Computer" object class over the "cn=computer" will not work (see Figure 3).

Figure 3 Error Due to Case Sensitivity (Click the image for a larger view)

A specific set of rights is required for creating some objects. This has to do with "must contain" and "may contain" attributes on objects. The best metaphor I've heard to explain this concept is the hamburger model. Hamburgers must contain a meat patty and a bun to be considered a hamburger. Those are the must-contain attributes of the hamburger object class. Items such as pickles, ketchup, lettuce, and so on are may-contain attributes. If we extend the object class to define a cheeseburger, we would add cheese to the list of must-contain attributes.

User objects work the same way. Let's say we were to follow this model to create User objects using the following DSACLS syntax:

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

The administrator would be confronted with several errors during user object creation. We need to grant the privileges necessary to set required attributes on the user object, including setting the password. This is outlined in the following additional DSACLS syntax.

For the first step, grant the privilege to write must-contain attributes by granting Generic Read/Generic Write to all attributes of the user class:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

For the next step, grant the extended right to change the password:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

For the final step, grant the privilege to Read Property and Write Property of Password Last Set attribute:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

Once the proper rights have been delegated, the defined roles will be limited to only managing object classes defined in the container's DACL. Using the previous computer object example, the context menu in Active Directory Users and Computers restricts the list of new objects that can be created by the user who is delegated such rights (see the restricted list in Figure 4).

Figure 4 Restricted List of New Objects

DSACLS can also be automated to provide a complex deployment of rights. Here are some of the DSACLS commands that can be used to delegate rights to manipulate common address attributes over user objects in a given container:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

Examples such as these are common for most delegation models and can be used in conjunction with the previously defined roles.

Another tool used for implementing delegation is DSREVOKE.EXE, which allows administrators to locate and remove delegated rights for specific security principals on objects within the directory. While this tool can be very useful, it is specific to a security principal and does not evaluate nested membership inside security groups.

Beyond these command-line tools, we also highly recommend the use of User Rights Assignment and Restricted Groups with Group Policy. As discussed earlier, User Rights Assignment allows IT administrators to extend or remove low-level rights (such as the right to remotely access and restart a system) for various groups of users on specific target systems. Restricted Groups can be used to specify and enforce local and domain group membership within the forest. In combination, these tools provide everything you need to automate and implement an Active Directory delegation model.

Summary

Though the task of developing an Active Directory delegation model may seem complex, the truth is that very simple models can be applied to most IT infrastructures. One of the most important steps in deploying a practical delegation model is to define clear roles. You should limit the defined roles to a small, manageable number. The balance is tricky, as too many roles will result in roles not being used while too few roles won't allow for role separation.

Remember, when defining tasks, categorize them by frequency, importance, and difficulty. Once you define the roles, develop a set of use cases to help identify what each role can or cannot do and automate the testing process. Well-prepared use cases will help you explain these roles to the stakeholders in your organization and mitigate any surprises due to automation errors.

Finally, it's always a good idea to take a practical approach when developing a delegation model. Remember, simplicity equals supportability and a sustainable delegation model will pay huge dividends in controlling administrative rights within your Active Directory environment.

Additional Resources

• Design Considerations for Delegation of Administration in Active Directory
• Best Practices for Delegating Active Directory Administration

Joel Yoker is a Senior Consultant on the Microsoft Federal team. Joel and Rob are both focused on developing and deploying security solutions for United States Federal government customers.

Rob Campbell is a Senior Technical Specialist on the Microsoft Federal team. Joel and Rob are both focused on developing and deploying security solutions for United States Federal government customers.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.