Identity Integration Playbook: AD Consolidation After an Acquisition

Active Directory consolidation is the highest-risk identity event in any M&A integration. Get it wrong and you lock out your entire user population. Get it right and you’ve built the foundation for everything that follows.

The complexity comes from three sources: the dependency graph is vast (everything authenticates to AD), the risk surface is wide (a failed AD migration affects every user simultaneously), and the planning horizon is long (AD restructuring decisions made in week 3 constrain options in week 18).

This playbook covers the decisions that matter, the failure modes that kill integrations, and the discovery-first approach that prevents both.

The Three AD Integration Patterns

Pattern 1: Full Forest Migration (No保留)

Move all identities from the source forest to the target forest. The source forest is decommissioned. All users get new accounts in the target forest with new SIDs, new UPNs, or both.

Use when: Both entities are being fully integrated. The acquired entity is no longer operating as a separate entity. The target forest has the capacity and the organizational structure to absorb the source identity population.

Risk: User experience disruption during transition. Applications that rely on SID history or specific SID values may break. Migration of group memberships requires careful mapping to preserve access.

Pattern 2: Forest Trust with Selective Migration

Establish a trust relationship between the source and target forests. Migrate selective workloads (usually by business function or geography) while maintaining source forest identity for non-migrated workloads.

Use when: The acquired entity needs to remain functionally separate for a period, or when full migration timeline is longer than business tolerance allows. Common in phased integration or when regulatory constraints require operational separation.

Risk: Trust relationships add authentication latency and complexity. Selective migration requires clear ownership of which identities go where and when. Orphaned accounts in the source forest are common when migration windows close without completing.

Pattern 3: Identity Mapping at the Directory Layer (No Migration)

Use Entra ID Connect or similar tooling to map source identities to target identities without migrating source accounts. Users keep source credentials, source SIDs are linked to target accounts via foreign security principals.

Use when: The source environment needs to remain intact (for regulatory reasons, operational continuity, or partial divestiture), but users need access to target environment resources.

Risk: Complexity in the identity mapping layer. Dual-home scenarios where a user has source forest credentials for some resources and target forest credentials for others. Licensing implications for Entra ID Connect in complex topologies.

Discovery Before Planning

Every AD consolidation plan starts with a discovery sprint. Without the following data, wave planning is guesswork:

Identity inventory

• All users in all forests: count, UPN patterns, sAMAccountName patterns, group memberships
• Service accounts: count, usage, associated applications, password policies
• Computer objects: count, age, last authentication, associated users
• Trust relationships: direction, authentication protocol, purpose

OU structure analysis

• OU hierarchy in each forest
• Group policy links at each OU level
• Which OUs contain user objects vs. computer objects vs. service accounts
• Delegation model: who has what permissions at which OU level

Application dependency map

• Applications that authenticate against AD (most do)
• Service accounts used by each application
• SPN registrations: which accounts are registered for which services
• Authentication protocols in use: NTLM vs. Kerberos vs. LDAP-signed

Security posture baseline

• Privileged account inventory: AD admins, domain admins, enterprise admins, schema admins
• Password policies per forest
• Audit policy configuration
• ACLs on sensitive OUs and containers

The UPN Decision

UPN restructuring is the decision that constrains everything else in the identity migration. There are two approaches:

Option A: Keep Source UPNs

Migrate users with their existing UPNs (or a variant — same root domain, different suffix). Users keep their email addresses, their M365 sign-in addresses, and their usernames. This is the least-disruptive option because the user-facing identity doesn’t change.

Use when: Email and M365 UPNs are the primary user identity. Disrupting those creates significant user experience and communications overhead.

Risk: If the source UPN domain is being retired post-merger, you need a UPN suffix strategy. Users with source UPNs in an deprecated domain after the domain is decommissioned will have authentication failures.

Option B: Target UPNs (New Primary Identity)

Migrate all users to target forest UPNs. Users get new usernames and new M365 sign-in addresses. This requires a legacy email alias strategy (usually: new primary address is target UPN, old address becomes a secondary alias) and a communications change management program.

Use when: The source domain is being retired as part of the integration. Target UPN domain is the future state and all users should be on it.

Risk: User change management is significant. Every user needs to know their new credentials. M365 licensing implications if email routing changes require license reassignment.

Option C: Hybrid (Phased Migration)

Early waves use source UPNs (low disruption). Later waves migrate to target UPNs. This requires managing two authentication paths simultaneously for a period.

The Group Membership Problem

Group membership migration is where most AD integrations hit unexpected failures. The problem: groups have SID-based membership, not name-based. When a user account migrates from source forest to target forest, it gets a new SID. The group membership that referenced the old SID is broken.

The solutions:

SID History: Migrate with SID history preserved. The new account in the target forest carries a record of the old SID. Applications that check SID-based access still work because the SID is present in the new account’s token. This is the most common approach and the most reliable — but it requires Enterprise Admin rights in the target forest and careful management of SID history expiration.

Group mapping table: Build a mapping table of source group to target group and use it during migration to re-establish membership. This requires more manual planning and testing, but doesn’t require SID history. Use when SID history is not available (some acquisition structures, some regulatory constraints).

Foreign Security Principals (FSP): Source forest accounts appear as FSPs in the target forest’s groups. This is a valid approach but creates a maintenance burden — FSPs don’t update automatically when source accounts change, and orphaned FSPs are a common post-migration issue.

The Cutover Execution

AD cutover is high-risk because it’s atomic: the moment you switch authentication to the target forest, all applications that rely on AD authentication are affected simultaneously. There’s no selective cutover for AD the way there is for other workloads.

Pre-cutover validation checklist

Before the cutover window:

• All source domain controllers’ DNS records point to target domain controllers (if using trust-based authentication)
• All applications have been tested against target domain authentication
• All service accounts have been migrated or mapped
• SID history has been verified on all migrated accounts
• Group memberships have been verified with SID history
• Rollback procedure documented and tested
• Monitoring dashboards live: AD authentication latency, ticket volume, application error rates

Post-cutover validation

Immediate post-cutover (first 15 minutes):

• Core business applications accessible
• Email authentication working
• M365 sign-in functional
• Network file shares accessible
• Network printer access confirmed

Hours 1-4:

• Ticket volume trending normally
• No spike in password reset requests (sign of authentication failure)
• Application error rates at baseline

Days 1-3:

• Monitor for authentication latency spikes
• Watch for service account failures (often surface after business hours when batch jobs run)
• Check for ACL propagation issues on file shares and SharePoint

Common AD Migration Failures

Failure 1: Service account discovery gap

Service accounts used by applications are discovered late — often after cutover, when applications fail to start. Service accounts are frequently undocumented because they’re set up by application teams, not by AD administrators.

Discovery fix: Run AD discovery modules including service account enumeration and SPN scanning before planning begins. Cross-reference with the application’s team to confirm every service account’s usage and migration path.

Failure 2: SID history collision

When SID history exceeds the target forest’s SID history quota (by default, 500 SIDs per account), authentication failures begin. This happens in large migrations where many accounts carry extensive SID history.

Fix: Monitor SID history quota during migration. Some accounts may need to be migrated without full SID history if they approach the limit.

Failure 3: UPN mismatch after M365 licensing

If M365 licensing uses the UPN but the license assignment uses the email address, there’s a mismatch that can cause licensing errors post-migration. Verify that all licensed users have the correct UPN in M365 before completing the migration.

ACQI’s AD discovery modules scan all forests, all OUs, all service accounts, and all SPN registrations before planning begins. Avoid the discovery gap that kills AD migrations. Request a discovery sprint →