The headline number sounds manageable. Two companies, each with their own AD forest, merging into one.
Then you run the discovery and find: Company A has 31,000 user accounts. Company B has 16,200 user accounts. Combined headcount is 22,000 people.
The gap — 25,000 accounts that aren’t people — is the consolidation problem. Service accounts. Shared mailboxes. Application identities. Security principals used by systems. Test accounts. Orphaned accounts from the company’s own prior acquisitions.
Consolidating this at enterprise scale requires a methodology, not just goodwill.
Why Account Matching Is Not as Simple as It Sounds
The instinct is to match accounts by email address or UPN. Two users, same name, same email — same person, migrate one to the target forest.
It’s never that clean.
The UPN suffix problem: Company A uses acquirer.com as UPN suffix. Company B uses target.com as UPN suffix. After consolidation, everyone needs mergedcompany.com as their UPN suffix. But some applications have UPN hardcoded in configuration. Changing the UPN breaks those apps.
The name collision problem: Two users — John Smith at acquirer, John Smith at target. Different people, same display name, same UPN prefix. When forests merge, one has to change. Users who have been John.Smith@target.com for 12 years suddenly become John.Smith.alt@mergedcompany.com — breaking email signatures, Teams presence, and any system that uses the UPN as an identifier.
The SAMAccountName collision problem: SAMAccountName has a 20-character limit and must be unique within the domain. JSmith from both companies can’t coexist. The resolution process is manual for non-trivial cases, and requires application owners to sign off on the new name.
The SID History Problem
SID History is the mechanism that preserves access during AD migration. When a user migrates from SourceForest to TargetForest, their original SID is written to the SID History attribute in the target forest. This allows them to access resources that were ACL’d to their original account.
The risk: SID History is a privilege persistence mechanism. An attacker who gains access to an account with SID History can potentially access resources across forests, including resources in the source forest that shouldn’t be accessible anymore.
In a PE roll-up scenario — where Company A has acquired Companies B, C, and D over five years, each with SID History preserved — you may have SIDs from four different forests in the consolidated account. If any one of those source forests had compromised accounts, those SIDs still grant access in the consolidated forest.
ACQI’s approach: Enumerate SID History on all accounts in the consolidated forest. Flag any account with SID History from a source domain that has been decommissioned. Compare SID History contents against current forest ACLs to identify over-permissioned accounts.
Service Account Matching: The Hardest Problem
Service accounts are where consolidation gets truly complicated.
A service account has three identities that need to be tracked simultaneously:
- The AD account (
DOMAIN\service_account) - The SPN (Service Principal Name) registered to that account
- The credential (password or certificate) used to authenticate
During consolidation:
- The AD account moves to a different OU and potentially a different domain
- The SPN may need to be re-registered if the account’s DN changes
- Any application that uses the account’s credential needs to be updated with the new credential location
For a 47,000-account environment, this is weeks of work for the integration team.
The ACQI module: Discovers all service accounts across both forests, identifies their SPNs, maps them to the applications and servers that use them, and estimates the credential update blast radius for each account. This becomes the integration work backlog — sorted by business criticality.
Certificate and SPn Reconciliation
Service accounts that use certificate-based authentication (certmap accounts in AD) require the certificate’s Subject Alternative Name to match the account’s UPN. When the UPN changes during consolidation, the certificate breaks.
The resolution: re-enroll the certificate from the CA (if the CA is in the target forest) and update the certmap configuration. If the CA was in the source forest and is being decommissioned, this becomes a certificate chain re-issue — which needs to happen during a maintenance window.
SPNs (Service Principal Names) are registered in the M365 tenant separately from AD. When the AD account is migrated, the corresponding SPN in Entra ID may or may not automatically update, depending on how Azure AD Connect is configured. SPN mismatches cause app authentication failures that are notoriously hard to diagnose — the app fails silently and the user gets a generic “access denied” error.
The Integration Sequence
For a 47,000-account consolidation, this is the sequencing that works:
Phase 1 (Weeks 1-4): Discovery — ACQI runs across both forests simultaneously. Accounts are categorized: human users, service accounts, application identities, privileged accounts, orphaned accounts. Each category gets a different migration path.
Phase 2 (Weeks 5-8): Matching — Human users are matched across both forests by employee ID (if available), or by a probabilistic match on name + department. Name collisions are resolved with UPN suffix strategy. SID History is documented.
Phase 3 (Weeks 9-16): Service Account Migration — Service accounts are migrated in dependency order. The rule: migrate the provider before the consumer. If App A depends on Database B, migrate Database B’s service account before App A’s. This prevents cascading failures.
Phase 4 (Weeks 17-24): Human User Migration — Users are migrated in waves by department, starting with IT (so the migration team has full access during the migration window). SID History is preserved for 90 days post-migration, then selectively reviewed and removed.
Phase 5 (Weeks 25-52): Cleanup — Unmatched accounts from the source forest are disabled (not deleted — litigation hold may require access). SID History is audited and pruned. Certificate stores are verified.
The Number That Matters
The 47,000 accounts that “become one” don’t actually become one account each. They become a consolidated forest where the integration team has full visibility into which accounts exist, what they do, and what breaks if they move.
That visibility is what ACQI provides in the discovery phase. The rest is execution.