Did you ever set permissions on Active Directory (AD) objects and
have those permissions mysteriously disappear shortly afterward?
Most administrators involved in AD support will have experienced
this odd behavior at some point. What might be causing it? Gremlins in the network? A rogue administrator? Actually, it's more likely
to be the AdminSDHolder object, a little-known feature of AD designed to protect
certain privileged group and user objects from compromise. We'll look at the role
of AdminSDHolder and techniques you can use to modify its behavior and avoid
common pitfalls.
An Example of the Problem
To illustrate, let's take a simple example of the AdminSDHolder object in action.
Joe works on the IT service desk and has, via membership of the Service Desk
group, the delegated permission to reset passwords for all users in an organizational
unit (OU) named Wellington Users. When Joe tries to change the password for
user James Smith, he receives an Access is Denied error. Being reasonably
tech-savvy, Joe opens the Microsoft Management Console (MMC) Active Directory
Users and Computers snap-in to compare James Smith's security settings, which
Figure 1 shows, with the settings of Don Murphy,
whose password he can reset, as Figure
2 shows.
On Don Murphy's security settings, Joe sees that the Service Desk group has
permission to reset passwords. In contrast, this permission is absent from James
Smith's security settings, which also show that permissions inheritance is blocked.
Thinking this somewhat strange, Joe asks one of the AD administrators to change
James Smith's security settings to match those of Don Murphy. Joe goes to lunch
and comes back to find a note from the AD guy to say that the security settings
have been changed as requested. Joe tries again to reset James Smith's password
and, to his frustration, gets the same Access is Denied error. He storms
off to shout at the AD admin, who tells Joe that he indeed reset James Smith's
security settings. So what actually happened?
Closer inspection of James Smith's account reveals that he's a member of the
Domain Admins group. AD protects certain privileged groups and accounts from
being compromised, including the Domain Admins group. Table
1 lists these groups and accounts. The protection extends to all members
of these groups, including nested group membership. In our example, it would
be poor security for Joe to be able to reset the password for an account that's
a member of Domain Admins, as he could easily then use the account himself,
make his own account a member of Domain Admins, create a new account with elevated
privileges, or perform similar tasks. From a security perspective, it clearly
makes sense to have some type of built-in protection in place.
What's AdminSDHolder?
Many people tend use the term AdminSDHolder to refer to the process by which
AD protects privileged groups and accounts, but it's really just the name of
an AD object. The AdminSDHolder object is a container object in the domain directory
partition at CN=AdminSDHolder, CN=System,<Domain DN>—for example,
CN=AdminSDHolder, CN=System,DC=north, DC=com.
The object itself does nothing special but acts as a place-holder for a restricted
security descriptor. Figure 3 shows an example
of the AdminSDHolder object's security descriptor. Every hour, a background
SAM task runs on the domain controller (DC) that holds the PDC emulator Flexible
Single-Master Operation (FSMO) roles. This task is, among other things, responsible
for checking whether the security descriptors of the protected groups and users
match those of the AdminSDHolder object. If the descriptors differ, the AdminSDHolder
task uses the AdminSDHolder's security descriptor to overwrite whatever permissions
have been set on the problematic group or user. In our earlier example, the
AdminSDHolder task replaced the inherited permissions that the AD administrator
had reset on James Smith's account, which resulted in the confusion.
The AdminSDHolder task also sets the user's or group's adminCount attribute
from <Not Set> to a value of 1. Figure 4
shows an example of James Smith's attributes viewed through the ADSI Edit
tool.
You can change the security descriptor associated with the AdminSDHolder object,
although I don't advise doing so. Keep in mind that this change updates all
protected users and groups with the new security descriptor. Don't make such
as change lightly; a poorly planned configuration can leave your AD environment
open to compromise. For example, assigning the Domain Users group full-control
permissions on the AdminSDHolder object would effectively allow anyone in the
domain to potentially elevate their group membership to Domain Admins.
Avoiding Resetting of Security Descriptors
As a best practice, I recommend that you don't make standard user accounts members
of the groups protected by the AdminSDHolder object. By "standard" accounts,
I mean those you typically use to log on to the domain from a workstation to
perform everyday tasks, such as creating Microsoft Word documents or working
with email. If a user needs to perform administrative tasks, assign the user
a second account for this purpose. By doing so, you can avoid scenarios like
the one I described at the beginning of the article. To remedy the problem,
you could assign James Smith an additional account for administrative purposes,
make his new account a member of Domain Admins, and place the account in a separate
OU, to which the Service Desk group has no delegated permissions.
Changing the AdminSDHolder Task Schedule
Depending on your environment, you might decide to tighten security by running
the AdminSDHolder task more frequently. You can do so by modifying the registry,
as follows. (Note that the usual warnings about modifying the registry apply.)
- Locate the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\NTDS\
Parameters subkey.
- If this subkey isn't already present, add a new DWORDvalue named AdminSDProtectFrequency
and set the value (decimal) in seconds. The lowest possible setting is one
minute (60 seconds), and the maximum is 120 minutes (7,200 seconds).
You should be aware that the AdminSDHolder task is resource intensive, so think
carefully before you decide to modify the default setting. I've noticed that
the task tends to spike the CPU on the PDC emulator DC whenever it runs. Also
note that you can't force the AdminSDHolder task to run manually.
Previous
Register
