Delegate! Passing Administrative Control with Active Directory

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.

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.

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:

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.

Additional
Information

You’ll surely encounter some situations not covered
here. This list of additional resources will help deepen
your knowledge of AD delegation.

Fortunately, the industry has accumulated a good deal
of real-world experience in AD design, which has been
nicely distilled in “Best
Practice Active Directory Design for Managing Windows
Networks." This white paper contains excellent
information on how best to design the forest, tree,
domain and OU structure. Anyone undertaking an AD deployment
would be well-served by consulting this document to
winnow the array of design choices you’re faced with.
After you’ve digested that, you can move onto a sister
white paper that discusses deployment

Also useful: “Building Enterprise AD Services: Notes
from the Field.” Chapter 11 has a discussion of how
to delegate certain configuration operations like WINS
and DNS to non-enterprise administrators.

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?