Topic starter
25/06/2026 1:12 am
TL;DR: Semperis' analysis of BadSuccessor finds writable delegated Managed Service Account migration attributes can be abused to impersonate privileged principals, including Domain Admins and KRBTGT. That makes dMSA write permissions and migration controls a core part of Active Directory privilege management, not just an implementation detail.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “How to Block BadSuccessor: The Good, Bad, and Ugly of dMSA Migration”.
Key questions
Q: Why does BadSuccessor create such a high-impact AD risk?
A: Because it can be used to impersonate highly privileged principals, including Domain Admins and KRBTGT, if the attacker can control the right dMSA state and linkage.
Q: What signs suggest dMSA abuse is underway?
A: Watch for unexpected dMSA creation, unusual changes to migration state, altered successor links, or password and key retrieval activity that does not match a planned migration.
Q: What breaks when dMSA migration attributes are writable by non-admin users?
A: The boundary between a benign service account and a privileged impersonation path breaks.
Practitioner guidance
- Review dMSA write paths Identify every user, group, and delegated process that can write to dMSA-linked attributes or reach that permission indirectly.
- Block migration use until needed Use the schema-level block on the migration scenario where your organisation does not need dMSA migration yet, then remove it only for controlled transitions and restore it afterwards.
- Isolate Tier 0 account paths Move highly privileged accounts into separate, tightly controlled OUs and make their distinguished names harder for lower-tier principals to discover or guess.
Bottom line: BadSuccessor demonstrates that writable dMSA migration attributes can be turned into a privilege escalation path inside Active Directory.
Glossary terms: Delegated Managed Service Account (dMSA), Privilege Escalation, Administrative Tiering, Writable Domain Controller
What's in the full article
Semperis's full article covers the operational detail this post intentionally leaves for the source:
- PowerShell cmdlet behaviour for starting, completing, undoing, and resetting dMSA migration
- AD schema attribute changes that enable and block successor abuse
- Indicator of exposure and indicator of compromise logic for dMSA activity monitoring
- Hands-on examples showing how the mitigation block is applied and removed
👉 Read Semperis' analysis of BadSuccessor and dMSA abuse in Active Directory →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
25/06/2026 10:28 am
BadSuccessor is a schema trust failure, not just an account abuse issue: the attack works because migration metadata is treated as reliable even when it is writable. That assumption fails when a low-friction LDAP write can redirect the successor path to a privileged principal. The implication is that AD teams must reclassify dMSA migration state as a security boundary, not an implementation detail.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should AD teams prevent dMSA abuse during Windows Server 2025 rollout?
A: Separate planned migration from standing privilege, restrict who can write the dMSA attributes that influence successor behaviour, and keep privileged account paths hidden in protected administrative tiers. That combination reduces the chance that a writable dMSA becomes a takeover path.
👉 Read our full editorial: BadSuccessor shows how dMSA abuse can expose Active Directory