TL;DR: BadSuccessor is a new AD attack primitive that abuses dMSAs, allowing an attacker who can modify or create a dMSA to escalate privileges and take over the forest. The DACL-based parts of the attack have relatively straightforward mitigations.

Recently Yuval Gordon at Akamai released the blog post BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory with some great research on abusing a new managed service account type for Active Directory which was released in Windows Server 2025. If you haven’t read that post in full yet, please do so before continuing on with this one.

In a nutshell, BadSuccessor allows anyone who can create or compromise a Delegated Managed Service Account (dMSA) in any AD Forest where at least 1 Windows Server 2025 Domain Controller (DC) is in place and a KDS Root Key has been generated to abuse the created or compromised dMSA to perform an Escalation of Privilege (EoP) to any security principal, including a member of Domain Admins. The BadSuccessor attack primitive can also be abused to recover the keys of a superseded account, which is a form of credential theft that can also result in full AD Forest compromise.

This attack is especially interesting and novel in that it allows for a violation of the Clean Source Principal if any account which is not Tier Zero can create, or grant themselves the right to create, a specific type of child object in any Organizational Unit (OU).

When Yuval reported this EoP vulnerability to Microsoft’s MSRC, the response from MSRC was to downplay the criticality of the vulnerability by rating it a Medium and deciding not to issue a scheduled patch for the issue as part of the Patch Tuesday routine.  Instead, a fix will be worked on over time and, hopefully, included in future OS updates.

At its heart, the BadSuccessor attack is possible because of the way the Kerberos Key Distribution Center (KDC), which in the case of Active Directory is a domain controller, blindly trusts any value set in the msDS-ManagedAccountPrecededByLink attribute of the dMSA and utilizes Kerberos protocol extensions to duplicate the preceded account’s security context on the dMSA’s Kerberos Privilege Attribute Certificate (PAC).

If the KDC’s blind trust of the msDS-ManagedAccountPrecededByLink attribute is not the issue, then the ability of any security principal to modify this attribute would be.  Several other attributes in Active Directory that are confidential, secret, or highly privileged require more than just the standard ability to write to the property.  Constraining the ability to write to an object’s attribute can be accomplished in a couple of ways:

• Requiring a privilege to set a value.  Example: Enabling Kerberos Unconstrained Delegation on an account requires modifying the userAccountControl attribute on an object.  Most bit flags of the userAccountControl can be set by anyone with WriteProperty access for that attribute.  However, some are restricted.  The      TRUSTED_FOR_DELEGATION flag requires being assigned the SeEnableDelegationPrivilege privilege on domain controllers via User Rights Assignments or other methods.  Without this privilege enabled in the security context of the account attempting to modify or add the object, Active Directory will not accept a modified userAccountControl attribute which contains the TRUSTED_FOR_DELEGATION flag.
• Require Control Access Rights, specifically an Extended Right. Example: Enabling “password not required” on an account also requires modifying the userAccountControl attribute on that object. The bit flag which specifies whether a password is required or not for an account can’t be written with just WriteProperty on the userAccountControl attribute. It also requires the ExtendedRight Update-Password-Not-Required-Bit   
• Other restrictions that may be explicitly defined in the code.  I don’t have an example of this, I’m just aware it may be possible.

Unfortunately, requiring any of these three potential restrictions on the msDS-ManagedAccountPrecededByLink requires action from Microsoft. So whether Microsoft’s approach to this issue is to make changes to how the KDC handles the PAC or constraining the ability to write to the msDS-ManagedAccountPrecededByLink, it will require action by Microsoft to fully remediate the BadSuccessor issue.

But there are ways to mitigate the risk from a DACL abuse approach while we wait for Microsoft to take action.

DACL Abuse at Play

To start off with, let’s look at the attack path from a DACL abuse approach.

1. Initial access has occurred or we can make a base assumption that we are in an assumed breach scenario.
2. An attacker has control of a security principal with which they can authenticate in the environment. For our example, the attacker has control over ‘UserA’.  ‘UserA’ is not a member of any default privileged groups such as Domain Admins.
3. The same attacker has control over a computer host ‘Server1’ in the same domain which is running at least Windows Server 2025 or Windows 11 24H2.
4. The ‘UserA’ account has been granted rights on at least 1 Organizational Unit (OU) in the Active Directory (AD) domain which either specifically grant CreateChild access rights, grant ‘UserA’ GenericAll access rights which include CreateChild, or ‘UserA’ is able to grant themselves those rights on the OU via object ownership, WriteOwner, or WriteDACL.
   
   Note: An OU is the most likely AD object to allow creation of msDS-DelegatedManagedServiceAccounts. However, Containers are another object which the default AD Schema allows the msDS-DelegatedManagedServiceAccount to be a child object of via the systemPossSuperiors. In AD Forests where the Schema has been modified, for example, in such cases similar to CVE-2021-34470, other objectClasses may be available.
5. With these previously granted rights, the attacker creates a Delegated Managed Service Account (dMSA) in that OU, which the attacker creatively named “New dMSA”:
   
   
6. Due to how security descriptor defaulting rules work in Active Directory, the ‘UserA’ principal is highly likely to be set as the Owner in the security descriptor for the ‘New dMSA’ object.
7. By default, the Owner of any object has the implicit privilege to modify permissions (WriteDACL) on the object they are the Owner of.  This inherit privilege is checked during an access check before any Discretionary Access Control Lists (DACLs) or Access Control Entries (ACEs), so the Owner of the object can do this even if there is a deny ACE which would otherwise prevent that security principal from doing so.
8. The attacker utilizes the inherit privilege to WriteDACL which ‘UserA’ has as the Owner of ‘New dMSA’ to grant ‘UserA’ GenericAll (Full Control) permissions on ‘New dMSA’:
9. Now that ‘UserA’ is granted GenericAll permissions on ‘New dMSA’, which includes WriteProperty permissions, ‘UserA’ can modify the properties of ‘New dMSA’.  By using either the AD PowerShell module, .NET classes, or just plain LDAP, ‘UserA’ will set msDS-ManagedAccountPrecededByLink to the Distinguished Name (DN) of an account the attacker wants to compromise, perhaps the ‘DomainADM’ user.  ‘UserA’ also sets msDS-GroupMSAMembership to ‘Server1’, which is the computer host that the attacker controls, and then sets msDS-DelegatedMSAState to ‘2’ to begin the takeover process:
   Note: The msDS-GroupMSAMembership does not need to be set to a computer host that the attacker controls.  The msDS-GroupMSAMembership can be any security principal(s), including a group.  BadSuccessor is abusable directly to a user account.
   
10. The attacker can now use the control they have over ‘Server1’ and ‘New dMSA’ to retrieve a Kerberos TGT with the security context of ‘DomainADM’.  This effectively impersonates the capabilities of ‘DomainADM’ without modifying any group membership or other Kerberos delegation features.

The capability of the dMSA account to impersonate any security principal which is present in the msDS-ManagedAccountPrecededByLink property on the dMSA is vulnerability in BadSuccessor, however it is the Windows security model around how security descriptors and access checks are performed that enable staging of an abuse platform for this vulnerability.

Just as there are choke points in attack paths which lead to attack path management, there are choke points in the DACL abuse that sets the stage for the BadSuccessor vulnerability.  

Before we get into creating DACL-based mitigations, I’d like to cover a few common misconceptions I see around security descriptors in Windows and Active Directory as it relates to the BadSuccessor attack primitive.  I’ve included information on these at the end of this blog.

DACL Based Mitigations

There are a couple of potential choke points in the BadSuccessor attack which can be mitigated by targeted use of Access Control Entries on OUs.

The first potential choke point is on the ability to Create msDS-DelegatedManagedServiceAccounts:

The second potential choke point is on the implicit ability of object owners to WriteDACL:

The third potential choke point is on the ability to Write an arbitrary value to the msDS-ManagedAccountPrecededByLink:

I’m certainly not the first person to have the idea to use a Deny ACE or OwnerRights to prevent this attack vector.  However, most of the suggestions for utilizing Deny ACEs for mitigation missed important nuances in the way that the Windows security model functions. 

For example, adding a Deny CreateChild ACE at the root of the Domain won’t be effective.  When a DACL is created or modified by standard Windows functions and APIs it will be set in canonical order.  DACLs in canonical order place explicit ACEs…those which are not inherited, prior to inherited ACEs in the order of operations.  Because many of the permissions that allow users to CreateChild objects on OUs will be explicitly delegated at the child OU level, this potential inherited Deny CreateChild ACE will be preempted by the explicit Allow ACEs on the OUs.

Adding a blanket Deny CreateChild ACE that applies to all object types won’t work well either as it will muck up standard administrative processes.  The Deny CreateChild ACE needs to be targeted so that it will only affect msDS-DelegatedManagedServiceAccounts.  And any Deny ACEs we create now must be readily reversed.

And while I recommend learning about and using the well-known SID OwnerRights in your environment, I recommend doing so with testing and caution to avoid service interruptions.

As a caveat, I must note that if an attacker has or can compromise an account which has WriteDACL permissions on an Organizational Unit (OU), then any deny ACEs we create are moot or a speed bump at best.  If you have OUs where low-privileged accounts are granted GenericAll (aka Full Control), WriteDACL or WriteOwner permissions, those low-privileged accounts would also have the capability to modify the permissions of the OU to remove any deny ACEs we might create.  However, BloodHound absolutely can help you find instances where accounts have GenericAll, Owns, WriteDacl, or WriteOwner edges to an OU node.

To locate accounts which are not Tier Zero that are able to modify permissions on OUs in the environment, please use this BloodHound cypher:

MATCH p = (ou:OU)<-[:WriteDacl|Owns|GenericAll|WriteOwner]-(n:Base)
WHERE NOT ((n:Tag_Tier_Zero) OR COALESCE(n.system_tags, '') CONTAINS 'admin_tier_0')
RETURN p
LIMIT 1000

Mitigation 1: Add-BadSuccessorOUDenyACEs.ps1

I’ve put together a pair of PowerShell functions to mitigate the DACL abuse primitives that allow for this attack to occur.  The scripts containing the functions are hosted on my GitHub: https://github.com/JimSycurity/dMSAs 

Add-BadSuccessorOUDenyACEs will apply, by default, 3 ACEs to each OU it is fed via the DistinguishedName parameter (or by pipeline).  The 3 ACEs are:

1. Deny AuthenticatedUsers the rights to CreateChild dMSA objects in the OU
2. Allow OwnerRights the rights to ListChildren on child dMSA objects in the OU (which replaces the default WriteDACL capability)
3. Deny AuthenticatedUsers the rights to Write to the msDS-ManagedAccountPrecededByLink on child dMSA objects in the OU

To set these ACEs on every OU in a domain:

Get-ADOrganizationalUnit -Filter * | Add-BadSuccessorOUDenyACEs

To remove the same ACEs on every OU in a domain:

Get-ADOrganizationalUnit -Filter * | Add-BadSuccessorOUDenyACEs -RemoveAll

Note: Any of the PowerShell scripts which check for OU permissions that allow for BadSuccessor abuse could be modified to output the OU list to the pipeline.  When I have time to do so, I’ll update the scripts on my dMSAs GitHub.

The 3 ACEs in the script target the least-privilege access required to abuse the BadSuccessor attack chain.  I don’t only target dMSA creation because dMSAs may already exist in the environment.  Disabling implicit owner rights on dMSAs can help mitigate the ability to modify the DACL of a dMSA via OwnerRights, but it can’t prevent supplying all of the required dMSA attributes on object creation.  The final Deny Authenticated Users the ability to Write to the msDS-ManagedAccountPrecededByLink attribute on child dMSA objects in an OU is designed to protect existing dMSA objects from abuse.  It may not provide protection in the instance of object creation.  

These 3 ACEs work together to mitigate DACL abuse of dMSAs in instances where the attacker, or an account the attacker controls, does not have WriteDACL permissions on the OU.

Mitigation 2: Disable Implicit Owner Rights

Please don’t do this hastily, but understand that the mitigations in KB5008383 related to LDAP Add and LDAP Modify operations will remediate the implicit owner right to WriteDACL across all computer and computer-derived objects in the AD Forest.  The msDS-ManagedServiceAccount, msDS-GroupManagedServiceAccount, and msDS-DelegatedManagedServiceAccount object classes are all subclasses of the computer class.

Setting the dSHeuristic flag 29 prevents a potential step in the BadSuccessor attack where the low-privileged account which created the dMSA object becomes the owner of the object and can thus WriteDACL on the object to grant itself rights to modify the necessary properties to carry out the attack.  This is the attack path that Yuval Gordon appeared to follow in his original BadSuccessor blog.

Unfortunately, it is possible to supply all of the required property values to successfully abuse the BadSuccessor attack on a dMSA account when it is created.  Implicit Owner Rights are not required if the attacker creates the object in a vulnerable state, which can be accomplished via tooling released on 5/23/25.

Mitigation 3: Additional Authorization for LDAP Add Operations

There are two dSHeuristics flags from KB5008383.  Flag 28 requires additional authorization for LDAP Add Operations.  The details of how this additional authorization functions are located in the MS-ADTS Open Specifications 3.1.1.5.2.1.1 Per Attribute Authorization for Add Operation.

I’m grateful for feedback I received on reddit and for a LinkedIn post by Adrea Pierini which brought to light my misconception on how flag 28 worked.  I dug back into it and did some rigorous testing in my lab.  As stated by Adrea, dSHeuristics Flag 28 does block a security principal that is granted solely CreateChild permissions on an OU or container from creating a dMSA object, but only when attributes which are not required by the object class are specified and the account does not otherwise have explicit rights to modify those attributes.

Note: If you want to understand, in depth and with lab examples, how flag 28 for dSHeuristics functions, I wrote up my notes in the Experiments folder of the dMSA repo I created: https://github.com/JimSycurity/dMSAs/tree/main/Experiments I will likely clean this up and turn it into a blog in the future.

Conclusion: Layers

Security and mitigations need layers to be effective.  The DACL-based ACEs in Mitigation 1 are not 100% effective in every scenario.  Disabling Implicit Owner Rights per Mitigation 2 has several gaps, some of which can be filled by the additional authorization for LDAP Add Operations described in Mitigation 3.

If only Mitigation 1 is in place there could be containers or OUs which are missed in applying the Add-BadSuccessorDenyACEs.  Remember, there could be overly permissive rights on containers which can be parents to dMSA objects also.

If only Mitigation 2 is in place, an attacker could create a dMSA object with all attributes pre-created at object add, which does not require any implicit owner rights to perform the BadSuccessor attack.

If only Mitigation 3 is in place, an attacker could create a base dMSA object, grant itself permissions via the implicit WriteDACL privilege of object ownership, and then modify the attributes required to perform the BadSuccessor attack.

It should also be noted that if an attacker has control over an account which is the owner or has GenericAll, WriteDACL, WriteOwner permissions on an OU or container there are no ways to prevent this attack.  The Deny WriteProperty on the msDS-ManagedAccountPrecededByLink may perhaps slow down or provide an opportunity for detection if commodity attack tooling is utilized.

My current recommendation is:

1. Utilize the posture check tools others, like LuemmelSec have released but keep in mind that containers can be an issue in addition to OUs.
2. Ensure audit logging is properly configured in the environment and consider applying SACL auditing as recommended in Yuval’s original BadSuccessor blog post.
3. Implement Mitigation 1 thoroughly in the environment or at least on OUs and containers where any principals that are not Tier Zero are granted CreateChild permissions.
4. Ensure both dSHeuristic flags are currently in at least Audit mode across all domain controllers.
5. Review the added event logs in the Directory Services log  which the KB5008383 implements across all DCs, hunting for scenarios where required AD workflows may be disrupted by implementing Enforcement mode. 
6. Work towards implementing KB5008383 Enforcement mode on all domains.
7. Wait patiently for Microsoft to, hopefully, provide a full remediation.

Other Mitigations

Mitigation 3: Don’t have a KDS Root Key

If your AD Forest doesn’t already have a KDS Root Key, then the BadSuccessor dMSA attack is not possible in that forest, regardless of whether there is a Windows Server 2025 domain controller.  msDS-DelegatedManagedServiceAccounts cannot be created in a forest, or any of the domains of that forest if there is no KDS Root Key.  You can determine if a root key is in effect using the Get-KdsRootKey PowerShell cmdlet.  

If a KDS Root Key does already exist in the forest, then this mitigation is not feasible.  It’s been possible to generate a KDS Root Key since Windows Server 2012 R2 and this functionality is utilized by both msDS-GroupManagedServiceAccount (gMSA) and msDS-DelegatedManagedServiceAccount (dMSA) objects.

It would be possible to create a detection for any newly created KDS Root Keys by applying a specific SACL.  The location of the SACL would need to be CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=contoso,DC=com where contoso.com is the root domain of the AD Forest. The ACE required in the SACL would trigger on trustee Everyone with CreateChild rights.  This presumes proper event log and auditing configuration on the domain controllers in the root domain of the forest along with log aggregation to a SIEM with configurable alerts.

Security Descriptor Misconceptions

I see a couple of misconceptions on how some of the underlying details of the BadSuccessor attack function, primarily as it relates to Active Directory (AD) object creation and ownership.  I’ve already written a few words on AD object ownership: Owner or Pwned?.  It’s not a short read, and the issues are summarized here.

This is not intended to take away from Yuval and Akamai’s great research.  If we do not understand the details of how the attack primitive works, we cannot mitigate it.

Misconception 1

“When a user creates an object in AD, they have full permissions over all of its attributes.” is not quite accurate, or at least it leaves out some of the important nuances of the issue.  

A more accurate statement could be “When a user creates an object in AD, and a security descriptor is not supplied in the add request, and the user is not a member of the Default Administrators Group for the object, then the user’s SID is written to the OwnerSID of the object’s security descriptor and due to implicit OwnerRights, that user is then able to modify the permissions of the object in order to grant themselves full permissions over all of its attributes.”  

Look, I get why my statement didn’t get used.  I’m not known for my brevity.  This is all spelled out in Owner or Pwned, which is only 55 pages long, but there are rules:

• All objects in Active Directory are securable objects.  
• All securable objects can (and almost always do) have a security descriptor.  In AD this property is nTSecurityDescriptor.  
• In AD, the OwnerSid of a security descriptor cannot be NULL.  All AD security descriptors must have a populated OwnerSid property which represents the object’s owner.
• The owner of a security descriptor is implicitly granted Read Permissions and Write DACL rights by default, unless these implicit rights are blocked.
• A principal granted Write DACL rights can modify the DACL of that security descriptor and grant any permissions up to and including GenericAll rights.
• When an object is created in AD, if the creator of the object does not provide a correctly formed OwnerSid in a properly formed security descriptor, a default owner will be assigned to the security descriptor of that object according to the Owner and Group Defaulting Rules:
  • If the security principal creating the AD object is a member of the Default Administrators Group (DAG) for the object, the SID of that group is written to the OwnerSID
  • Otherwise, if the creator’s security context contains the TokenOwner field, the SID in that field is written to the OwnerSID
  • Otherwise, the creator’s user SID is written to the OwnerSID.  This is very common and is the scenario that BadSuccessor is relying on.

Again, there’s nuance here, but this nuance is important.  The creator of an object doesn’t automatically have full permissions over that object.  The creator of an object is, by default,  implicitly granted rights to change the permissions over that object.  The creator of an object is, by default, able to grant themselves full control over the object.  Unless implicit owner rights are blocked.

Misconception 2

When a user creates an object in AD, it is true that the user’s SID will be replaced in any ACEs where the Creator Owner special identities group is specified as the trustee.  So yes, the user that created the object will be the Creator Owner.  However, the Creator Owner mechanism is not what is at play here in “granting ourselves permissions on the object”.  As explained in Misconception 1, Owner and Group Defaulting Rules are what grant the default implicit right to WriteDACL.  

Creator Owner ACEs are usually a result of Security Descriptor Defaulting Rules, where if an object is created and a security descriptor is not supplied with the request, the security descriptor will be determined from the defaultSecurityDescriptor value for that objectClass of the object being created.  The AD Schema provides the default security descriptor, and in the case of dMSAs, the objectClass in the schema looks something like this:

Dn: CN=ms-DS-Delegated-Managed-Service-Account,CN=Schema,CN=Configuration,DC=AD2025,DC=lan
adminDescription: The delegated managed service account class is used to create an account which can supersede a legacy service account and shared by different computers.;
adminDisplayName: ms-DS-Delegated-Managed-Service-Account;
cn: ms-DS-Delegated-Managed-Service-Account;
defaultHidingValue: FALSE;
defaultObjectCategory: CN=ms-DS-Delegated-Managed-Service-Account,CN=Schema,CN=Configuration,DC=AD2025,DC=lan;
defaultSecurityDescriptor: D:(OD;;CR;00299570-246d-11d0-a768-00aa006e0529;;WD)(OD;;RP;e362ed86-b728-0842-b27d-2dea7a9df218;;WD)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO)(A;;LCRPDTLOCRSDRC;;;CO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY);
distinguishedName: CN=ms-DS-Delegated-Managed-Service-Account,CN=Schema,CN=Configuration,DC=AD2025,DC=lan;
dSCorePropagationData: 0x0 = (  );
governsID: 1.2.840.113556.1.5.302;
instanceType: 0x4 = ( WRITE );
lDAPDisplayName: msDS-DelegatedManagedServiceAccount;
name: ms-DS-Delegated-Managed-Service-Account;
objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=AD2025,DC=lan;
objectClass (2): top; classSchema;
objectClassCategory: 1 = ( STRUCTURAL );
objectGUID: 57db26f1-1765-4f70-8498-20f2157a0b7a;
rDNAttID: cn;
schemaIDGUID: 0feb936f-47b3-49f2-9386-1dedc2c23765;
showInAdvancedViewOnly: TRUE;
subClassOf: computer;
systemFlags: 0x10 = ( SCHEMA_BASE_OBJECT );
systemMayContain (5): msDS-GroupMSAMembership; msDS-ManagedPasswordPreviousId; msDS-ManagedPasswordId; msDS-ManagedPassword; msDS-ManagedAccountPrecededByLink;
systemMustContain (2): msDS-DelegatedMSAState; msDS-ManagedPasswordInterval;
systemOnly: FALSE;
systemPossSuperiors (2): container; organizationalUnit;
uSNChanged: 2039;
uSNCreated: 2039;
whenChanged: 7/21/2023 11:03:07 AM Central Daylight Time;
whenCreated: 7/21/2023 11:03:07 AM Central Daylight Time;

Within that definition is the defaultSecurityDescriptor for dMSA objects in SDDL format, with the Creator Owner (CO) ACEs in bold font:

D:(OD;;CR;00299570-246d-11d0-a768-00aa006e0529;;WD)(OD;;RP;e362ed86-b728-0842-b27d-2dea7a9df218;;WD)(OA;;WP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO)(A;;LCRPDTLOCRSDRC;;;CO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY);

That’s a total of 8 Creator Owner ACEs in the dMSA defaultSecurityDescriptor. Converting that SDDL to a graphical representation results in this:

None of the Creator Owner ACEs that are part of the defaultSecurityDescriptor for dMSAs allow for the capability to modify the permissions of the object, nor do they allow modification of the msDS-DelegatedMSAState or msDS-ManagedAccountPrecededByLink attributes.

It should be noted, however, that the Account Operators builtin group is granted an explicit GenericAll ACE on any newly created dSMA, so this is another reason to not use the builtin Account Operators group and to routinely review its membership to ensure it stays empty.

Updated May 30, 2025 to address misunderstandings I had at the time how dSHeuristics flag 28 from KB5008383 worked.  Resolved my misconception in Mitigation 2, shifted the KDS Root Key to Mitigation 4, and created a new Mitigation 3: Implement LDAP Add Operation Restrictions.