How to find service accounts with Domain Admin rights: nested groups, equivalent rights and safe removal

Service accounts end up in Domain Admins because an installer asked for it or a fault was fixed in a hurry, and they then sit there for years with a password that never changes and an SPN that anyone in the domain can request a ticket for. This guide shows how to find every service account that holds Domain Admin rights or their equivalent: direct and nested membership of the protected groups, leftovers flagged by adminCount, and domain-level permissions such as replication rights that give the same result without any group. It then covers how to work out what each account really needs and how to remove the privilege without an outage. It is for Active Directory administrators, identity teams and security engineers. It assumes you know the basics in the Service Account Security Guide.

Key takeaways

• Domain Admins should be nearly empty: Microsoft's guidance is that Domain Admins membership should be needed only for build or disaster recovery, with no day-to-day accounts except a secured built-in Administrator. Any service account in it is a finding.
• Treat the top three groups as one: Microsoft states that Enterprise Admins, Domain Admins and Administrators should be considered effectively equivalent in potential privilege, so search all three, and the other protected groups, not only Domain Admins.
• Nesting hides membership: use Get-ADGroupMember -Recursive or the LDAP in-chain matching rule 1.2.840.113556.1.4.1941, because a service account added to a helpdesk group nested in Administrators does not appear in a direct member list.
• Rights can exist without groups: replication rights on the domain object let an account run DCSync (ATT&CK T1003.006) and pull every password hash, which is Domain Admin in effect. Check the domain ACL as well as groups.
• Remove privilege in stages: delegate the specific rights the service needs, test, then remove group membership, and watch logons and failures before you call it done.

When you need this

• Privileged access review: privileged service accounts are often excluded from people-focused reviews. See the Privileged Access Management Guide.
• Kerberoasting exposure: a privileged service account with an SPN and a human-set password is the classic target of Kerberoasting (T1558.003). See the Kerberoasting and AS-REP Roasting Defence Guide.
• Before migration to gMSA: knowing which accounts hold privilege tells you which conversions need the most care. See How to convert AD service accounts to gMSA.
• Incident response: after a domain compromise, every privileged service account is a credential to reset and a persistence route to check. See the Active Directory Domain Compromise Playbook.

Before you start

• Tools: the Active Directory module for Windows PowerShell (RSAT) on an administrative workstation, or any LDAP client. All discovery steps are read-only and work with an ordinary domain user account, because group membership and most ACLs are readable by authenticated users.
• Scope: every domain in every forest you run, including resource forests and domains reached through trusts. Enterprise Admins and Schema Admins live in the forest root domain.
• A definition of service account: accounts with a servicePrincipalName, managed service accounts (msDS-ManagedServiceAccount and msDS-GroupManagedServiceAccount object classes), accounts in your service account OUs, and accounts matching your naming convention. Record which rule matched.
• A findings register: account, how it is privileged (group path or ACL), SPNs, pwdLastSet, lastLogonTimestamp, password never expires flag, hosts it logs on to, application owner and decision. The Service Account Inventory Template has a suitable layout.
• Change approval for remediation: removing privilege from a running service is a production change with an application owner.

Step-by-step

1. Know which groups and rights count as Domain Admin

2. List recursive members of each privileged group (read-only)

1. For each group, run Get-ADGroupMember -Identity "Domain Admins" -Recursive. Microsoft documents that -Recursive returns all members in the hierarchy of the group that do not contain child objects, so nested groups are flattened to their users and computers.
2. Repeat for Enterprise Admins and Schema Admins in the forest root, Administrators, and the other protected groups in the table.
3. Also record the direct member list without -Recursive, so you know which nested group each account came through. That nested group is usually what you remove, not the account.
4. For large domains or non-Windows tooling, query LDAP with the in-chain rule. With the base set to the domain and subtree scope, the filter (&(objectCategory=person)(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=example,DC=com)) returns all users that are direct or nested members. Microsoft notes that in-chain queries with high fan-out are more processor intensive, so run them off-peak.

3. Pick out the service accounts

1. For each member, read servicePrincipalName, objectClass, userAccountControl, pwdLastSet, lastLogonTimestamp, description and the OU from distinguishedName.
2. Flag as a service account anything with an SPN, any managed service account, anything in a service account OU and anything matching your naming convention.
3. Flag the password never expires bit with the bitwise rule: (userAccountControl:1.2.840.113556.1.4.803:=65536) (DONT_EXPIRE_PASSWORD).
4. Flag accounts that are not service accounts by any rule but log on as a service on servers. Interview the server owner: these are often user accounts repurposed for a service.

4. Find leftovers with adminCount

Microsoft defines adminCount as indicating that an object has had its ACLs changed to a more secure value by the system because it was a member of an administrative group, directly or transitively. Query (&(objectCategory=person)(adminCount=1)), or Get-ADUser -LDAPFilter "(adminCount=1)" -Properties servicePrincipalName,memberOf, and compare with the recursive members from step 2. Accounts with adminCount=1 that are no longer members were privileged at some point: they tell you the history, and they still carry the protected ACL with inheritance disabled, which can break delegated management. The AdminSDHolder, SDProp and Protected Groups Guide covers how SDProp sets this and how to clean it up.

5. Check rights that bypass groups

• Replication rights: read the ACL on the domain naming context head (for example with (Get-Acl "AD:DC=example,DC=com").Access) and list any principal granted the DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2) or DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) extended rights other than domain controllers and the built-in groups. A directory synchronisation account such as the Entra Connect account may legitimately hold them; anything else needs a documented reason.
• Control of privileged objects: list GenericAll, WriteDacl and WriteOwner entries on the domain object, AdminSDHolder and each privileged group. Graph tools that compute attack paths do this at scale. See the BloodHound and Active Directory Attack Path Guide.
• Domain controller access: check which service accounts are local administrators or have logon rights on domain controllers, and who can edit GPOs linked to the Domain Controllers OU.

6. Work out what each account really needs

Small environments with a handful of applications can usually resolve every account by interview in a few days. Large estates should rank by risk: SPN plus old password plus Domain Admin first, then accounts that log on to many hosts, then the rest.

7. Remove the privilege (destructive, change-controlled)

1. Delegate the specific rights identified in step 6 and test the application with them while the account is still privileged.
2. Destructive: remove the account, or the nested group it came through, from the privileged group with Remove-ADGroupMember. Group membership is evaluated at logon, so restart the service, or wait for its next logon, before you judge the result.
3. Reset the password to a long random value, or convert to a gMSA, because the old password may have been exposed while it was privileged.
4. Apply Microsoft's user rights pattern for Domain Admins on member servers and workstations (Deny access to this computer from the network, Deny log on as a batch job, Deny log on as a service, Deny log on locally, Deny log on through Remote Desktop Services), so any privileged account that remains cannot run services there.
5. Clean up adminCount and restore ACL inheritance on accounts that are no longer protected, following the AdminSDHolder guide.

Verify it worked

Events 4728, 4732 and 4756 record a member added to a global, local or universal security group. Microsoft recommends alerting on any change to the properties or membership of Domain Admins. See the Active Directory Security Monitoring Guide for the audit policy these events need.

Rollback and common errors

• Rollback is re-adding membership: keep the exact group and nesting path in the change record so you can restore it with Add-ADGroupMember, then restart the service. Remove it again once the missing delegation is found.
• Removing the account but not the nested group: if a nested group grants the privilege, other accounts in it keep it. Fix the nesting.
• Missing other domains: service accounts from a child domain can be members of Enterprise Admins in the forest root or of groups in a trusting domain.
• Trusting group membership alone: an account removed from every group but still holding replication rights or full control on the domain object is still effectively Domain Admin.
• Forgetting the password: an account that was privileged with a static password should be treated as exposed; changing its group does not change what an attacker holding the password could already have done.
• Expecting an immediate effect: tokens issued before the change keep the old group SIDs until the next logon, so a service may keep working with old rights until it restarts.

Hardening afterwards

• Use gMSA for services: automatic long passwords remove the Kerberoasting payoff. See the Group Managed Service Accounts (gMSA) Guide.
• Alert on membership changes: Microsoft recommends alerting on any modification to Domain Admins properties or membership; extend it to all protected groups.
• Deny privileged logons on member servers: keep the five deny user rights for Domain Admins in GPOs linked to server and workstation OUs, excluding jump servers as Microsoft notes.
• Tier service accounts: accounts that manage domain controllers stay in the control plane and never log on to ordinary servers.
• Repeat monthly: run the recursive membership, SPN and replication rights queries on a schedule and diff the results.

Practitioner checklist

• List recursive members of Domain Admins, Enterprise Admins, Administrators and the other protected groups in every domain.
• Record the nesting path for each member and identify service accounts by SPN, object class, OU and naming.
• Compare adminCount=1 accounts with current members to find leftovers.
• Read the domain head ACL for replication rights and control rights held by non-DC principals.
• Agree with each application owner what the account really needs and delegate it.
• Remove membership in a change window, reset or convert the password, and keep the rollback path recorded.
• Alert on 4728, 4732 and 4756 for protected groups and deny privileged logons on member servers.
• Repeat the queries monthly and after every application installation that asks for Domain Admin.

Standards and references

• Microsoft Learn: Appendix B, Privileged Accounts and Groups in Active Directory
• Microsoft Learn: Appendix C, Protected Accounts and Groups in Active Directory
• Microsoft Learn: Appendix F, Securing Domain Admins Groups in Active Directory
• Microsoft Learn: Get-ADGroupMember
• Microsoft Learn: Search Filter Syntax
• Microsoft Learn: Admin-Count attribute
• MITRE ATT&CK: T1003.006 DCSync
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: How to find and retire Active Directory service accounts with SPNs, Windows Service Accounts, gMSA and dMSA Guide, Identity Attack Paths Guide, Privileged Access Workstations Guide.