0X00002016

Fix ERROR_DS_CANT_ON_RDN (0X00002016) – AD Attribute Trap

Server & Cloud Intermediate 👁 11 views 📅 May 28, 2026

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)

  1. Check if you're trying to rename an object that can't be renamed
    Some built-in objects (like Domain Admins, Enterprise Admins) have nTSecurityDescriptor flags that prevent rename. Try a test object first.
  2. 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 (usually cn). Right-click > Properties. Look at attributeID and systemFlags. If systemFlags has 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).
  3. 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.
  4. Try renaming via a different method
    If GUI fails, use PowerShell:
    Get-ADUser jdoe | Rename-ADObject -NewName "John Doe2"
      
    If that fails too, it's definitely a deeper issue.
  5. Check for directory sync conflicts
    If you're using Azure AD Connect, a conflicting attribute (like mailnickname or userPrincipalName) 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?