"Admin Free" Active Directory and Windows, Part 2- Protected Accounts and Groups in Active Directory
I am a terrible blogger when it comes to timeliness and consistency of post intervals. I admit it. All I can say is, it has been a busy summer. I actually have a half-dozen posts queued up for publication, but each needs to be scrubbed and fleshed out before I post them, so even though I may be slow to get them out, please know that there are definitely more in this series.
In the "Don't do as I do" category...
All screenshots and text examples provided in this post were captured on a Windows Server 2008 R2 virtual machine I built for testing purposes, and I did several things that you should never do (unless you're just trying to get a blog post finished and are going to shut down the virtual machine as soon as you're done). I logged onto the VM (a DC) as the built-in Administrator. I did the same thing with each of the test accounts. I used the same password for each of the accounts. In short, I did things that I would never do in a production environment, nor should you. Since I fully expect that the eagle-eyed among you will quickly notice that I've violated basic security principals in these screenshots, I thought I might as well 'fess up and get that out of the way so that we can focus on the important bits.
Without further ado, here goes...
Protected Accounts and Groups in Active Directory
Within Active Directory, a default set of highly-privileged accounts and groups are considered “protected” accounts and groups. With most objects in Active Directory, admins (or delegates) can change permissions on the objects, including changing permissions to allow themselves to change memberships of the groups, for example. However, with protected accounts and groups, the objects' permissions are set and enforced via an automatic process that ensures that the permissions on the objects remains consistent even if the objects are moved about the directory. Even if somebody manually changes the objects' permissions, this process ensures that they're returned to their "defaults" in short order.
AdminSDHolder and SDProp
In the System container of every Active Directory domain, an object called AdminSDHolder is automatically created (CN=AdminSDHolder,CN=System,DC=...). The purpose of the AdminSDHolder object is to provide "template" permissions for the protected accounts and groups in the domain. Every 60 minutes (by default), a process known as SDProp (Security Descriptor Propagator) runs on the domain controller that holds the domain’s PDC Emulator (PDCE) role. SDProp compares the permissions on the domain’s AdminSDHolder object with the permissions on the protected accounts and groups in the domain. If the permissions on any of the protected accounts and groups do not match the permissions on the AdminSDHolder object, the permissions on the protected accounts and groups are reset to match those of the domain’s AdminSDHolder object.
Additionally, permissions inheritance is disabled on protected groups/accounts, which means that even if the accounts and/or groups are moved to different locations in the directory, they do not inherit permissions from their new parent objects. Inheritance is also disabled on the AdminSDHolder object so that permission changes to the parent objects do not change the permissions of AdminSDHolder.
Changing the SDProp Interval
Except for purposes of testing, you shouldn't change the interval at which SDProp runs. However, if you're like me, you probably still want to know how to do it, "just in case". To change how often SDProp runs, on the PDCE in the domain, use regedit to navigate to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Add a DWORD key called "AdminSDProtectFrequency" if the value does not already exist. The value of AdminSDProtectFrequency is set in seconds and valid values range from 60 to 7200 seconds (one minute to two hours). To return to the default 60-minute execution interval, just delete the key you created. And please, don't do this in production, because reducing the interval can increase LSASS processing overhead (read: spike your DC's utilization) and as far as I know, there's no reason to change the value in a production environment.
Manually running SDProp
In operating systems prior to Windows Server 2008, you can use the procedure found in KB article 251343 to force SDProp to run immediately. In Windows Server 2008 or 2008 R2, however, you can use LDP to execute the RunProtectAdminGroups task. To do this, launch ldp.exe, connect and then bind to your PDCE with appropriate credentials, and in the Browse menu, select Modify. In the resultant dialog box, type "RunProtectAdminGroupsTask" (without quotes) in the Attribute: field and "1" (without quotes) in the Values: field. Leave the Operation set to Add, click the Enter button to populate the Entry List field, and then click Run. (See screenshot below) This is useful if you are testing some of the concepts described in this post, so that you don't have to wait for SDProp to complete its scheduled run in order to see the results of your modifications. (And is yet another reason why you shouldn't need to change the SDProp interval.)
Default Protected Accounts and Groups in Active Directory by OS and SP Version
The following table lists the default protected accounts and groups in Active Directory by operating system version and service pack level:
|
Default Protected Accounts and Groups in Active Directory |
|||
|
Windows 2000 <SP4 |
Windows 2000 SP4 –Windows Server 2003 RTM |
Windows Server 2003 SP1+ |
Windows Server 2008 – Windows Server 2008 R2 |
|
Administrators
|
Account Operators |
Account Operators |
Account Operators |
|
Administrator |
Administrator |
Administrator |
|
|
Administrators |
Administrators |
Administrators |
|
|
Backup Operators |
Backup Operators |
Backup Operators |
|
|
Cert Publishers |
|||
|
Domain Admins |
Domain Admins |
Domain Admins |
|
|
Domain Admins |
Domain Controllers |
Domain Controllers |
Domain Controllers |
|
Enterprise Admins |
Enterprise Admins |
Enterprise Admins |
Enterprise Admins |
|
Krbtgt |
Krbtgt |
Krbtgt |
|
|
Print Operators |
Print Operators |
Print Operators |
|
|
Read-only Domain Controllers |
|||
|
Replicator |
Replicator |
Replicator |
|
|
Schema Admins |
Schema Admins |
Schema Admins |
Schema Admins |
|
Server Operators |
Server Operators |
Server Operators |
|
Note: DSHeuristics Attribute
An attribute on the AdminSDHolder object, DSHeuristics, allows limited customization (removal) of groups that are considered protected groups and are affected by AdminSDHolder and SDProp. This customization should be carefully considered if it is implemented, although there are valid circumstances in which modification of DSHeuristics on AdminSDHolder is useful. More information on modification of the DSHeuristics attribute on an AdminSDHolder object can be found in the Microsoft Support Article #817433.
The adminCount Attribute
When an account or group is flagged as a protected account/group, the value of the adminCount attribute on the object is set to a value of "1", which changes how security is applied to the account's object in AD. Objects whose adminCount attribute has a value of "1" will have their ACLs set to match those of the domain's AdminSDHolder attribute every time SDProp runs, regardless of whether the accounts are actually privileged accounts. Any account that has direct or transitive membership in any protected group (whether the membership is derived from security or distribution groups) is subject to this restricted security. If a user is a member of a group that is, in turn, a member of a protected group in AD, then that user object is flagged as a protected account.
Distribution Groups Nested in Protected Groups
When transitive membership in a protected group includes nested distribution groups (DGs), accounts that are members of nested distribution groups will not receive the protected group’s SID in their access tokens. However, distribution groups can be converted to security groups in Active Directory, which is why distribution groups are included in protected group member enumeration. Should a protected-group-nested distribution group ever be converted to a security group, the accounts that are members of the former distribution group will subsequently receive the parent protected group’s SID in their access tokens at next logon, but will already have been subject to AdminSDHolder and SDProp.
In summary, if you're a member of a DG that is protected, your account is flagged as a protected account, although that protected group's SID isn't included in your access token unless and until the nested DG is converted to a security group.
Take, for example, the user Jack NoAdmin shown below. Jack is a member of Domain Users and a group called "AdminSDHolderDistributionGroup" (I never claimed to be creative in my naming conventions.)
The AdminSDHolderDistributionGroup group is, you guessed it, a distribution group:
And the AdminSDHolderDistributionGroup group has a lone member, Jack NoAdmin:
However, the AdminSDHolderDistributionGroup group is also a member of the Administrators group in the NWTraders.msft domain:
When Jack NoAdmin logs on and runs whoami /groups, the Domain Admins group is not included in his access token (nor, of course, is the DG's SID since it's not a security group):
Nonetheless, Jack NoAdmin's account is flagged as a protected account:
Orphaned Protected Accounts
Suppose one day I'm perusing my directory and I notice that somebody has placed a distribution group into my Domain Admins group. Since this makes no sense to me, I remove that distribution group from the Domain Admins group. Alternately, suppose I am simply pruning the membership of my Domain Admins group because I'm working towards a "zero admins" Active Directory. What I may not realize is that my cleanup work is not finished at this point. When an account is removed from a protected group, it is no longer considered a protected account, but its adminCount attribute remains set to “1” if it is not manually changed. The result of this configuration is that the object’s ACLs are no longer updated by SDProp, but the object still does not inherit permissions from its parent object(s). Therefore, the object may reside in an OU to which permissions have been delegated, but the formerly-protected object will not inherit these delegated permissions. A script to locate and reset formerly-protected objects in the domain can be found in the Microsoft Support Article #817433.
AdminSDHolder Ownership
Most objects in Active Directory are owned by the domain’s built-in Administrators group; however, the AdminSDHolder object is, by default, owned by the domain’s Domain Admins group (this is a circumstance where Domain Admins do not derive their rights and permissions via membership in the Administrators group for the domain).
In versions of Windows prior to Windows Server 2008**, owners of an object can change permissions of the object, including granting themselves permissions that they did not originally have. The default permissions on a domain’s AdminSDHolder object prevent users who are members of Administrators or Enterprise Admins groups from changing the permissions for a domain’s AdminSDHolder object. However, members of the Administrators group for the domain can take ownership of the object and grant themselves additional permissions, which means that this protection is rudimentary and only protects the object against certain accidental modification by users who are not members of the Domain Admins group in the domain. Additionally, both the Administrators and Enterprise Admins (where applicable) groups have permission to change the attributes of the AdminSDHolder object.
**In another post, I'll talk about things like the OwnerRights SID in Windows Vista and later operating systems.
Modifying AdminSDHolder to "Prevent" Modification of Most-Privileged Groups
There are actually lots of reasons why the AdminSDHolder object and SDProp are important, but most of them aren't the focus of this post. This post is focused on one particular aspect of AdminSDHolder, which is this: we often encounter customer environments in which somebody has modified AdminSDHolder to "block" unauthorized changes to the most privileged groups in AD. In fairness, this kind of modification is something that is documented in an article entitled Modify the AdminSDHolder container. However, there's a really important line in that article, which is "This procedure will not completely prevent unauthorized changes to membership of administrative groups in an Active Directory domain." Somehow, this sentence doesn't seem to resonate with people, because time after time, we see modifications made to AdminSDHolder in an effort to increase security that actually does no such thing. At this point, I'll run through the modification we often see and why it doesn't work the way people intend it to work.
When we perform Active Directory Security Assessments (ADSAs), we run a series of PowerShell scripts that retrieve information about the forest we're assessing. These scripts do not require any special privileges in and of themselves, but in order to ensure that we're retrieving accurate information, we require an account that has read permissions to essentially everything in the directory that can be read by Enterprise Admins plus Domain Admins and Administrators in each domain. In an ideal world, there would be a built-in "Auditor" role in AD that would provide read access to the entire directory, plus read access to event logs, GPOs, etc., but as of this writing, there is no such thing. We always ask the customer if they have created such a role, but so far, none have, and as a result, we usually end up needing membership in the most privileged groups for the accounts that are used to run the scripts. In order to truly assess the security of the directory, we need to be able to read information that has been ACL'd to be available only to privileged accounts, such as cases in which attributes have been marked confidential or in which the organization has changed various "read" permissions in an attempt to prevent non-admins from reading directory information. It is here where we tend to run into a lot of creative modifications to AD that usually don't achieve the results their implementers intended.
We often see modifications made to the AdminSDHolder objects in an organization, usually because somebody is trying to allow, say, Domain Admins to modify objects, but prevent Administrators from modifying the object. A typical example of this is when we see customers modifying AdminSDHolder to attempt to prevent Administrators from adding themselves to the domain's Domain Admins group, and in the case of the root domain, the Enterprise Admins group. There are a few issues with this approach, however. The first is that there is usually a fundamental misunderstanding of what rights and privileges are granted to which of the three most powerful groups in AD. If you read Part 1 of this series, you know that many of the rights and permissions granted to Domain Admins and Enterprise Admins are actually the result of those groups being nested in their domain's Administrators group, the very group that is being treated as if it's "less" privileged. You also know that you should really consider these groups effectively equivalent from the perspective of potential privilege, since via various means, one may make itself a member of the others.
In these environments in which we see the organization attempting to "restrict" Administrators, what we also typically see is that they have smaller numbers of Enterprise Admins and Domain Admins, but lots of Administrators, because they're under the impression that Administrators aren't "as privileged" as Domain or Enterprise Admins. The default rights, permissions and scope of access associated with each of the three groups vary, but that does not mean that one group is more or less privileged than another- it just means that they have different default breadth of capability, not depth of capability. In short, believing that placing users into the Administrators group rather than the DA or EA groups buys a level of security is a misconception. It prevents somebody who is a member of the Administrators group for a domain from accidentally performing functions that are reserved (by default) for EA or DA members, but it doesn't prevent intentional attempts to bypass the default rights and permissions associated with the group- and to be clear, even in cases in which the bypass is intentional, it's not always malicious. A user who is a member of Administrators, but not Domain Admins, may encounter an access failure while trying to fix something that is broken and resolve the access failure by adding his/her account to the Domain Admins group. The action isn't malicious, but it is intentional, and it's trivial to perform.
The second misconception that we find in organizations that make these kinds of modifications is that they can modify AdminSDHolder in a fashion that will allow them to prevent Administrators from making themselves Domain Admins (or EAs), and that's the focus of this post. I now intend to show you the most common modifications we see made to the AdminSDHolder object, and to illustrate why none of them actually work.
Note: the second most common modifications we see in this area are attempts to "block" Enterprise Admins from accessing domains outside of the forest root domain. This is also a fruitless exercise, but isn't the focus of this particular post. I might perhaps write a separate post about this one, or I might not, but I hope you'll trust me when I say that what I wrote in Part 1 about how you should treat the three groups as effectively equivalent because each can become the others is true.
"Blocking" Administrators in Active Directory
Okay, so let's get down to brass tacks. In the scenario below, I've constructed a single-domain forest. (These principles still apply in multi-domain forests.) In this domain/forest, I have created three administrative users, each with membership in just one of the three most privileged groups in the domain. Well, sort of...
First, there's Jane Administrator. Jane is a member of Domain Users (default), Administrators and a third group that will come into play later in this scenario, a group I have created called "AdminDenyGroup".
Next, I've created Jim Enterprise Admin. Jim is a member of Domain Users, Enterprise Admins and the aforementioned AdminDenyGroup.
Finally, I have created Joe DomainAdmin, who is a member of Domain Users, Domain Admins and the AdminDenyGroup, which is not yet used for anything in this scenario.
At this point, you're probably saying, "wait, Joe and Jim aren't just members of those groups," and you're correct. In reality, all three of my users are members of the Administrators group in this domain, because of the default setting below, which is that EA and DA groups are nested into the domain's Administrators group.
If Jane, Jim and Joe log on, open a command prompt and type whoami /groups, here's what each of them sees:
Jane's Group Information
Group Name Type SID Attributes
========================================== ================ =========================================== ==================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias S-1-5-32-554 Group used for deny only
BUILTIN\Certificate Service DCOM Access Alias S-1-5-32-574 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group
CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
NWTRADERS\AdminDenyGroup Group S-1-5-21-379885987-58094810-1550352872-1109 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label S-1-16-8192 Mandatory group, Enabled by default, Enabled group
(I'll talk about some of the other information above, such as the "Group used for deny only" and "Mandatory Label..." bits in a different post.)
Jim's Group Information
Group Name Type SID Attributes
================================================ ================ =========================================== ===============================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias S-1-5-32-554 Group used for deny only
BUILTIN\Certificate Service DCOM Access Alias S-1-5-32-574 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group
CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
NWTRADERS\AdminDenyGroup Group S-1-5-21-379885987-58094810-1550352872-1109 Mandatory group, Enabled by default, Enabled group
NWTRADERS\Enterprise Admins Group S-1-5-21-379885987-58094810-1550352872-519 Mandatory group, Enabled by default, Enabled group
NWTRADERS\Denied RODC Password Replication Group Alias S-1-5-21-379885987-58094810-1550352872-572 Group used for deny only
Mandatory Label\Medium Mandatory Level Label S-1-16-8192 Mandatory group, Enabled by default, Enabled group, Local Group
Joe's Group Information
Group Name Type SID Attributes
================================================ ================ =========================================== ===============================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias S-1-5-32-554 Group used for deny only
BUILTIN\Certificate Service DCOM Access Alias S-1-5-32-574 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only
NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group
CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
NWTRADERS\Domain Admins Group S-1-5-21-379885987-58094810-1550352872-512 Mandatory group, Enabled by default, Enabled group
NWTRADERS\AdminDenyGroup Group S-1-5-21-379885987-58094810-1550352872-1109 Group used for deny only
NWTRADERS\Denied RODC Password Replication Group Alias S-1-5-21-379885987-58094810-1550352872-572 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label S-1-16-8192 Mandatory group, Enabled by default, Enabled group, Local Group
Given the above, I'm using Jane Administrator for demonstration purposes since theoretically, she's the "least" privileged of the three users due to the fact that she's only in the Administrators group, but not the DA or EA groups.
In my scenario, I'm my company's primary AD administrator, and I want to prevent my three junior admins from making themselves members of the other privileged groups in the domain. First, I create a security group called AdminDenyGroup and I put Jane, Jim and Joe into that group. (Sometimes we see individuals added to these deny groups, sometimes we see the Administrators group added to these deny groups and sometimes it's a combination of the two. It doesn't much matter what permutation is used, the results are the same, which is that there is a subset of highly-privileged users who are "locked down", but still retain membership in one or more of the three most-privileged groups.)
Next, I modify the ACL on my domain's AdminSDHolder object to deny members of the AdminDenyGroup the ability to write to the members property on any of the protected groups in the domain. I do this using the DSACLs command-line utility, typing dsacls CN=AdminSDHolder,CN=System,DC=NWTraders,DC=msft /D NWTRADERS\AdminDenyGroup:WP;"member" into an administrative command prompt.
Adding "Deny" Entries to the AdminSDHolder DACL
In the DSACLs line above, I first invoke DSACLs, then provide the path to the object on which I want to view or modify ACLs. /D adds a "deny" access control entry (ACE) to the object and is followed by the name of the principal for which the deny ACE will be set. The WP entry represents "write property" and the "member" attribute is the property to modify.
Note: for full usage information for DSACLs, you can type "dsacls /?" at a command prompt. I'll also be providing some additional usage information later in this post.
Now that I've denied my junior administrators the ability to write to the membership of any of my domain's protected groups by modifying the AdminSDHolder ACLs, I force SDProp to run so that my changes are immediately propagated to all privileged groups in the domain. (As shown earlier in this post). Next, I look at the ACLs on the domain's AdminSDHolder object using ADSIEdit.msc and this is what I find:
AdminSDHolder ACL
I can see that my AdminDenyGroup has been added to the ACL with Special permissions, so I click the Advanced button to view the entry. This is what I see:
Special Permissions for AdminDenyGroup
No matter where I look on the AdminSDHolder object, I don't see what are the special permissions that I thought I had just set. However, if I look at the ACL on one of my protected groups, I can see that my ACE has actually been applied.
Domain Admins ACL
I point this out because it can be confusing to try to determine AdminSDHolder ACLs from a GUI unless you know where to look, which in some cases is actually on a different object. If, however, I use DSACLs to display the security on the AdminSDHolder object, I will actually see that there is a deny ACE for the AdminDenyGroup. If you're ever looking at one of your domains' AdminSDHolder objects and aren't able to see the ACEs for some of the entries, you should use DSACLs to display the security instead.
Now I feel that I've effectively stopped my junior admins from making themselves members of other protected groups and I head out for a long weekend. Over the weekend, Jane is troubleshooting an issue and receives an "access denied" message because she's not a Domain Admin. Jane fires up Active Directory Users and Computers and views the membership of the Domain Admins group, intending to add her account to the group. When she brings up the group's properties, she sees that the Add and Remove buttons are grayed out, which means she can't add herself to the Domain Admins group. Right?
Not so fast. Jane really needs to be a member of the Domain Admins group to fix the issue she's troubleshooting, so she locates her own account in the directory, right-clicks it and selects "Add to a group..."
Jane then types "Domain Admins" into the Select Groups dialog box, checks the names and clicks "OK"...
...and this is what she sees:
Voila! Jane is now a Domain Admin and proceeds to fix whatever it was that she needed to fix.
I return to the office after my long weekend and I discover that Jane is now a member of the Domain Admins group in my domain. While I should probably just go talk to Jane to ask her why she made this change, instead I decide to get medieval on Jane and really block her ability to make herself a member of any other privileged groups besides Administrators. First, I spend some time with DSACLs and I look at the various permissions entries that I can set, shown below.
Generic Permissions
GR- Generic Read
GE- Generic Execute
GW- Generic Write
GA- Generic All
I can set generic permissions, but those are a little too broad for what I'm trying to accomplish, so I look at the specific permissions that I can set.
Specific Permissions
SD- Delete
DT- Delete an object and all of its children
RC- Read security information
WD- Change security information
WO- Change owner information
LC- List the children of an object
CC- Create child object
DC- Delete a child object
WS- Write To Self (also known as Validated Write).
Note: there are 3 kinds of validated writes, and how the WS permission is applied will depend on the type of object to which it is applied (I don't have to specify this in DSACLs). Self-Membership is applied to Group objects and allows updating membership of a group in terms of adding/removing one's own account. Validated-DNS-Host-Name is applied to computer objects and allows systems to update their DNS names. Validated-SPN is also applied to computer objects and allows the computer to update its own SPN attribute.
WP- Write property
RP- Read property
CA- Control access right
LO- List the object access.
Note: LO can be used to grant list access to a specific object if List Children (LC) is not granted to the parent as well. It can also be denied on specific objects to hide those objects if the user/group has LC on the parent. AD DS does NOT enforce this permission by default, it has to be configured to start checking for this permission.
Now that I've familiarized myself with the various specific permissions that I can deny my AdminDenyGroup, I type the following at an administrative command prompt:
dsacls CN=AdminSDHolder,CN=System,DC=NWTraders,DC=msft /D NWTRADERS\AdminDenyGroup:SDRCWDWOWS
This command adds deny ACEs to block the group from deleting protected objects, reading the ACLs on protected objects, changing the ACLs on protected objects, changing ownership of the protected objects or adding themselves to protected groups.
I run SDProp and pull up the permissions on the Domain Admins group.
Satisfied that I've finally thwarted my junior administrators, I head out of town for a three-day conference. While I'm out, Jane is performing routine maintenance and receives an "Access denied" message when she tries to perform a function that, by default, requires Domain Admins membership. Jane is perplexed, because she remembers that she added herself to the DAs group over the weekend, so she locates her account in AD, notices that she's no longer a member of Domain Admins (since I removed her) and tries to re-add herself via the same mechanism that she used over the weekend. This is what she sees:
Jane is curious about this new behavior, so she decides to take a look at the permissions on the Domain Admins group. When she brings up the group's properties and tries to view the Security tab, this is what she sees:
Fortunately, there is that "Advanced" button that Jane can click, so she does, and she sees this unusual dialog box:
Since it seems pretty straightforward, Jane selects her own name in the "Change owner to:" field and clicks "OK". She receives a message telling her that she needs to close and reopen the object's properties, so she does, and this is what she now sees:
Now that Jane owns the object, she clears the restrictions on the AdminDenyGroup, or, if she wants quicker results, just removes the ACE altogether.
Jane then adds herself to the Domain Admins group. The next time SDProp runs, the AdminSDHolder-defined permissions are reset back to what I had defined, but Jane is still a member of Domain Admins.
I return from my conference and I again find that Jane is a member of the Domain Admins group, but when I go to look at the ACLs on the group, nothing seems amiss, so I'm now completely confused.
Getting to the Point(s)
First, why was Jane able to take ownership of the Domain Admins group despite the fact that I had explicitly denied that permission to the AdminDenyGroup? Because Jane is a member of the Administrators group in the domain. One of the privileges held by the built-in Administrators group is the ability to take ownership of objects. Privileges trump permissions. (The difference between rights and privileges is fuzzy, even in some of our own documentation, so for brevity's sake, let's just go with "privileges" here.)
Second, at this point, you might be thinking of various creative approaches that I can take to stop Jane from doing what she did. Perhaps in addition to what I've done above, I can create a restricted groups policy and enforce the membership of my DA, EA and Administrators groups. Well, Jane can still do all of the things that she did above, and once she has that membership in Domain Admins, she can go delete or modify my restricted groups policy (the mechanics will depend on how my GPO security is configured as well as other factors, but one way or another, she can find a way to bypass that policy). Perhaps I decide that I'm going to give Jane a restricted set of administrative tools and deny her the ability to launch dsa.msc. Jane can just switch to a command line to do what she previously did via the GUI. Perhaps I can start setting all kinds of deny ACLs for that AdminDenyGroup, muck with default schema permissions, block .dlls, muck with rights and privileges...
And all I'll really accomplish by doing all of those things is to make a mess of my directory and in all likelihood, generate a slew of difficult-to-fix errors. Why should I "lock down" people rather than simply not giving them an excessive level of privilege in the first place? If I don't give it, I don't have to take it away. So why don't I look for ways that I can let Jane do what she needs to do without giving her wholesale privilege that I then try to "tweak"? You don't make a demigod by shackling a god; build up rather than tearing down.
Perhaps you're thinking that I should be implementing stringent auditing, as well. Well, I should be, but auditing is reactive, not proactive. Alerts come after the breach has already occurred, which brings me to what I discussed in the first post in this series. I've mentioned in a previous post what the team for which I work in Microsoft does, and that we've been heavily focused on APT and APT-like attacks for several years. We've seen varying levels of sophistication in these attacks, where the adversaries usually start with the simplest approach that gets them what they want, escalating their tactics only once they've been discovered and the target organization has started to kick in with some defenses. What we do see, however, is that once the attackers have gained privileged access to an environment, they act swiftly to obtain both data and additional access to the environment. The goal after the first intrusion is usually to find "legitimate" means to access the target organization, and to blend in with real users and systems so that it's hard to find the attackers. So while there may be excellent auditing and alerting in use within your company, the people targeting it may only need one of your privileged accounts for minutes in order to achieve what they want to achieve. No matter how quickly you respond to an alert that a privileged account has been breached, at that point, it's too late.
This is why I am a proponent of the "zero admins" approach to Active Directory (and it's not just AD to which this principle is applicable). If you have no accounts that actually have broad and deep privilege in your environment, then you have already exponentially increased the difficulty the attackers face in attempting to own your environment. You will never stop somebody who wants to attack your organization from doing so, but what you can do is to make it so hard for them to get to what they want that you're able to get them out before they've gotten what they've come for. This isn't a new idea- it's basic defense in depth, least privilege, etc. We've been telling this story for years. I'm just trying to tell it a little bit differently, I guess.
Thanks for reading a really long post. I hope it made some sense.
Until next time...
P.S. This post was actually published on 13 August 2011, but since I started it in June, it bears an old date. Sorry about that.
Comments
Anonymous
January 01, 2003
Great catch, David! Fixed, and thanks!Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Good stuff Laura. Just one tiny thing - you mention "However, the AdminSDHolderDistributionGroup group is also a member of the Domain Admins group in the NWTraders.msft domain:" when the screen shot shows the DL Administrator group?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi Darren, That's not a dumb question at all; it's a very salient and logical one. In the example you give, you'd actually do what we've always recommended, which is to temporarily place the account that's performing the schema upgrade to the Schema Admins group, run the update, then remove the account from the SA group. However, to really answer your question, "with a zero-admin environment how do elevated things get done in the environment," to a degree, it depends on what "elevated things" means. For some tasks, you might just want to delegate appropriate rights and permissions to role groups. An example of this approach would be in delegating permissions that allow support staff to unlock accounts and reset passwords for users in their scope of responsibility. In other cases, the scenario might be one in which you'd ultimately need to delegate so many rights and permissions that doing so would almost replicate the power that Administrators, Domain Admins, and/or Enterprise Admins have. An example of something like this could be the act of creating a new domain in a forest by running DCPromo on a server that will become the first DC for the domain. For situations like that, you're generally better off temporarily populating the privileged group(s) that can perform the operation. For more information on some basic approaches to being able to populate and de-populate privileged groups, please take a look at the "Best Practices for Securing Active Directory" whitepaper at www.microsoft.com/.../details.aspx. I hope this helps a bit. Thanks, LauraAnonymous
August 28, 2013
Ok, dumb question but with a zero-admin environment how do elevated things get done in the environment? For example say when a new version of Windows comes out and a new AD schema, how does one upgrade the Schema if there are no admins? Effectively AD becomes read only or frozen in a point in time? Does zero admins come with the caveat that the built-in admin account is always still there; but no on company directory admins?Anonymous
November 20, 2015
I maintain a list of links I call "security stuff every Microsoft customer should know" that