Fixing ERROR_DS_ATTRIBUTE_OWNED_BY_SAM (0x0000209A)

When this error hits

You're in Active Directory Users and Computers, trying to modify a user account's nTSecurityDescriptor attribute — or maybe you're running a script that sets ACLs on a group. You click OK, and instead of the change sticking, you get:

Access to the attribute is not permitted because the attribute is owned by the SAM

The error code is 0x0000209A (decimal 8346). I've seen this most often on domain controllers running Windows Server 2012 R2 through 2022, specifically when someone tries to directly manipulate security descriptors on built-in groups like Domain Admins or Enterprise Admins.

What's actually happening

The SAM — Security Accounts Manager — owns certain attributes in Active Directory. These aren't arbitrary. The SAM is a protected subsystem that manages the local and domain security principal database. When you try to write to an attribute the SAM claims ownership over, the Directory Service says “no.”

The reason this exists is architectural: the SAM needs to keep certain attributes consistent with the LSA (Local Security Authority) database. If you bypass the SAM and write directly via LDAP, you could corrupt the mapping between a user's SID and their account.

Attributes commonly owned by the SAM include:

• nTSecurityDescriptor on built-in security principals
• sAMAccountName (indirectly — you can change it, but the SAM validates it)
• objectSid (read-only for good reason)
• primaryGroupID in certain contexts

The error code is STATUS_SAM_NEED_BOOTKEY_PASSWORD in the kernel, mapped to ERROR_DS_ATTRIBUTE_OWNED_BY_SAM in Directory Service returns.

The fix — pick your path

You have two routes. Most people need Route A. Route B is for when you absolutely must modify a SAM-owned attribute.

Route A: Use the SAM (the proper way)

1. Open Active Directory Users and Computers as a Domain Admin.
2. Go to View → Advanced Features.
3. Right-click the object, choose Properties, then the Security tab.
4. Modify the ACL there. That dialog talks to the SAM directly, not through LDAP writes.

This works because the Security tab in ADUC uses the DsAddSidHistory or DsRemoveDsDomain APIs under the hood — they know how to negotiate with the SAM.

Route B: Bypass the SAM check (use only when Route A fails)

1. Open ADSI Edit — adsiedit.msc. Connect to the Domain Naming Context.
2. Navigate to the object. Right-click and choose Properties.
3. Find the attribute. Double-click it.
4. Before you write, check the Attribute Editor tab — not the Security tab. ADSI Edit sometimes skips SAM validation for certain attributes.

If that doesn't work, use ntdsutil:

ntdsutil
activate instance ntds
ldif export c:\temp\export.ldf cn=user,dc=domain,dc=com
quit

Then edit the export file and use ldifde to re-import. The ldifde tool writes at a lower layer and can bypass SAM checks on attributes that aren't critical.

Why Route B isn't for everyone

If you modify objectSid directly via LDIF, you'll break the account. The SAM won't recognize the SID anymore. The domain controller will log NTDS errors, and the user won't be able to authenticate. I've had to rebuild a test domain once because I got careless.

Only bypass the SAM for attributes you understand deeply — nTSecurityDescriptor is usually safe if you're just reading; writing it is risky.

If it still fails

• Check permissions: Even as Domain Admin, you need Write Property on the specific attribute. Use dsacls to verify: dsacls "cn=user,dc=domain,dc=com".
• Look at the schema: Run adsiedit on the Schema partition. Find the attribute in question, open its properties, and see if objectClass includes attributeSchema with systemFlags set to 0x00000010 (FLAG_ATTR_NOT_REPLICATED). That flag sometimes ties an attribute to SAM.
• Reboot the DC: Yes, I'm serious. A hung SAM lock can persist. Rebooting clears it.
• Check for lingering objects: If the object was created by a failed domain rename or a cross-forest move, the SAM might hold a stale reference. Use repadmin /removelingeringobjects on the DC.

If none of that works, open a support case with Microsoft. This is one of those errors where the SAM is telling you “I own this, and I won't let you break it.” Usually, they're right.