Remediating stale adminCount=1 accounts: What should be verified before clearing adminCount and enabling inheritance?

Question

Hello,

I'm working on a PowerShell script to remediate stale protected accounts in Active Directory.

The script identifies user accounts that have adminCount=1 but are no longer members (including nested membership) of any protected administrative groups. The planned remediation is to:

Re-enable ACL inheritance.

Clear the adminCount attribute.

My question is:

Apart from verifying that the account is no longer a member of any protected group, are there any other Microsoft-recommended checks that should be performed before enabling inheritance and clearing adminCount?

For example:

• Should explicit/custom ACLs on the user object be reviewed?

Are there any scenarios where inheritance should not be re-enabled?

Is there any official guidance or best practice for safely remediating stale adminCount=1 accounts at scale?

I'd appreciate any recommendations, especially from those who have implemented this in production environments.Title:

Remediating stale adminCount=1 accounts: What should be verified before clearing adminCount and enabling inheritance?

Body:

I'm working on a PowerShell script to remediate stale protected accounts in Active Directory.

The script identifies user accounts that have adminCount=1 but are no longer members (including nested membership) of any protected administrative groups. The planned remediation is to:

Re-enable ACL inheritance.

Clear the adminCount attribute.

My question is:

Apart from verifying that the account is no longer a member of any protected group, are there any other Microsoft-recommended checks that should be performed before enabling inheritance and clearing adminCount?

For example:

Should explicit/custom ACLs on the user object be reviewed?

Are there any scenarios where inheritance should not be re-enabled?

Is there any official guidance or best practice for safely remediating stale adminCount=1 accounts at scale?

I'd appreciate any recommendations, especially from those who have implemented this in production environments.

Answer 1

The primary prerequisite is confirming that the account is no longer protected by AdminSDHolder. That means verifying it is not a direct or nested member of any protected administrative group and is not otherwise intended to remain protected. Simply checking direct group membership is insufficient.

Before re-enabling inheritance, review whether the object has intentionally configured explicit ACLs. Some organizations apply custom delegated permissions directly to privileged or service accounts. Re-enabling inheritance does not remove explicit ACEs, but inherited permissions may change the object's effective access. If your environment uses delegated administration, reviewing non-inherited ACEs before remediation is a sensible safeguard.

Also confirm the account is not a service account, legacy application account, or other account that administrators intentionally configured with adminCount=1 and protected permissions. Although stale adminCount values are common after group removal, exceptions do exist and should be identified before bulk remediation.

General guidance I'm familiar with is to remove the account from all protected groups first, then manually or programmatically re-enable ACL inheritance and clear the adminCount attribute. I'm not aware of any Microsoft-provided/supported process that automatically resets stale accounts after they leave protected groups because SDProp only applies protection; it does not remove it.

For large-scale remediation you'd want to follow a staged approach. Generate a report, validate the candidate accounts with administrators, back up or record the current ACLs, remediate a pilot group, verify the resulting permissions, and then expand deployment. Logging all changes and retaining a rollback plan is considered best practice.

I'm also not aware of any Microsoft recommendations to keep inheritance disabled once an account is no longer intended to be protected, unless you deliberately configured that object with unique security requirements. In most environments, stale adminCount=1 accounts should have inheritance restored so they once again receive permissions from their parent OU.

More at https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/reducing-the-active-directory-attack-surface and https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin