Fix 0x000020A6: Can't add system-owned attribute in AD

What's actually happening here

The error 0x000020A6 shows up when you try to add or modify an attribute that Active Directory flags as systemOnly. That flag lives in the attribute's attributeSchema object under systemFlags. The system sets this to prevent accidental corruption — think of attributes like objectCategory or instanceType that AD itself manages.

You'll see this most often when running a script or ADSI Edit against a custom schema attribute you inherited from a migration, or when a third-party app tries to set something it shouldn't. The error text reads: "It is not permitted to add an attribute that is owned by the system."

Quick fix (30 seconds) — check what you're touching

1. Open ADSI Edit. Connect to the Default Naming Context or Schema partition, depending on where the target object lives.
2. Right-click the object you're editing → Properties.
3. Scroll to the attribute you're trying to set. If it's grayed out, it's system-only. You can't write to it without changing the schema.
4. If you don't actually need that attribute, stop. Find another way to store your data — a custom extensionAttribute or an msDS-* attribute that's user-writable.

This isn't a real fix, just a reality check. Half the time people hit this error because they're modifying the wrong attribute.

Moderate fix (5 minutes) — override systemOnly via PowerShell

If you absolutely must write to a system-only attribute, you need to flip the systemOnly flag. You'll be modifying the attribute schema itself — this replicates across the domain, so test in a lab first.

Here's the PowerShell approach. Run this on a Domain Controller as Domain Admin:

$attrName = "theAttributeYouNeed"
$path = "LDAP://CN=$attrName,CN=Schema,CN=Configuration,DC=yourdomain,DC=com"
$attr = [ADSI]$path
$flags = $attr.systemFlags[0]
Write-Host "Current systemFlags: $flags"
# Remove the systemOnly bit (bit 4, value 16)
$newFlags = $flags -band -bnot 16
$attr.systemFlags = $newFlags
$attr.SetInfo()
Write-Host "systemFlags updated to: $newFlags"

What this does: The systemFlags attribute holds a bitmask. Bit 4 (value 16) controls system-only. The -band -bnot 16 clears just that bit, leaving all other flags intact. After this, any authenticated user can write to that attribute — no schema cache refresh needed.

Test immediately: try your original operation again. If it works, great. If not, check that you targeted the right attribute name — case-sensitive.

Advanced fix (15+ minutes) — schema snapshots and LDAP tools

If PowerShell flops, or you're skittish about running scripts in production, use ADSI Edit on the Schema partition directly. This is the nuclear option — you're changing the schema definition, not just data.

1. Open ADSI Edit. Right-click → Connect to. Under Select a well known Naming Context, pick Schema.
2. Navigate to CN=Schema,CN=Configuration,DC=.... Find the attribute you need.
3. Right-click → Properties. Find systemFlags. Double-click it.
4. Subtract 16 from the current value. Example: if it says 18, change it to 2. (18 - 16 = 2). The decimal value displayed is the sum of all set bits.
5. Click OK, then refresh the schema: in an elevated command prompt on the DC, run net stop ntds && net start ntds. This restarts the directory service and picks up the change.

The gotcha: If the attribute is a base schema attribute (like cn or objectClass), Microsoft doesn't let you unset systemOnly. The DS will refuse the write even if you change the flag. You'll get a different error — usually 0x000020A7. For those, you're stuck.

Another advanced trick: if you're using LDAP directly (e.g., ldapmodify), you can bypass ADSI by setting the systemOnly attribute to FALSE via an LDAP modify operation on the attributeSchema. But at that point, you're better off using the GUI.

Recap: when each fix works

Pick the one that matches your situation. Don't do the advanced fix unless you've confirmed the moderate fix fails and you really need that attribute writable. Schema changes stick forever.