Day 1 of a post-merger integration. 9:00 AM. The M&A integration team comes in, runs the AD sync between the two forests for the first time — and the payroll system stops processing.
Not because of a bug. Because the service account password wasn’t rotated before the merger, and when the two AD forests tried to establish trust, the target company’s AADC (Azure AD Connect) service account in the source forest got locked out.
Sound specific? This exact scenario has happened in at least three high-profile M&A integrations in the past 18 months. It’s not a hypothetical.
Why Service Account Passwords Don’t Get Rotated
In normal operations, service account passwords are rotated on a schedule — or they’re not. Most organizations have a mix. The ones that aren’t rotated on schedule accumulate in environments where touching anything that works feels like a risk.
The problem is compounded in M&A because the service account discovery problem that exists in any single organization is doubled when two organizations merge. Neither company necessarily knows about all of the other company’s service accounts. And the accounts in the overlap — service accounts in the target company that are used by the acquiring company’s systems — are the most dangerous.
The Three Failure Modes
Failure Mode 1: Authentication Failure Cascades
A service account’s password expires. The service that uses it fails. In a standalone environment, the failure is contained. In a post-merger environment, the service might be part of a dependency chain: AADC sync fails → identity data goes stale → SSO breaks for migrated users → the M365 environment starts returning errors for the acquired company’s users.
The discovery issue: in the two weeks before Day 1, the integration team was focused on the large, visible systems. Service accounts running as scheduled tasks on individual servers were not on anyone’s radar.
Failure Mode 2: Password Change Mid-Flight
Someone does proactively rotate a service account password — but the password is updated in AD and not in the application that uses it. This is the more common failure mode. A sysadmin sees that the password is aging and rotates it, but the password in the SQL Server connection string (or the batch scheduling tool, or the monitoring system) isn’t updated.
In normal ops, this is a single-service outage. In a merged environment, it might affect a system that bridges two companies.
Failure Mode 3: Trust Relationship Password Changes
When two AD forests establish an interforest trust, the trust account (the machine account for the trust relationship) has a password that auto-rotates every 30 days. If the trust password fails to sync — because the PDC emulator in the source forest is unreachable — the trust breaks. And a broken trust means no AD authentication across the two forests.
This one is rare and catastrophic. It requires both forests’ AD infrastructure to be reachable during the trust password rotation window.
The 72-Hour Discovery Sprint
Before Day 1, run this sprint to find all service accounts and their rotation status:
Hour 0-24: ADSI Edit scan — Connect to the source forest with ADSI Edit and enumerate all accounts where userAccountControl has the PASSWD_NOTREQD bit set (flagged as not requiring a password) and accounts where pwdLastSet is 0 (requiring password change at next logon). These are the highest-risk accounts.
Hour 0-24: SPN scan — Query all accounts with registered SPNs using:
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, passwordLastSet, pwdLastSet, enabled
These are the accounts that Kerberoast attacks target, and they’re also your most business-critical service accounts.
Hour 24-48: Scheduled Task enumeration — On every domain-joined server, enumerate all scheduled tasks that run as a specific user. Any scheduled task running as a domain service account is a dependency you need to document:
Get-ScheduledTask | Where-Object {$_.Principal.UserId -like "*DOMAIN*"} | Select-Object TaskName, Principal.UserId, State
Hour 48-72: Application service account mapping — For every major application (ERP, CRM, payroll, identity systems), document the service account used for the Windows service and the SQL Server connection. Many applications run under a named service account that is provisioned in AD specifically for that application.
ACQI’s contribution: The platform runs all four of these discovery passes across all servers and both forests simultaneously. It produces a single service account registry — organized by criticality and blast radius — in under 4 hours.
The Password Rollover Playbook
Once you’ve identified all service accounts, you need to rotate passwords before Day 1. The sequence matters:
Step 1: Sort accounts by blast radius. A service account used by a single application on one server is low-risk to rotate. A service account used by a multi-region ERP system that runs on 12 servers in 3 data centers is high-risk — rotate this one last, with a full change freeze window.
Step 2: For high-risk accounts, find the full list of dependencies before touching the password. Use dependency modeling — what servers, services, applications, and scheduled tasks use this account? You need a complete picture before the change, not after the outage.
Step 3: Rotate passwords in a change window, during low-activity hours. Update the password in AD first. Then update the credential in all dependent systems in parallel — use a credential manager (CyberArk, BeyondTrust, Thycotic) to push the updated credential to all registered targets simultaneously.
Step 4: Test. The test isn’t “did the service restart.” The test is “can users in both forests authenticate to all integrated applications.”
The Hidden Risk in Plain Sight
Service accounts are not exotic. Every company has them. The average mid-size enterprise has 400-800 service accounts across their AD environment. In a merger of two mid-size companies, you’re looking at 800-1,600 service accounts — and at least 20% of them won’t have been rotated in the last 90 days.
That’s the Day-One bomb. Not glamorous. Not in any deal model. But it will take down payroll.