AD-ACC-006: adminCount set on accounts that are no longer privileged¶

low   Accounts   MITRE ATT&CK T1078.002   Reads: LDAP

Enabled users still have adminCount = 1 after leaving the protected groups: forgotten former admins whose frozen, non-inheriting permissions nobody reviews.

Also known as: admincount

Why it matters¶

Every hour the SDProp process copies the DACL of CN=AdminSDHolder,CN=System onto every member of a protected group, disables inheritance on it and sets adminCount = 1. When the account later leaves the group, nothing undoes this: the DACL stays frozen and inheritance stays off.

That leaves three problems:

• The account is usually a former administrator. It may still be local admin on servers, hold saved credentials or keep rights granted directly, and it is an obvious target: attackers list adminCount=1 to find admins.
• Any ACE that was on AdminSDHolder when the account was protected, including a persistence backdoor (see AD-ACL-002), is still on the account.
• Permissions delegated on the OU (help desk password resets, monitoring) do not reach it, so it drifts outside normal management.

How ad-doctor detects it¶

From the LDAP snapshot: every enabled user (computers and managed service accounts excluded) with adminCount = 1 that is not a transitive member of a tier-0 group. krbtgt and the RODC krbtgt_NNNNN accounts are skipped, since they are protected by design.

The tier-0 groups ad-doctor collects are Domain Admins, Schema Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Print Operators and Backup Operators, including membership through primaryGroupID.

Each object is the account's sAMAccountName, for example ex_admin.

Severity¶

Always low. The account is no longer privileged through group membership; the risk is what it may have kept (rights elsewhere, an old password, a backdoored DACL) and the fact that normal OU delegation no longer applies to it.

False positives and limits¶

• Members of protected groups ad-doctor does not collect. SDProp also protects Replicator, Key Admins, Enterprise Key Admins, Domain Controllers and Read-only Domain Controllers. A user in one of those legitimately has adminCount = 1; check memberOf before clearing it, or SDProp sets it again within the hour.

Fix¶

1. Confirm the account is not in any protected group (read-only):

   Get-ADUser ex_admin -Properties adminCount, memberOf, LastLogonDate, PasswordLastSet |
       Select-Object SamAccountName, adminCount, LastLogonDate, PasswordLastSet, memberOf
   

2. Review the account as a former admin: disable it if no one uses it, rotate its password, and look for rights it kept (AD-PATH-001 shows control paths to tier 0).

3. Clear adminCount. This is what ad-doctor fix generates:

   Set-ADUser ex_admin -Clear adminCount -WhatIf
   

4. Re-enable inheritance so OU permissions apply again:

   Import-Module ActiveDirectory
   $dn = (Get-ADUser ex_admin).DistinguishedName
   $acl = Get-Acl -Path "AD:$dn"
   $acl.SetAccessRuleProtection($false, $true)
   Set-Acl -Path "AD:$dn" -AclObject $acl -WhatIf
   

5. Remove explicit ACEs that were copied from AdminSDHolder and are not wanted on an ordinary user.

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ACC-006

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ACC-006"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

Related checks¶

• AD-ACL-002
• AD-ACL-005
• AD-PRIV-006
• AD-PATH-001

References¶

Microsoft and vendors

• Appendix C: Protected accounts and groups in Active Directory

Specifications

• Admin-Count attribute

Research

• Sneaky Active Directory Persistence #15: AdminSDHolder and SDProp (Sean Metcalf)

MITRE ATT&CK

• T1078.002

Available since 0.1.0.