Fix ERROR_DS_ILLEGAL_BASE_SCHEMA_MOD (0x213B)

You tried to change a core schema object in Active Directory. Windows blocks that by design. Here's how to get around it — or confirm you shouldn't.

The error looks scary. It isn't. ERROR_DS_ILLEGAL_BASE_SCHEMA_MOD means you tried to modify something in the Active Directory schema that Microsoft marked as untouchable. Base schema objects — classSchema, attributeSchema, subSchema, and the root of the schema partition itself — have a flag called systemFlags with bit 0x10 set. That bit is the "you can't change me" lock. Windows returns 0x213B the moment your LDAP modify hits one of those objects.

Real-world trigger: someone runs a script to bulk-update defaultSecurityDescriptor on a built-in class, or tries to rename CN=Schema,CN=Configuration,DC=contoso,DC=com to match a lab environment. The error fires instantly. It's not a permissions problem. It's a design guardrail.

Quick fix (30 seconds): confirm you're actually hitting a base object

Before you do anything, verify the target. If you're pointing your LDAP modify at a base schema object, no amount of Schema Admins membership will help. The flag wins.

Run this against your schema master:

ldifde -f schema_dump.ldf -d "CN=Schema,CN=Configuration,DC=contoso,DC=com" -p Base -l systemFlags

Then open schema_dump.ldf and look at systemFlags. If bit 0x10 is set (values like 16, 17, 20, 21), that's your answer. You can't modify it. Stop here and figure out what you actually wanted to do — because it wasn't this.

Common false alarm: people confuse "I can't modify this" with "I don't have rights." Check systemFlags first. Groups and permissions are a red herring if the object is locked by design.

Moderate fix (5 minutes): you meant to modify a child, not the base

Most people hitting 0x213B are one level off. They want to change an attribute on a custom class, or add an optional attribute to an existing class. That's allowed — as long as you're not touching the base object itself.

Say you're extending user to add employeeBadgeNumber. You don't modify CN=User,CN=Schema,... directly. You add the attribute to the class's mayContain list, then update the schema cache.

Open ADSI Edit. Connect to CN=Schema,CN=Configuration,DC=contoso,DC=com.
Find your custom attribute object. Confirm systemFlags does not have 0x10 set.
Edit the target class's mayContain property. Add the DN of your attribute.
Right-click the schema root, choose Reload Schema, or run schmmgmt.msc and reload.

If step 3 throws 0x213B, you picked a class Microsoft locked. Pick a different one, or create your own auxiliary class. The reason step 3 fails on locked classes is that Microsoft's own schema objects have bit 0x10 hardcoded and the DC enforces it before your modify even reaches the database.

Advanced fix (15+ minutes): you really do need to change the schema itself

There are legitimate reasons to alter what looks like a base object. Two examples that come up in the field:

You're restoring from a Schema Operations Master disaster and need to clean up a half-applied extension.
You're decommissioning a legacy app that injected schema changes and left orphaned objects.

Neither requires modifying a base object. ERROR_DS_ILLEGAL_BASE_SCHEMA_MOD is telling you the approach is wrong, not the goal.

Option A: disable the schema update check (not what you think)

There's a registry value people pass around — Schema Update Allowed. It does not bypass 0x213B. It only allows schema writes on a DC that isn't the schema master. Setting it on a non-master DC gets you past error 0x2136 (ERROR_DS_OBJ_CLASS_VIOLATION on schema writes), not 0x213B. Don't waste time here.

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Schema Update Allowed = 1 (DWORD)

If you're still seeing 0x213B after this, you're hitting a locked base object. The registry value is irrelevant.

Option B: use a custom auxiliary class

This is the real fix when the answer is "I need extra attributes on a locked class." You can't add to user's mayContain if user is base-locked. But you can create an auxiliary class that extends the behavior, then attach it to the objects that need it.

dn: CN=contoso-Aux-Ext,CN=Schema,CN=Configuration,DC=contoso,DC=com
changetype: add
objectClass: classSchema
cn: contoso-Aux-Ext
ldapDisplayName: contosoAuxExt
governsID: 1.2.840.113556.1.4.9999
objectClassCategory: 3
subClassOf: top
mayContain: employeeBadgeNumber

objectClassCategory: 3 is the magic value — it means auxiliary class. Auxiliary classes don't inherit the base lock, so you can modify them freely after creation. Attach with ADSI Edit or Set-ADObject on the target user.

Option C: verify you're talking to the schema master

Schema writes only succeed on the FSMO role holder. If you point a modify at any other DC, you can get odd errors that look like 0x213B but aren't. Confirm the master first:

netdom query fsmo
# or
Get-ADForest | Select-Object SchemaMaster

Then bind your LDAP client to that hostname explicitly. If the error changes to something else after you do, you were never hitting the base schema problem at all.

What NOT to do

Don't try to clear systemFlags bit 0x10 on a base object. Even if you find a tool that claims to do it, the schema engine re-stamps the flag on the next schema cache load. Worse, you can corrupt the schema partition and force a forest recovery from backup. I've seen this happen once at a financial services client. Three days of downtime to undo a script that should never have run.

The bit exists because Microsoft's own internal tooling relies on those objects being stable. Every Exchange install, every Lync/Skype deployment, every third-party product that extends the schema assumes base objects stay put. Break that assumption and you break installations you haven't even run yet.

Confirming the fix

After applying any of the above, re-run the original LDAP modify. If you were modifying a base object, the correct result is that you stopped modifying it and used an extension approach instead. If you were one level off, the modify should succeed and the DC event log will show Event ID 1228 or nothing at all (successful schema writes aren't logged loudly).

Check replication once you're done. Schema changes replicate as a single unit — either every DC has it or none do. If replication breaks mid-flight, you're back to 0x213B on subsequent modifies until the schema partition converges.

repadmin /showrepl * /csv > schema_repl.csv
repadmin /replsummary

Most people who land on this page don't need the advanced section. They're pointing LDAP at the wrong object. The 30-second systemFlags check will tell you which world you're in.