Fix ERROR_DS_CANT_ON_RDN (0X00002016) – AD Attribute Trap
Active Directory can't write to a relative distinguished name (RDN) attribute. Usually a schema or permissions issue.
Quick answer: This error means AD can't modify the naming attribute (typically cn or ou) because it's either protected by the schema, locked by a permissions issue, or the attribute itself is read-only on that object class.
What's Really Going On
I see this error pop up most often when someone tries to rename a user or OU through the GUI or PowerShell, and the operation fails with 0X00002016. I've had a client last month whose entire HR department lost access because an intern renamed a security group wrong.
The core issue: Every object in AD has a relative distinguished name (RDN) — usually the cn (common name) for users and groups, or ou (organizational unit) for containers. The RDN attribute must be writable. If something blocks that attribute from being changed — schema flag, ACL, or a conflict with another directory sync tool — you get this error.
Fix Steps (in order of probability)
- Check if you're trying to rename an object that can't be renamed
Some built-in objects (like Domain Admins, Enterprise Admins) havenTSecurityDescriptorflags that prevent rename. Try a test object first. - Verify schema attribute flags on the RDN attribute
Open ADSI Edit (mmc > Add Snap-in) and connect to the Schema partition. Find the attribute used for the object's RDN (usuallycn). Right-click > Properties. Look atattributeIDandsystemFlags. IfsystemFlagshas FLAG_ATTR_IS_RDN (0x00000001) set, it's the RDN — fine. If it also has FLAG_ATTR_REQ_RDN or FLAG_ATTR_DISALLOW_MOVE, renaming is blocked. You can't change those flags without schema modification (see alternative fix below). - Check object-level permissions
Right-click the object > Properties > Security tab. Make sure the account running the rename has Allow Write cn (or the relevant RDN attribute). Sometimes inheritance is broken — check Advanced > Effective Permissions. - Try renaming via a different method
If GUI fails, use PowerShell:
If that fails too, it's definitely a deeper issue.Get-ADUser jdoe | Rename-ADObject -NewName "John Doe2" - Check for directory sync conflicts
If you're using Azure AD Connect, a conflicting attribute (likemailnicknameoruserPrincipalName) being synced can block the RDN change. Temporarily disable sync, try the rename, re-enable sync.
Alternative Fixes
Fix 1: Modify schema flags (advanced, risky)
If you're absolutely sure the attribute should be renameable, you can edit the schema attribute's systemFlags to remove the DISALLOW_MOVE flag. Back up the schema first. Use ADSI Edit to access Schema partition, set flags to 1 (just IS_RDN) instead of 3 (IS_RDN + DISALLOW_MOVE). I've done this maybe three times in ten years — only when a vendor's app had coded a bad object class.
Fix 2: Move and recreate the object
If renaming is impossible, create a new object with the desired name, copy attributes from the old one, then delete the old. Use PowerShell for bulk:
$old = Get-ADUser jdoe -Properties *
New-ADUser -Name "John Doe2" -SamAccountName jdoe2 -GivenName $old.GivenName -Surname $old.Surname -UserPrincipalName jdoe2@domain.com
Fix 3: Restore from tombstone
If the object was accidentally deleted, use Active Directory Recycle Bin (Server 2008 R2+). Right-click Deleted Objects > Restore. The RDN error usually appears during restore if the original naming attribute was overwritten — ensure the restored object's naming attribute matches the original.
Prevention Tip
Stop letting interns rename AD objects directly. Use a dedicated provisioning tool or PowerShell script that logs every rename. Also, run this on every domain controller to check for problematic schema flags:
Get-ADObject -Filter { objectClass -eq 'attributeSchema' } -Properties systemFlags | Where-Object { $_.systemFlags -band 0x00000010 } | Select Name, systemFlags
That 0x00000010 flag means DISALLOW_MOVE. If you see it on cn or ou in your custom schema, you're going to hit this error. Remove it proactively.
Remember this: Most 0X00002016 errors you'll run into aren't bugs — they're AD telling you 'I can't let you rename that' for a good reason. Listen to it, or override it carefully.
Was this solution helpful?