STATUS_DS_CANT_MOD_OBJ_CLASS (0XC00002AE) Fix in Active Directory

You'll see STATUS_DS_CANT_MOD_OBJ_CLASS (0XC00002AE) when something tries to change the objectClass attribute of an existing Active Directory object. This usually happens in two places: a custom script that tries to convert a contact to a user, or a provisioning tool that creates a temporary object and later tries to repurpose it. I've also seen it when someone mistakenly tries to add the computer class to a user object with an LDAP modify operation.

Here's the actual scenario. You're writing a PowerShell script to bulk-create mail contacts. You create a contact, then realize you need it to be a user. So you do something like:

Set-ADObject -Identity "CN=John Doe,OU=Temp,DC=contoso,DC=com" -Replace @{objectClass="user"}

Boom. The error comes back. Or you're using an IDM tool that does the same under the hood. The error text says it all: "The directory service detected an attempt to modify the object class of an object."

What's actually happening here is a fundamental safety rule baked into Active Directory's schema. The objectClass attribute determines which objects can be attached to which attributes. If you could change it after creation, you'd end up with objects that have attributes they shouldn't have, or worse, an object that claims to be a user but has no sAMAccountName. The directory service simply refuses to allow it.

It's not a bug. It's by design. In fact, the schema defines objectClass as a system attribute. You can't even modify it with a privileged account unless you've taken the directory into Directory Services Restore Mode and hacked the schema, which you should absolutely never do.

Why the schema forbids it

Every AD object has an objectClass list. The top-level class is top, then something like person or contact, and so on. When you create a user, the system creates an object with objectClass set to user, which inherits from organizationalPerson and person. That class chain determines which attributes are allowed.

If you could swap contact for user after creation, the object might already contain attributes that don't exist in the user class. The directory service would have to either delete those attributes or ignore them, and neither is safe. So it just says no.

The only way to "change" an object's class is to delete it and recreate it with the desired class. That's the solution. It's not elegant, but it's the only supported path.

The fix: delete and recreate

Here's the step-by-step. This example converts a contact to a user, but the same logic applies for any class change.

1. Export the data you need. Grab all attribute values you care about. Use PowerShell to pull them before you delete anything.

Get-ADObject -Identity "CN=John Doe,OU=Temp,DC=contoso,DC=com" -Properties * | Select-Object Name,GivenName,SN,DisplayName,Mail,ProxyAddresses | Export-Csv -Path "contact_data.csv" -NoTypeInformation

2. Delete the old object. Use Remove-ADObject or the AD Administrative Center. Make sure you're not deleting anything you can't recreate.

Remove-ADObject -Identity "CN=John Doe,OU=Temp,DC=contoso,DC=com" -Confirm:$false

3. Create the new object with the correct class. For a user, use New-ADUser. For a computer, use New-ADComputer. For a group, New-ADGroup.

New-ADUser -Name "John Doe" -GivenName "John" -Surname "Doe" -DisplayName "John Doe" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (Read-Host -AsSecureString "Password") -Enabled $true

4. Reapply the exported attributes. Use Set-ADUser to set mail, proxyAddresses, etc. You'll need to map the CSV columns to the corresponding user attributes.

Set-ADUser -Identity "CN=John Doe,OU=Users,DC=contoso,DC=com" -EmailAddress "john@contoso.com" -Add @{proxyAddresses="smtp:john@contoso.com"}

The reason step 2 works is that you're removing the object entirely, which removes the class restriction. The new object starts fresh with the correct class chain.

When you can't delete the object

Sometimes the object is protected or has dependencies. For example, a user that's a manager of a group, or a contact that's listed in a distribution group's membership. If you delete it, those references break.

In that case, you have a couple of options:

• If it's a user that needs to become a contact — you can disable the user, create a contact, and link the contact as the manager instead of the user. The user object stays, but it's no longer used for that purpose.
• If it's a contact that needs to become a user — you'll have to remove the contact from all distribution groups first, delete it, then create the user and re-add it. There's no way around the deletion.

What to check if it still fails

If you've recreated the object and still see 0XC00002AE, double-check your code. Are you sure you're creating a new object with the right class, and not modifying the existing one? Look for any line that uses Set-ADObject or an LDAP modify operation that touches objectClass.

Also check if you have any custom schema extensions that might be interfering. Unusual class inheritance can cause weird behavior. Use Get-ADObject to inspect the objectClass list of the new object — it should contain the expected classes in order.

Get-ADObject -Identity "CN=John Doe,OU=Users,DC=contoso,DC=com" -Properties objectClass | Select-Object -ExpandProperty objectClass

If the output shows contact instead of user, you didn't actually create a new object — you might have accidentally re-linked the old one. Check the object's objectGUID before and after. A new GUID means new object.

One more thing. If you're using an identity management tool, check its logs. Some tools have a "provision" step that tries to update objectClass as part of a reconciliation. If you can't disable that step, you might need to set up the object manually and let the tool just update attributes. That usually satisfies the tool's logic without triggering the error.

The bottom line: you can't change an object's class. Respect the schema, delete and recreate. It's a few extra seconds, but it keeps the directory consistent.