Topic starter
24/06/2026 9:06 pm
TL;DR: Windows Server 2025 delegated managed service accounts can be abused for stealthy Active Directory privilege escalation by rewriting migration attributes so Kerberos tickets issue as a privileged user, according to Netwrix. That breaks the assumption that service-account identity changes are visible through ordinary group and logon monitoring, making attribute-level control and Kerberos telemetry essential.
Editorial analysis by NHI Mgmt Group, based on content published by Netwrix: “dMSAs Are the New AD Privilege Escalation Target â Hereâs What You Need to Know”.
By the numbers:
- Akamai found that 91% of analysed environments had at least one organisational unit where user accounts had sufficient permissions to exploit this technique.
Key questions
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.
Q: Why do dMSAs create privilege escalation risk in Active Directory?
A: They create risk because the migration relationship between a dMSA and its predecessor can be manipulated to make the account appear to carry a higher privilege context.
Q: How can teams tell whether dMSA abuse is happening?
A: Look for attribute changes on dMSA objects, unexpected migration state transitions, and Kerberos ticket activity that does not match the known service-account baseline.
Practitioner guidance
- Restrict dMSA creation rights Limit CreateChild, WriteProperty, WriteDACL, Generic All, and WriteOwner permissions on organisational units that can host dMSAs.
- Monitor migration attributes directly Track changes to msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState, along with unexpected dMSA creation or modification.
- Baseline legitimate dMSA behaviour Document which dMSAs exist, which machines they bind to, and what normal Kerberos ticket patterns look like.
Bottom line: dMSA abuse turns Active Directory migration metadata into an escalation mechanism, so the real control problem is object-state governance rather than simple group review.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:07 am
Delegated managed service account escalation is really an object-state problem, not a group-membership problem. dMSAs shift service identity into a migration model where predecessor links and state flags matter as much as membership. That means the governance boundary is the directory object itself, not the role or group assignment layer. Practitioners should treat dMSA metadata as privileged control plane data.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should organisations do after finding risky dMSA permissions?
A: Revoke unnecessary delegated write rights, validate every dMSA migration path, and reclassify dMSAs as privileged identities for review purposes. The priority is to close the object-level control gap before it becomes a repeatable escalation route. Once the permissions are fixed, keep monitoring the attributes that define the account’s trust chain.
👉 Read our full editorial: dMSA privilege escalation in active directory exposes new identity risk