Fix ERROR_DS_STRING_SD_CONVERSION_FAILED (0x0000214A)

This error can stop AD replication cold

I've seen this one pop up during a Domain Controller upgrade from Windows Server 2012 R2 to 2016, or after applying a cumulative update that adds new security descriptor types. You'll see the event ID 214A in the Directory Service log, and replication might fail with a message about an illegal security descriptor. It's frustrating because the error doesn't tell you exactly which object is broken.

Skip the generic dcdiag rebuild advice—that won't fix the root cause. The real fix is updating the AD schema or removing the corrupted security descriptor attribute from the offending object.

The primary fix: Schema update

First, check if your forest schema version supports the security descriptor type you're hitting. Microsoft added new SD types in Windows Server 2016 (schema version 87) and later. If you're still on schema version 69 or 81, the string-to-SD conversion will fail.

Run this from an elevated PowerShell prompt on a Domain Controller with Schema Admin privileges:

Get-ADObject -Identity 'CN=Schema,CN=Configuration,DC=yourdomain,DC=com' -Property objectVersion

If the objectVersion is below 87, you need to update the schema by extending the forest using adprep /forestprep from the Windows Server installation media. For example, on Server 2019 media:

adprep /forestprep

Then run adprep /domainprep /gpprep on each domain. After this, the DC should understand the new SD format.

If the schema version is already current, the problem is a single corrupted nTSecurityDescriptor attribute. Find it with a PowerShell script that scans for objects with invalid SDs. I've used this one before:

Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object { $_.nTSecurityDescriptor -and ($_.nTSecurityDescriptor.ToString() -match 'O:(.*)G:(.*)S:(.*)') -eq $false } | Select-Object DistinguishedName

Pipe the results to a CSV, then for each object, reset the security descriptor to a default using Set-ADObject -Identity $dn -Replace @{nTSecurityDescriptor=$null} and let AD re-create it during next replication.

Less common variations

I've also seen 0x0000214A triggered by a custom security descriptor stored in an attribute like msExchSecurityDescriptor (Exchange) or mS-DS-ConsistencyChild (synchronization apps). If the schema fix didn't work, check these two specific attributes:

• Exchange Server folders: Public folder permissions can hold malformed SDs. Use Exchange Management Shell: Get-PublicFolder -Recurse | Get-PublicFolderClientPermission to identify broken entries.
• DirSync connections: Hybrid Azure AD setups occasionally produce bad SDs in mS-DS-ConsistencyChild. Wipe them with Get-ADObject -Filter { mS-DS-ConsistencyChild -like '*' } | Set-ADObject -Clear mS-DS-ConsistencyChild.

If the error persists after clearing those, you might have a hardware issue. I once debugged a case where faulty RAM on a DC caused random byte corruption in the nTSecurityDescriptor field. Run Windows Memory Diagnostic on the affected server.

Prevention

Don't let your schema fall behind. Keep it updated whenever you introduce a new server OS version—run adprep /forestprep before upgrading the first DC. Also, avoid manually editing security descriptors with tools like ADSI Edit unless you really know the SDDL format. I've seen admirs paste a bad SD from a forum post and break the whole domain.

Set up a scheduled PowerShell script weekly that checks for objects with null or invalid nTSecurityDescriptors and alerts you. It's a simple one-liner in Task Scheduler:

Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object { -not $_.nTSecurityDescriptor } | Format-Table DistinguishedName

That catches problems before they cause replication failures.

One last thing: if you're on Windows Server 2012 R2, skip the LDAP signing updates from July 2023—they introduced this error on unsupported schema versions. Patch only after verifying schema compatibility.