Why 60% of AD Audits Miss Critical Groups Before a Merger

When a PE firm acquired a $340M manufacturing company in Q1 2025, their IT due diligence team handed them a clean report. AD forests were mapped. Privileged accounts were identified. Service accounts were catalogued.

Three months post-close, the integration team discovered that 23% of the target’s domain admins weren’t listed in any audit — they were nested group members, invisible to a flat LDAP query.

This is not an edge case. It is the norm.

The Nesting Blind Spot

Standard AD audits query the Members attribute of groups. They do not recurse. A query for Domain Admins returns only direct members. But in virtually every mature AD environment, the actual membership list looks like this:

Domain Admins
├── john.smith@acquirer.com (direct)
├── CN=IT Privileged,OU=Groups,DC=target,DC=com  ← nested group
│   └── CN=Service Accounts,OU=Groups,DC=target,DC=com  ← nested again
│       └── mssql-svc, krbtgt, adfs-svc  ← invisible to flat query
├── CN=Finance Desktop Admins,OU=Dept,DC=target,DC=com  ← nested
│   └── (23 workstations, each with local admin rights)

A flat query finds 1 member. The actual blast radius is 47 identities.

The Module-Level View ACQI Provides

ACQI’s AD discovery runs recursive group membership enumeration across all discovered OUs and security groups. It catches:

• Nested Enterprise Admins — groups that grant forest-level rights without appearing in domain admin lists
• SID History abuse vectors — accounts that retain old SIDs from prior acquisitions (a major finding in multi-deal PE roll-ups)
• ACL inheritance breakage — OUs where permissions have been explicitly blocked, creating invisible security boundaries
• Password not required / reversible encryption — legacy settings on service accounts that create NTLM fallback vectors
• Foreign security principals — group members from trusted domains that may include accounts outside your jurisdiction

The 15-Point AD Pre-Close Checklist

Run this before any deal closes:

Privileged Identity (4 items)

1. Enumerate all users with Direct Domain Admin membership
2. Recurse all security groups — find nested groups with DOMAIN\USERS or DOMAIN\ADMIN rights
3. Enumerate all Enterprise Admins (forest-level) and confirm each is authorized
4. Check SID History attribute on all user accounts added post-2018

Service Accounts (4 items) 5. List all accounts with SPN (Service Principal Name) registered — these are kerberoast targets 6. Check password last set date on all service accounts — any over 90 days may be unmaintained 7. Enumerate accounts in “Pre-Windows 2000 Compatible Access” group 8. Find all accounts with “This account supports AES 128/256 encryption” disabled (weak Kerberos)

Group Policy Objects (3 items) 9. Audit GPO links at the site, domain, and OU level — unlinked GPOs often indicate abandoned security policy 10. Enumerate GPOs that apply to the Domain Controllers OU specifically 11. Check for any GPO with disabled or deleted security filtering (means it applies to nothing or everything)

Trust Relationships (2 items) 12. Document all inbound and outbound forest trusts with authentication settings 13. Check SID Filtering (quarantine attribute) on all external trusts

Privileged Group Membership (2 items) 14. Alert on any account added to Backup Operators or Network Configuration Operators in last 180 days 15. Compare current DNS Admins, Server Operators, and Print Operators lists against baseline — these are often overlooked but give equivalent Domain Admin access via different vectors

Why Standard Tools Miss This

BloodHound, by default, collects group membership through the Members attribute. It does not automatically recurse through nested groups unless you run path-finding algorithms. A standardBloodHound collection without explicit nesting queries will under-report privileged group membership by 40-70% in organizations with deep OU structures.

ADExplorer (Sysinternals) shows you the tree, but you have to manually expand every group to see nested membership.

PowerShell’s Get-ADGroupMember with -Recursive flag works, but only on groups you know to query — it won’t tell you which groups contain other groups.

ACQI runs this as an automated module, across both the target and acquiring company’s AD environments simultaneously, surfacing the delta that no manual audit finds.

The Real Risk: The Account You Don’t Know About

In the manufacturing company case, the 23 undiscovered admins included a service account being used as the effective “break glass” account for the domain — one that had permissions to reset any other account including Domain Admins.

It wasn’t malicious. It was a backup sysadmin setup in 2014 that nobody documented.

Post-merger, it was granted the same access in the consolidated forest. The acquirer had no idea it existed.

That’s the 60%. The accounts that aren’t in any report because nobody knew to look for them.

Run recursive. Run deep. Or run blind.