dMSA migration: when to proceed, stop, and recover

Do not sign off a dMSA migration because the application still works during the start phase. Completion disables the old account. Accept the change only after fresh authentication proves the completed configuration works. Microsoft overview

A delegated Managed Service Account (dMSA) replaces a traditional service account’s reusable password with managed, randomized keys and ties authentication to approved computer identities. This guide provides change-review recommendations, not findings about your environment. Documentation baseline: 14 September 2026; date deployment checks separately. How dMSA works

What to do before booking the change

• Confirm support for the account, every host, and the actual application topology.
• Verify security updates and remove unjustified account-control permissions.
• Inventory all uses of the old identity, including recovery systems and occasional jobs.
• Test required authentication paths and confirm replication across relevant sites.
• Rehearse completion and both recovery scenarios; name the people responsible.
• Agree on a validation deadline and the failures that trigger recovery.

Use this decision table at the change review. Approval to complete and acceptance of the result are separate decisions.

Passing the preparation checks permits controlled completion; production acceptance requires evidence collected afterward.

Confirm support and control

Start with a traditional service account. Migration from an existing managed service account, including a group Managed Service Account (gMSA), is unsupported. Migration limitations

Microsoft’s account comparison excludes applications on multiple servers or behind a load balancer, but its migration instructions discuss multiple devices. For shared services, clusters, or load-balanced applications, obtain Microsoft and application-vendor confirmation for the actual topology, operating systems, and builds. Account comparison, Migration instructions

Use Windows Server 2025 as the documented setup baseline; require explicit support evidence for other systems. Record host editions, versions, full builds, and cumulative updates. Verify the effective Kerberos client policy, including DelegatedMSAEnabled as DWORD 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Check the Key Distribution Service (KDS) root key, migration permissions, and two-way forest trust where applicable. Setup prerequisites

Identify the writable Windows Server 2025 domain controller (DC) used for migration. Map other DCs serving hosts during normal operation, site failover, and recovery; retain their build and support evidence. Migration requires writable-DC access. Migration requirements

Verify applicable fixes on every Windows Server 2025 DC, recording the installed update, running build, and date. KB5063878, build 26100.4946, is an August 2025 historical reference, not today’s approval target. Check the deployment’s required supported cumulative update and relevant known issues. Microsoft update record

Akamai reports that the CVE-2025-53779 patch closed the original BadSuccessor escalation path, but abuse remained possible with control over both the dMSA and target account. Review effective permissions across users, groups, and computers: creating or modifying dMSAs, migration links on both accounts, allowed devices, and control of authorized computer accounts. Include inherited permissions, group membership, organizational units, containers, ownership, and rights to change access rules. Remove unjustified control and audit sensitive changes. Patch and permission analysis

Build evidence during the start phase

Have the application owner approve an inventory from service settings, scheduled tasks, application records, and authentication logs. Include passive nodes, remote sites, maintenance, and infrequent jobs. Record each host’s Active Directory (AD) computer identity, purpose, effective policy, managed-password retrieval authorization, and test result. Investigate unexpected enrollment before completion. Host enrollment

Baseline service principal names (SPNs), which identify services in Kerberos authentication, resource permissions, delegation settings, authentication policies, and authentication-policy-silo membership—the account’s policy grouping. Test every endpoint, downstream resource, delegation flow, and relevant domain or forest boundary. Verify both obtaining and using Kerberos service tickets, the credentials presented to services, with the expected identity at the destination.

Compare expected completion attributes carefully. Microsoft documents SPNs, applicable delegation attributes msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity, authentication policy, and silo membership. “Auth for Delegation” means TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000), not the unconstrained-delegation flag TRUSTED_FOR_DELEGATION (0x80000). Completion behavior, Flag definitions

Unconstrained delegation lets a service act for users without restricting destination services. Microsoft warns it stops working after completion if the old account used it, and with Credential Guard protecting the dMSA. Stop if a required workflow depends on it, until a supported replacement passes testing. Delegation limitations

After Start-ADServiceAccountMigration, verify account links, dMSA state 1, and enrollment permissions. Wait at least 14 days after changing the security descriptor—the object’s access-control settings—before completion; Microsoft recommends 28 days in start. Record change dates and verify replication, meaning synchronization between DCs. Broken replication or isolated DCs require delay; later authorization changes require reassessing the observation window. Start and timing guidance

Enable Microsoft\Windows\Security-Kerberos\Operational. Event 307 identifies migration activity and the account pair; 308 records an enrollment attempt; 309 records a key-fetch attempt. Neither attempt proves success. Correlate accounts, hosts, timestamps, and serving DCs with authentication and application results. Event descriptions

Keep dated support, permission, host, replication, test, and recovery records, each with an accountable owner.

Complete, then prove the result

Rehearse completion in a representative controlled environment and document production differences. In the approved window, run Complete-ADServiceAccountMigration. Verify state 2, migrated attributes, removal of temporary enrollment permissions, legacy-account disablement, and removal of its SPNs. Check SPN uniqueness and replication; preserve the original account. Completion changes

For a supported topology involving multiple devices, manually update PrincipalsAllowedToRetrieveManagedPassword after migration ends. Record before-and-after permissions, compare effective access—including group access—with the approved host inventory, and resolve mismatches. Verify replication before fresh authentication and application tests from every approved host. Multiple-device requirement

Use controlled restarts or new sessions in the affected service context where appropriate. Existing valid tickets can preserve access after account disablement, so an old session proves little about cutover. Retain ticket-use evidence and destination results. Ticket validity

Trigger recovery if required functions, attributes, permissions, or replication fail acceptance within the agreed window. Acceptance covers the inventoried hosts and tested functions on the recorded builds and configuration. After acceptance, monitor failed authentication, unexpected devices, and migration-link changes. Reassess when hosts, permissions, delegation, trusts, or topology change.

Rehearse the recovery destination

Test two scenarios. Aborting during start should restore the original configuration with accounts unlinked. After completion, decide whether recovery targets linked start or the original unlinked configuration.

Undo-ADServiceAccountMigration reverses one phase: start becomes unlinked; completed returns to start. Reset-ADServiceAccountMigration resets migration and unlinks accounts. Reaching the original configuration after completion therefore needs a separately validated unlink/reset step and any configuration restoration. Undo, Reset

For both scenarios, verify account enablement, SPN ownership, delegation, permissions, replication, and fresh application authentication. Retain account identifiers, initial and final states, commands, results, restoration steps, duration, and application-owner acceptance. Keep the original account for recovery. Recovery guidance

Three quick answers

Does event 309 prove usable keys arrived? No. It records an attempt; connect it to successful authentication and application results.

Can ticket policy justify a shorter wait? This guide provides no basis for shortening Microsoft’s 14-day minimum or 28-day recommendation. Record effective ticket-granting ticket (TGT) validity and renewal policies separately: their defaults are 10 hours and seven days. TGT validity, Renewal window

Does a successful recovery command finish the job? No. Recovery ends when the rehearsed target state and application checks pass.