Fix Active Directory Error 0x2073 (RDN Schema Mismatch)

Active Directory throws 0x2073 when you try to add an object whose Relative Distinguished Name doesn't match the schema. Here's the quick fix and the reasoning behind it.

Getting hit with 0x2073 when trying to add an object to Active Directory is maddening—especially when the error message doesn't tell you which attribute is wrong. But the fix is straightforward once you know what's happening.

The Quick Fix

The error means the Relative Distinguished Name (RDN) you used doesn't match the schema's definition for that object class. In most cases, it's because you're using CN= when the schema expects OU=, or vice versa.

Open ADSI Edit (or LDP) and connect to the partition where the object exists.
Navigate to the parent container where you're adding the object.
Right-click → New → Object. Choose the object class you're creating.
When you get to the RDN (Relative Distinguished Name) field, check the syntax—it shows the attribute name the schema requires (like CN or OU).
Enter the value using that exact prefix. For example, if it says CN, type CN=John Doe, not Name=John Doe.

If you're doing this via PowerShell or .NET, the same rule applies. Here's a common mistake in PowerShell:

# Wrong—assumes CN, but the class might use OU
New-ADObject -Name "NewOU" -Type "organizationalUnit" -Path "DC=contoso,DC=com" -OtherAttributes @{ou="NewOU"}

# Correct—use the schema-defined rDNAttName
New-ADObject -Name "NewOU" -Type "organizationalUnit" -Path "OU=MyOU,DC=contoso,DC=com"

Notice in the correct version, the Name parameter takes the RDN value, and the path includes the parent OU. The schema for organizationalUnit defines ou as its rDNAttName, so that's what you must use.

Why This Happens

Active Directory's schema defines each object class with a mandatory attribute called rDNAttName. For users, it's cn. For OUs, it's ou. For domains, it's dc.

When you create an object, the directory service takes the leftmost component of the distinguished name (the RDN) and checks it against the class's rDNAttName. If they don't match, it throws 0x2073 because the object can't be addressed consistently in the directory tree.

What's actually happening here is a schema validation step that prevents you from creating an object that would be ambiguous later. If you could create an OU with CN=, then LDAP queries expecting OU= would break. The directory service is protecting itself.

Less Common Variations

The same error pops up in other scenarios—not just when creating objects through ADSI Edit.

1. Bulk Import with CSVDE or LDIFDE

When you import a CSV file, each line maps to an object. If your DN column says CN=Marketing but the schema for that class expects OU, you'll hit this error. Check your import file's DN column against the class definition.

# sample CSVDE line that fails
dn,objectClass
CN=Marketing,DC=contoso,DC=com,organizationalUnit

# corrected
OU=Marketing,DC=contoso,DC=com,organizationalUnit

2. Custom Schema Classes

If someone extended the schema with a custom class (like employee) and set rDNAttName to cn, you must use CN=. But if they set it to name, then Name= is required. This trips up developers who assume cn is universal.

To check a class's rDNAttName, use dsquery or ADSI Edit on the Schema partition:

dsquery * cn=user,cn=Schema,cn=Configuration,dc=contoso,dc=com -attr rDNAttName

3. Renaming Objects via Move

You can also trigger this when renaming an object through the rename operation. If you supply a new RDN that doesn't match the class (like changing a user's cn to ou), you'll get the same error. The name you provide must still honor the original attribute.

Prevention

The simplest habit: before creating any object programmatically, look up the class's rDNAttName. You can script this check:

$class = "user"
$schema = Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter {lDAPDisplayName -eq $class} -Properties rDNAttName
Write-Host "Use $($schema.rDNAttName)= prefix for $class objects"

Also, standardize your import scripts to validate the DN prefix before committing. A simple if ($dn -notlike "$($schema.rDNAttName)=*") throw saves you from troubleshooting this at 2 AM during a bulk migration.

One more tip: when you get this error, don't just retry with a different prefix. Look at the actual object class you're trying to create. Sometimes the issue is that you picked the wrong class entirely—you're creating a contact when you meant user, and the RDN requirements differ. Confirm the class first, then adjust the prefix. That's the real fix.