AD computer adminCount triage: protected DCs versus member hosts

What is AD computer adminCount triage?

AD computer adminCount triage is the process of explaining why a machine-related directory object carries adminCount=1 before deciding whether anything needs to change. A domain controller, a service account and an ordinary member server can appear in the same candidate list while requiring very different decisions. The useful outcome is a classification backed by identity, membership and permission evidence.

Microsoft's Admin-Count schema reference describes an attribute associated with ACL protection following direct or transitive administrative-group membership. The marker alone does not establish current privilege, an attack path, or a stale ACL. Treat it as a reason to investigate the object rather than an instruction to clear a value.

This workflow produces a record for each SID: protected, justified exception, plausible residue, or indeterminate. It complements our user-account workflow for stale adminCount cleanup, which explicitly asks readers to classify computers and groups separately. Its user cleanup commands should not become a bulk maintenance recipe for machines.

How protection affects DCs, RODCs and other objects

Microsoft's Appendix C: Protected Accounts and Groups includes both Domain Controllers and Read-only Domain Controllers in the protected list. AdminSDHolder supplies template permissions, and SDProp compares protected-object permissions with that template. Protected objects have inheritance disabled; moving one into a different OU does not remove its protection.

A verified DC or RODC can therefore have a legitimate protection explanation. Establish its actual role and membership instead of treating every machine marker as accidental administrative access. For a member workstation or application server, investigate the current group paths and their business purpose. Neither its hostname nor its OU location is sufficient evidence of its role.

The collector's computer search also matters: it uses (objectClass=computer). At the reviewed revision, the parser explicitly recognizes msDS-GroupManagedServiceAccount within that population. A gMSA can consequently appear as a Computer finding without being an ordinary host. Confirm the returned structural class and service owner; do not grant it a blanket exception merely because it is a service account.

Microsoft's historical explanation of AdminSDHolder and SDProp documents residual markers and disabled inheritance after a user leaves protected membership. That explains why residue is a hypothesis worth testing. It does not establish that a particular computer is an orphan, and its older protected-group list should not replace current Appendix C. The same article describes protection through nested security or distribution groups, so a membership investigation should preserve those paths.

Detection: collect identity and independent directory evidence

Start with Get-ADComputer, whose documented parameters include -LDAPFilter, -SearchBase, -Server and -Properties. This adaptation requests the attributes needed to investigate computer candidates:

Get-ADComputer -LDAPFilter "(adminCount=1)" -SearchBase "DC=corp,DC=example" -Server "dc01.corp.example" -Properties adminCount,memberOf,primaryGroupID,PrimaryGroup,nTSecurityDescriptor,Enabled,SID,ObjectClass,userAccountControl

This independent query deliberately retains enabled and disabled results for classification. The EtcSec check discussed below selects enabled Computer entries only. Record enabled state explicitly when reconciling the two populations; a difference in scope is not necessarily a discrepancy in the marker.

Use SID and DN to match the finding to the directory object. Preserve its GUID as another identifier, its class, the queried domain and server, capture time and any failed reads. Keep raw attribute evidence rather than only a formatted screen listing. An empty result from a narrower search base does not resolve a finding collected elsewhere.

For a candidate suspected to be a gMSA, use a class-neutral read of the exact DN. Get-ADObject documents DN identity and additional properties:

Get-ADObject -Identity "CN=svcInventory,CN=Managed Service Accounts,DC=corp,DC=example" -Server "dc01.corp.example" -Properties objectClass,objectSid,adminCount,memberOf,primaryGroupID,nTSecurityDescriptor,userAccountControl

Compare that identity with the finding before selecting the host or service-account review path. A failed computer-specific lookup must not silently discard an object returned by the collector's broader class filter.

Remediation: classify each object before approving changes

Step 1 — Establish the protected-group reference

Resolve the applicable Appendix C groups in the relevant domains and forest root, recording their SIDs and DNs. Names can be renamed or localized. Microsoft's SID reference explains domain identifiers and relative identifiers; use verified group identities instead of a name-only comparison.

Get-ADGroup accepts a SID for -Identity and supports additional properties. This documented adaptation reads the built-in Administrators group in an explicit domain context:

Get-ADGroup -Identity "S-1-5-32-544" -Server "dc01.corp.example" -Properties memberOf,groupType

Repeat for the applicable protected groups using their verified SIDs. This example is one lookup, not a complete protected-group inventory. Separate directly protected accounts from membership groups, and record relevant domain configuration exceptions. An unresolved reference group leaves the investigation incomplete.

Step 2 — Resolve membership beyond the first view

Get-ADPrincipalGroupMembership supports computers, groups and service accounts. The example SID is a placeholder for the candidate's verified SID:

Get-ADPrincipalGroupMembership -Identity "S-1-5-21-111111111-222222222-333333333-1101" -Server "dc01.corp.example"

Microsoft documents that the group search requires a global catalog and that local groups in another domain require the appropriate resource context. Record non-terminating errors as failures to resolve membership, rather than accepting a partial output as a clean result. Query the relevant resource domains when the object has memberships there.

Use the returned groups and the object's memberOf evidence as starting points. For each group, read its parents with Get-ADGroup -Properties memberOf,groupType and continue until the paths terminate or reach the verified protected set. Preserve intermediate identities, handle cycles, and cover the domains concerned. A single cmdlet invocation is not presented here as a complete validated transitive traversal.

Step 3 — Resolve the primary group separately

Microsoft's primaryGroupID protocol reference explains that primary membership is omitted from the object's memberOf and the group's ordinary member list. The Get-ADComputer documentation also shows PrimaryGroup and primaryGroupID in its computer output.

Read one verified computer again and resolve its primary-group DN independently:

$machine = Get-ADComputer -Identity "CN=APP01,OU=Servers,DC=corp,DC=example" -Server "dc01.corp.example" -Properties PrimaryGroup,primaryGroupID,memberOf,adminCount,nTSecurityDescriptor

Get-ADGroup -Identity $machine.PrimaryGroup -Server "dc01.corp.example" -Properties memberOf,groupType

Run the second read only when PrimaryGroup was successfully resolved. If only the RID is available, construct the primary-group SID from the verified account-domain SID and that RID, then resolve the full SID. Do not substitute the full computer SID or assume an expected primary group from the machine's role. Review the primary group's own parent paths as well. Missing or conflicting evidence keeps the case indeterminate.

Step 4 — Examine object and parent permissions

Preserve the security descriptor and review inheritance, ownership and explicit ACEs. Compare the object with its intended role and parent baseline. Permission protection can be legitimate; conversely, a familiar marker does not explain a suspicious explicit grant.

The Microsoft Dsacls reference documents displaying the ACL and using /A to add ownership and auditing information. These are separate read operations:

dsacls "\\dc01.corp.example\CN=APP01,OU=Servers,DC=corp,DC=example" /A

dsacls "\\dc01.corp.example\OU=Servers,DC=corp,DC=example" /A

An access failure means the requested evidence is unavailable. A text capture is an investigation artifact, not a guarantee of a restorable backup. Establish the approved restoration method before any later ACL maintenance.

Our computer-object review of rights, delegation and dangerous groups explains the broader machine attack surface. Those exposures require their own evidence: adminCount=1 alone proves none of them. Keep the object's ACL, its memberships and any rights it holds elsewhere distinct in the review record.

Step 5 — Record the decision and validate the intended outcome

A justified exception is a business decision; it does not make a protected object unprotected. Plausible residue is an investigative classification, not permission to perform cleanup. Route any proposed membership or ACL change through the machine or service owner with the captured baseline and expected final permissions.

After approved maintenance, repeat the identity, membership and ACL reads on recorded servers. Account for directory replication and, where protection applies, observe the subsequent SDProp result under the configured schedule. Record success or failure and test the intended administration or service behavior. Do not repeatedly clear a marker to suppress an unexplained result.

How EtcSec Detects This

At collector revision 9f698083354a1cb7f625df5cb490a515823c3257, the reviewed COMPUTER_ADMIN_COUNT check iterates collected Computer entries, skips disabled entries and selects those whose AdminCount boolean is true. It emits an Info finding with the selected count; affected-entity details are included only when details were requested and candidates exist.

The LDAP parser sets that boolean only when the returned adminCount value equals 1. An absent or non-1 value becomes false in that representation. The check does not exclude DCs, RODCs or gMSAs, resolve direct, transitive or primary-group membership, or examine ACLs. It therefore supplies candidates for classification rather than a verdict of stale protection or dangerous privilege.

The computer provider does not request primaryGroupID or nTSecurityDescriptor in its default attribute list. Their absence from this collection must not be interpreted as absent groups or rights. BaseDN and MaxComputers constrain the collected population; a GetComputers error stops collection. The detector still returns an Info finding with a zero count when it has no selected candidates, so the presence of the finding type alone is not evidence of a hit.

Reconcile the audit scope and candidate identities with the independent reads above. Use the classification record to explain legitimate protection, escalate unresolved hosts and preserve uncertainty. Rerunning the audit can compare the scoped candidate list with that record, but cannot replace membership resolution or permission validation.