In-Depth

Delegate! Passing Administrative Control with Active Directory

One of Active Directory’s coolest features is the ability to delegate administration in an extremely granular way. This guide shows you how.

• By Jeff Bennion
• 11/01/2001

In the years leading up to the release of Windows 2000, one of its most anticipated features was Active Directory’s ability to delegate control over portions of the directory to lower-level administrators. Windows NT 4.0’s monolithic administrative model forced enterprises concerned about security into making one of two equally unattractive compromises: either limit routine administration to a small number of administrators or break a large domain into several smaller ones.

AD promised an incredibly rich delegation model: Every object in the directory and every attribute of that object could now be secured. Organizational Units (OUs) would allow enterprises to segment their large domains into smaller containers and delegate responsibility over them to lower-level administrators.

AD seemed to meet any enterprise’s delegation needs, no matter how unique. Now that AD has been in use for more than two years, has the delegation model lived up to its promise? In my capacity as AD specialist at BindView Corp., I’ve worked with many of the largest early adopters of AD as they designed and implemented their AD forest. I’ve found that, for the most part, AD has lived up to its promise. It’s proven to be a robust and flexible directory. But if you’re among the majority of enterprises still waiting to adopt and implement AD, you can benefit from the experiences of these early adopters as you make your own plans. And even if you’re well under way in your AD deployments, it’ll help to take a closer look at your delegation design and deployment.

AD Delegation Primer
AD’s security is based on NT’s file system-level permissions, but it adds several wrinkles.

In AD, the entire object can be secured in a familiar way: Read, Write, Take Ownership and Change Permissions. Though there are hundreds of types of objects in the directory, you’ll most often work with just four of them: user, group and computer accounts, as well as OUs. Each object can be secured individually, or you can apply the permissions to an entire set of objects, which reside in OUs. You can get even more precise—each property of that object (called an attribute) can be separately secured. For instance, you might be able to change a user’s home drive letter but not her password.

Similar to NTFS, objects can have both Allow and Deny permissions; Deny permissions set directly on the object always take precedence over any Allow permissions. But AD also follows the new inheritance model introduced with NTFS 5.0. An object can inherit permissions from its parent, but these permissions are evaluated after the explicitly assigned permissions. This means that an Allow permission directly applied to an object would supercede a Deny permission inherited from above. And just like in NTFS 5.0, inheritance can be blocked.

You can choose at what level to begin applying the permissions. You can apply them to the object only, the object’s children but not the object itself, or both. For example, you could give someone Full Control over all objects in an OU, but not over the OU itself.

You can even apply permissions to only certain types of objects in the container. This means you could give Write permission to all group accounts in an OU, but not to the user accounts.

Measure Twice, Cut Once
Just like in carpentry, it pays to measure twice and cut once when deploying your AD. Don’t shortchange the planning process, and make sure you get buy-in from all affected IT groups. Make certain you have support from senior management, because you’ll likely need to call on it to get cooperation from the various IT “fiefdoms” in your company. The integrated nature of AD promises to simplify directory management vastly in the future. But the downside of directory integration in the network operating system is that previously separate IT groups will now have to work more closely together. The first team affected is Exchange administrators. Previously, NT and Exchange groups had little to do with each other; with AD and Exchange 2000, the decisions of one team can have a direct effect on the other. As AD extends its reach into the enterprise, cases like this will multiply. If one of your road rules is “my way or the highway,” AD won’t live up to its full potential.

A poorly designed forest and domain structure can be difficult to undo. OU assignments are more easily modified, but an OU structure that doesn’t adequately represent your IT department’s responsibilities will complicate your efforts to apply a consistent and clear delegation model, not to mention group policy.

Define Your Roles
Even before you’ve deployed AD, you’ll want to begin the process of defining your delegation model. Start by determining the job functions of the various IT positions in your company. Next, map those functions to the specific AD permissions required to perform those functions, but nothing more. For instance, a help-desk staffer will typically need to unlock accounts and reset passwords, but probably shouldn’t have the ability to create accounts. In a distributed IT organization, you may want to grant particular administrators Full Control over certain accounts (such as computer accounts) that belong to their region, but maybe not user accounts. Every organization is different, but every company has a limited set of organizational roles, no matter how many people they apply to or where they’re applied. It’s vitally important that these functions be carefully documented and consistently applied; ad hoc security means no security.

Microsoft has provided four methods for assigning delegation over objects. The easiest to use is the Delegation of Control Wizard (Figure 1), accessed by right-clicking on an OU from the Active Directory Users and Computers MMC snap-in and choosing “Delegate Control.”

Figure 1. Launch the Delegation of Control Wizard from the AD Users and Computers MMC snap-in by right-clicking on the OU to which you’re granting rights, then click on “Delegate Control.” (Click image to view larger version.)

In the wizard you’ll find seven common Microsoft-defined roles. If those don’t fit your model, you can customize the roles that appear here by editing the delegwiz.inf file in the winnt\inf folder. However, this .inf file must be distributed to all machines where users will be assigning delegated rights, and editing the file can be complex. Beyond that, the wizard has two significant shortcomings: It’s impossible to revoke tasks assigned through the wizard, and you can’t see which tasks you’ve already assigned. Those are potentially crippling shortcomings, so you’ll probably find that the wizard—while easy to use—won’t be very useful.

To do more extensive delegation administration, you’ll want to use the ACL editor, part of the AD Users and Computers snap-in. If you’re familiar with the new ACL dialog box for NTFS permissions, it’ll be quite familiar to you. By default, however, you can’t view AD security. To enable it, click on the View | Advanced Features menu option. After that, each object will have a security tab visible. This gives you minute control over individual ACL settings and how they’re applied. The ACL editor, shown in Figure 2, is flexible and powerful, so you’ll find it’s your first stop when doing any ACL administration. But you’ll find it difficult to get a good view of where and how your permissions are applied, as they’re scattered across three different screens. In the next section we’ll discuss one way to help you get a good grasp of your current delegation settings.

Figure 2. The security tab gives you control over individual ACL settings and how they’re applied, but you’ll find it difficult to get a good view of your permissions, as they’ll be scattered across three screens.

Two more tools round out the Microsoft-supplied set. If you’ve ever used the CACLS command-line utility, you’ll probably take to the DSACLS tool right away. DSACLS is part of Win2K Support Tools, included with Win2K Server. Like CACLS, it allows you to manipulate directory access control entries from the command line. It contains a host of powerful options; because it’s command-line-based, you can easily incorporate it into batch files to deploy permissions quickly across your forest. In fact, in order to deploy and enforce your delegation model adequately, you’ll probably need to use some kind of automation. In addition to DSACLS, you can script a solution using ADSI and your favorite scripting language with Windows Scripting Host. If you find these tools require more expertise than you possess, you can use one of a variety of third-party tools.

Delegation Best Practices
Let me share several best practices regarding delegation.

• Create special OUs for both administrative accounts and compromised accounts and limit the rights over those OUs to a small set of administrators. If a helpdesk employee is able to change an administrator’s password, that user has effectively gained administrative access. And accounts that have been disabled for security reasons (for instance, recently terminated employees) should be moved out of their original containers into a “maximum security” OU so that even if the helpdesk personnel are duped into attempting to enable or unlock a compromised account, they won’t be able to.
• Delegate access through groups rather than users.
• Assign access at the lowest possible level. ACLs propagate (through inheritance) to all subsidiary objects. In large enterprises, these can quickly add up to huge numbers of access control entries (ACEs), which can significantly affect performance. (See “Additional Information.”)
• Avoid granting Full Control over containers. Limit delegated administrator’s rights to only specific object types they need. Create and Delete operations in particular can potentially affect the entire forest. • Use group policy to control user rights.
• Consider separating object-creation tasks from object-management tasks.
• Delegating the ability to move objects requires Delete permissions in the source OU and Create permissions in the target OU.
• Group membership administration is granted in the OU where the group account resides, not where the user account is. This means you can limit which groups a person can administer, but the person can add or remove any user account from that group.
• Remember that object owners, regardless of their explicit access level, can always gain Full Control over the object.

Get it in Writing
Proper maintenance of your delegation infrastructure requires careful documentation and auditing of delegation changes. It’s inevitable that the roles you’ve defined will change. Departments will take on additional responsibilities, and others may require less than you originally envisioned. If you’re not vigilant in documenting any changes to your delegation, you’ll rapidly lose control of the process, reduce accountability, and maybe even compromise your security.

Delegating the Ability to Unlock User Accounts An oversight in the default implementation of AD delegation is the ability to unlock accounts. This is one of the most common functions assigned to help desks, but the functionality isn’t exposed by default. Certain permissions Microsoft considered less common are hidden from the permissions dialog box to make it more workable. The dssec.dat file in the WINNT\system32 directory contains this list of hidden attributes. Open up this file in the notepad and locate the [user] section. You’ll find a line that reads: lockoutTime=7 Change the value from 7 to 0, then save the file and exit notepad. After doing this, you’ll see two new permissions in either the Delegation of Control Wizard or the AD Users and Computers Security tab. They’re called ReadLockoutTime and WriteLockoutTime. Anyone you give this permission to in an OU can unlock all the user accounts in that OU. To delegate the ability to unlock user accounts, open the dssec.dat file and change the LockoutTime value to 0. (Click image to view larger version.) After saving the dssec.dat file, you’ll see two new permissions in the security tab.

This documentation doesn’t require anything fancier than good old-fashioned pen and paper. In an accessible place, you’ll want to store what permissions belong to each role you’ve designed. Make sure you keep this list current.

Right away, you should enable auditing on your AD Domain Controllers so that you can monitor any changes to your delegation model. This is a two-step process. First, turn “Directory Service Access” auditing on (for success and failure) in the Domain Controllers Security Policy MMC snap-in. (If you’ve moved your DCs out of their default OU, modify the GPO for the OU in which the DCs reside). As seen in Figure 3, you’ll find this setting under Security Settings | Local Policies | Audit Policies. Change the “Audit Directory Service Access” option to audit for both success and failure. These changes will take a while to propagate, so events won’t begin showing up immediately. However, if you don’t want to wait for the new GPO settings to propagate normally, you can force a refresh on the local domain controller by typing:

secedit /refreshpolicy machine_policy

at the command prompt.

Figure 3. Before AD changes are logged, you need to configure the Domain Controller Security Policy to audit directory service access. (Click image to view larger version.)

Once you’ve enabled auditing, the audit ACLs defined on the directory take effect. You can view the auditing ACLs from the AD Users and Computers MMC Snap-in. To see the top-level audit settings for your domain, right-click on the domain, choose Properties, and click on the Security tab. Click on the Advanced button, and click on the Auditing tab. You’ll see that default auditing ACLs for Everyone are set up for a large number of operations (Figure 4). The only settings relevant to this discussion are the “Modify Owner” and “Modify Permissions” entries. Success and failure auditing is enabled for both of these events, which is what you’ll need. Note that enabling audit settings for very frequent operations (like Reads) could dramatically affect performance, as well as quickly fill your security event logs.

Figure 4. Modify Permissions and Change Owner Auditing is on by default. You may not want to monitor all the audit events that are enabled by default.

Keep in mind that these events are recorded on the DC where the operation occurred. Use the Resource Kit utility called DUMPEL to consolidate the reporting across all your DCs. (A variety of third-party tools can also help you consolidate this information.)

Once you’ve enabled auditing, look for event ID No. 565 entries in the security log. Unfortunately, this event is for all directory service operations (object creation, deletion, modification, and the like). ACL changes will be indicated in the “Accesses” section with the WRITE_DAC keyword. Ownership changes will be indicated with a WRITE_OWNER keyword.

As Figure 5 shows, the audit logs tell you who did the action, where the action was applied, and when it happened. But it won’t tell you what kind of access was changed or whose access changed.

Figure 5. An event log entry for a directory permissions change. The log shows who performed the operation and where it was set.

That information isn’t stored as part of auditing, so it’s critical to document your existing AD structure so you can refer to it when it changes. The ACLDIAG.EXE command-line tool will do just that. Like DSACLS, this is also part of the Win2K Support Tools.

ACLDIAG will list all the security settings in the OU you specify. There are options to format the output tab-delimited, which will make the output easy to import into Excel or a database program. You have to specify each OU individually. For instance, if you wanted to view all the security information in the West OU in your meru.org domain and pipe the output to an Excel-readable file, the syntax would be:

acldiag "ou=west,dc=meru,dc=org" /tdo >westout.prn

Because you’ll need to do this for each OU in your enterprise, a batch file would be the easiest way to collect all the information at once, which you can then run periodically.

ACLDIAG has a number of other useful features. It can tell you which delegation tasks have been applied to an OU through the Delegation of Control Wizard. In limited cases, it can even restore those task templates if they’ve been modified. It can also compare the permissions applied to the defaults specified in the schema, and display effective permissions for a given user or group.

Learning how to delegate authority in AD is challenging, to be sure. But the payoff, in terms of easier administration and a more secure network, makes it worth the effort. After all, why implement AD and then not take advantage of all it offers?