Learn to adjust the AdminCount attribute in protected accounts

What is a privileged user and a privileged group?

Active Directory is a database and set of services with control over 12 object types, including domain controllers, users and printers. Administrators grant key users and groups powerful rights and permissions to manage these objects.

There are four built-in groups inside Active Directory that have higher privileges than any other group. Those privileged groups are the built-in Administrators group, Domain Admins, Enterprise Admins and the Schema Admins group. These groups have the highest level of privilege to change almost any other object in Active Directory.

In theory, someone could remove permissions from these groups either by accident or through malicious intent. They could remove the rights to make changes and you could lose control over Active Directory, throwing the database into a state of chaos. Since these privileged groups are so critical to Active Directory, they are also protected groups.

What are protected accounts?

Active Directory contains a set of accounts and groups that are core to the directory and cannot be removed. You cannot manage Active Directory without these default accounts and groups.

The Builtin container and the Users container in Active Directory contain many of these accounts. There are 10 built-in security groups -- Account Operators, Administrators, Backup Operators, Cert Publishers, Domain Admins, Domain Controllers, Enterprise Admins, Print Operators, Schema Admins and Server Operators -- and three protected accounts -- administrator, KRBTGT and replicator.

Protected groups have permission sets that cannot be changed easily; Active Directory automatically reverts any modifications back to their default permissions every hour. This automatic reset guarantees these protected groups never lose control of Active Directory or the ability to govern the other accounts.

What the values in the AdminCount attribute mean

A built-in process in Active Directory scans the built-in groups and flags the users in those groups as "special accounts," or administrative accounts that require different treatment from other accounts.

All Active Directory objects have a hidden attribute called AdminCount, which is set to Null by default. Accounts considered special have the AdminCount value set to 1, which disables inheritance on the object and sets the security on the object to be governed by the AdminSDHolder object.

You can set the AdminCount to 1 for any account in a domain. The special groups make it an automatic process, while other accounts require manual intervention either through a GUI tool or with PowerShell.

What are the AdminSDHolder object and SDProp process for?

Many admins might not know about the AdminSDHolder object in Active Directory, because it is not visible in the default view of the Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) snap-in. Enable advanced view to see the system partition, which holds a subcontainer called AdminSDHolder.

Right-click the container to view the security of the container. The permissions in this object are the default permission set placed on all accounts in any of the security groups as well as any account that has its AdminCount value set to 1.

You can change the security in the AdminSDHolder object by editing permissions with the ADSIEdit utility.

The AdminSDHolder object and the SDProp process combination protects the built-in security groups and the users in those groups from accidental permissions changes.

The AdminSDHolder object applies default permissions to the important groups. The SDProp process runs every 60 minutes; it compares the permissions on the domain's AdminSDHolder object with the permissions on the protected accounts and groups in the domain and resets changed permissions back to a standard set of permissions.

As an added security measure, Active Directory disables permissions inheritance on protected groups and accounts. Even if the accounts and groups move to another location in the directory, they do not inherit permissions from their new parent objects. Active Directory also disables inheritance on the AdminSDHolder object so permission changes to parent objects do not alter the permissions of AdminSDHolder.

What are the downsides of protected objects?

All this built-in protection is great, but what if you want to change the built-in permission sets? Organizations will have different needs to cover various scenarios, and sometimes the default permissions will need to be altered. It's nearly impossible to do this if you don't know how to update the AdminSDHolder permission set.

Also, when the AdminCount value changes from 0 to 1, that inheritance is removed from these objects. If you need these groups to inherit permissions from organizational units (OUs) or other methods, then this requires some serious effort. You can set the AdminCount to 1 on any account in the domain, but this enforces security measures on accounts you may not want affected.

Also, accounts with AdminCount set to 1 cannot have their passwords reset in the standard fashion. You either add reset password permission to the AdminSDHolder or follow best practices and create elevated accounts for those users and place those accounts in alternate OUs. I recommend following security best practices, but these processes can be complex to understand and implement in smaller IT shops that may not have a deep knowledge of Active Directory.

Protected Users group strengthens defenses for privileged accounts

Starting in Windows Server 2012 R2, Microsoft added a security group in Active Directory called Protected Users. This group takes security to another level. Users in that group have added protections to strengthen security on accounts and logins that cannot be cached for reuse.

The following protections apply for a signed-in user who is a member of the Protected Users group:

• Credential delegation (CredSSP) will not cache the user's plaintext credentials even if the Allow delegating default credentials Group Policy setting is enabled.
• Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user's plaintext credentials.
• NTLM authentication protocol will not cache the user's plaintext credentials or NT LAN Manager one-way function.
• Kerberos will no longer create DES or RC4 keys. Also, it will not cache the user's plaintext credentials or long-term keys after the initial Ticket Granting Ticket (TGT) is acquired.
• A cached verifier is not created at sign-in or unlock, so offline sign-in is no longer supported.

Accounts that are members of Protected Users that authenticate to a Windows Server 2012 R2 domain cannot:

• authenticate with NTLM;
• use DES or RC4 encryption types in Kerberos pre-authentication;
• be delegated with unconstrained or constrained delegation; or
• renew the Kerberos TGTs beyond the initial four-hour lifetime.

Use PowerShell to find protected accounts in Active Directory

There are a few ways to find protected accounts in your organization. Let's review the built-in administrator account properties.

Open the account in the ADUC MMC snap-in and go to the Attribute Editor. This view shows an attribute called AdminCount with a value of 1. This is a protected account, and the security is applied from the AdminSDHolder container.

The GUI is great for one-off lookups, but PowerShell is the more efficient tool for work that involves hundreds or thousands of accounts. The following PowerShell command checks the AdminCount attribute has a value of 1 and is therefore protected.

get-aduser administrator -prop admincount | select Name, Admincount

Name          Admincount
----          ----------
Administrator          1

The following query checks a standard user account, which shows the AdminCount is not set but has a value of zero.

get-aduser crivas -prop admincount | select Name, Admincount

Name   Admincount
----   ----------
CRivas

The following PowerShell commands set the AdminCount to 1 for an account in the domain and then output the AdminCount attributes.  

get-aduser CRIVAS -property admincount | set-adobject -Replace @{adminCount=1}

get-aduser crivas -property admincount | select Name, Admincount

Name   Admincount
----   ----------
CRivas          1

To find all objects set to AdminCount 1, PowerShell can help. Searches can be done with the LDAPFilter parameter or with a specific check for user accounts or group objects. Below are examples of each search criteria.

# Find all accounts with an LDAPFilter
Get-ADObject -LDAPFilter "(adminCount=1)"

# Find user accounts
Get-aduser -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

# Find group accounts
Get-ADGroup -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

The following code and resulting output reveal all accounts set to AdminCount = 1 in my lab environment.

Get-aduser -Filter *  -prop admincount, Canonicalname | where admincount -eq 1 | select Name, SamAccountName, AdminCount, Canonicalname

Name                     SamAccountName AdminCount Canonicalname
----                     -------------- ---------- -------------
Administrator            Administrator           1 mk.lab/Users/Administrator
mkadmin                  mkadmin                 1 mk.lab/Users/mkadmin
krbtgt                   krbtgt                  1 mk.lab/Users/krbtgt
DJacobs                  DJacobs                 1 mk.lab/TestUserAccounts/DJacobs
CRivas                   CRivas                  1 mk.lab/TestUserAccounts/CRivas

Find and flip the AdminCount value with PowerShell

PowerShell can save those results to a variable and loop through the accounts and flip the AdminCount from 1 to 0 or vice versa.

# find the users

Get-aduser -Filter *  -prop admincount, Canonicalname -searchbase "OU=TestUserAccounts,DC=mk,DC=lab" | where admincount -eq 1 | select Name, SamAccountName, AdminCount, DistinguishedName

Name    SamAccountName AdminCount DistinguishedName
----    -------------- ---------- -----------------
CRivas  CRivas                  1 CN=CRivas,OU=TestUserAccounts,DC=mk,DC=lab
DJacobs DJacobs                 1 CN=DJacobs,OU=TestUserAccounts,DC=mk,DC=lab

#rerun the query and save to a variable

$AdminCount = Get-aduser -Filter * -prop admincount, Canonicalname -searchbase "OU=TestUserAccounts,DC=mk,DC=lab" | where admincount -eq 1 | select Name, SamAccountName, AdminCount, DistinguishedName

# Take the users in $AdminCount and change the AdminCount from 1 to 0

$AdminCount | Foreach-Object {set-adobject $_.DistinguishedName -Replace @{adminCount=0}}

#now let's see what the results are - Admincount has been set to 0
Get-aduser CRIVAS -prop admincount | select Name, SamAccountName, AdminCount, DistinguishedName

Name   SamAccountName AdminCount DistinguishedName
----   -------------- ---------- -----------------
CRivas CRivas                  0 CN=CRivas,OU=TestUserAccounts,DC=mk,DC=lab


Get-aduser DJACOBS -prop admincount | select Name, SamAccountName, AdminCount, DistinguishedName

Name    SamAccountName AdminCount DistinguishedName
----    -------------- ---------- -----------------
DJacobs DJacobs                 0 CN=DJacobs,OU=TestUserAccounts,DC=mk,DC=lab

Privileged accounts and protected users help administrators stop malicious behavior, accidental account lockouts and mistakes in security permissions. It takes time to learn these concepts to fully utilize them.

Once you understand how they work, implement the best security practices as outlined by Microsoft and document your changes. This will help you when you revisit the settings to understand why certain changes were made.