Fix STATUS_DS_ATTRIBUTE_TYPE_UNDEFINED (0XC00002A3)

What this error means

When you see STATUS_DS_ATTRIBUTE_TYPE_UNDEFINED (0XC00002A3), the directory service is telling you it doesn't know the attribute you're asking for. This happens when something references an attribute that isn't in the current schema. I've seen it most often after a failed schema update, a restore from backup, or when you've copied an LDAP query from another forest that has a different schema.

The error can show up in the Event Viewer, during a domain controller boot, or when you run a tool like ldp.exe or repadmin. It's rarely a hardware problem — it's almost always a schema mismatch or a malformed attribute reference.

Here's the troubleshooting flow. Start with the first fix, test, and only move to the next if you still see the error. You can stop at any point once the error is gone.

Fix 1: Verify the attribute actually exists (30 seconds)

Before messing with anything, confirm the attribute is even in your schema. Sometimes people type a wrong name or use an OID that was never added. This takes about 30 seconds.

1. Open a command prompt as Administrator on any domain controller.
2. Run this command, replacing attributeName with the attribute from your error message:

dsquery * cn=Schema,cn=Configuration,dc=yourdomain,dc=com -filter "(&(objectClass=attributeSchema)(lDAPDisplayName=attributeName))" -attr lDAPDisplayName attributeID

If you get a result with a name and an OID, the attribute exists, and you can skip to Fix 2. If you get nothing back, the attribute is missing. That's your problem. You'll need to either re-add the schema extension that defines it or fix whatever script is calling the wrong name.

Expected outcome: The command either prints a row with two columns or returns nothing. No news means the attribute is undefined — that's the root cause.

Fix 2: Check for a schema version mismatch (5 minutes)

If the attribute exists but you're still getting the error, the likely culprit is a schema version mismatch between domain controllers. This happens when one DC hasn't replicated the latest schema changes.

1. Open ADSI Edit (type adsiedit.msc in Run). If you don't have it, install the AD DS tools from Server Manager.
2. Right-click ADSI Edit in the left pane and choose Connect to.
3. In the dialog, select Configuration under Select a well known Naming Context.
4. Click OK, then expand Configuration → CN=Configuration,DC=yourdomain,DC=com → CN=Schema,CN=Configuration,...
5. Right-click CN=Schema and select Properties.
6. Look for objectVersion in the Attributes list. Note the number. On a Windows Server 2019 DC, it should be 88. For 2016, it's 87. For 2012 R2, it's 69. If the DCs show different values, that's the mismatch.

When you find a DC with a lower objectVersion, it hasn't replicated the schema. Force replication from a healthy DC:

repadmin /syncall /AdeP

Run this on the offending DC. Wait a few minutes, then check the Event Viewer for replication errors. If replication is failing, you may need to fix DNS or network connectivity between DCs first.

Expected outcome: After a successful sync, all DCs should show the same objectVersion. Restart the AD DS service (net stop ntds && net start ntds) and see if the error repeats.

Fix 3: Manually define the missing attribute (15+ minutes)

If the attribute truly doesn't exist and you can't re-run the original schema extension, you can add it manually. This is a last resort because it's easy to mess up. You need the exact LDAP display name and OID from the application that's calling it. If you don't have that, stop here and call the vendor — they need to provide the schema file.

Here's how to add a custom attribute using ADSI Edit:

1. Open ADSI Edit and connect to the Schema naming context as described above.
2. Right-click CN=Schema, then choose New → Object.
3. Select attributeSchema and click Next.
4. For Common Name, enter a unique name like my-custom-attribute.
5. In the Attributes list, set these mandatory values:
   • lDAPDisplayName — the exact name the app uses, e.g., myCustomAttribute
   • attributeID — the OID, e.g., 1.2.840.113556.1.8000.9999.1.1 (pick a unique OID; don't reuse existing ones)
   • attributeSyntax — set to 2.5.5.12 for Unicode string
   • oMSyntax — set to 64 for Unicode string
   • isSingleValued — set to TRUE unless you need multi-valued
6. Click More Attributes, then add the above values one by one.
7. After creating the attribute, you must also bind it to an object class. That's done by editing the mayContain property on the class you need it on. For example, to add it to user, right-click the user class in the Schema, go to Properties, select mayContain, and add the LDAP display name.

This is tedious and easy to get wrong. If you're not comfortable, I'd strongly suggest restoring the schema from a good backup or reimporting the vendor's LDIF file. A botched manual attribute can cause more problems than you started with.

Expected outcome: After the attribute is defined, the original operation that threw the error should succeed. Test with your application or with ldp.exe binding and querying for the attribute.

What if none of these work?

If you've checked the attribute exists, forced replication, and even added it manually but the error persists, you're likely looking at a corrupted schema partition. That's a bigger deal. You might need to restore the system state from a known good backup or, in extreme cases, demote and re-promote the DC. If the error appears on every DC in the forest, the schema master itself is suspect. Don't try to rebuild the schema from scratch — get Microsoft support involved or restore from the last successful schema backup.

One last thing: if you're running a third-party app, check if it has a schema extension that was installed incorrectly. I've seen a failed install leave a dangling reference. The vendor's repair tool is usually the cleanest fix.