Active Directory object class missing? Fix error 0x0000207B

When does this error hit?

You're writing a script or a small app that adds an object to Active Directory. Could be a user, a computer, a group, or something custom. You send the LDAP add request, and bam — you get back 0x0000207B with the message "The object class attribute must be specified." It's one of those errors that makes you stop and go, "But I did specify it, didn't I?"

I've seen this most often in two places: PowerShell scripts using [ADSI] or System.DirectoryServices, and in C# apps using DirectoryEntry. The trigger is almost always the same — you're passing a set of attributes but the objectClass line is either missing, misspelled, or it's in the wrong format.

What's really going on?

Active Directory is strict about one thing: every object must belong to a class. When you say "objectClass", you're telling AD what kind of object this is going to be: user, computer, group, organizationalUnit, or a custom class from the schema. Without that, the directory has no idea what attributes are allowed, what the object can do, or where it fits in the hierarchy.

Think of it like filling out a form with no form name. The system can't process it because it doesn't know what rules apply. AD is the same way. The objectClass attribute is what tells AD, "This is a user object, so expect these specific attributes."

The tricky part? This error can also pop up if you're using objectCategory but forgetting objectClass. They're different things. objectClass is the real deal — it's mandatory for creation. objectCategory is for indexing and searching, and it's set automatically by AD after the object exists.

The fix: step by step

Step 1 — Check your LDAP add request

Look at the code that's sending the add operation. In PowerShell with [ADSI], you'd see something like this:

$ou = [ADSI]"LDAP://OU=Users,DC=contoso,DC=com"
$newUser = $ou.Create("user", "CN=John Doe")
$newUser.Put("samAccountName", "jdoe")
$newUser.SetInfo()

Notice the Create("user", ...) call — that's where you're specifying the class as a string. If you forget the second parameter or use a class name that doesn't exist in the schema, you'll get 0x0000207B.

Step 2 — Verify the class name is exact

Active Directory class names are case-insensitive but spelling must be perfect. Common ones:

• user — for user accounts
• computer — for computer accounts
• group — for security or distribution groups
• organizationalUnit — for OUs (note: not "organizationalunit" without the "t" — yes, I've seen that)
• contact — for contact objects
• inetOrgPerson — for internet-style person objects

If you're using a custom class, double-check it's defined in the schema and that you're using the ldapDisplayName (like myCustomClass), not the cn (like My-Custom-Class).

Step 3 — In C#, check your DirectoryEntry constructor

If you're writing C# code using DirectoryEntry, the fix looks like this:

using (DirectoryEntry ou = new DirectoryEntry("LDAP://OU=Users,DC=contoso,DC=com"))
{
    using (DirectoryEntry newUser = ou.Children.Add("CN=Jane Doe", "user"))
    {
        newUser.Properties["samAccountName"].Value = "jane.doe";
        newUser.CommitChanges();
    }
}

The second parameter to Children.Add is the class name. Miss it, or pass null, and you'll get the error. Pass a misspelled class like "usre" and you'll get a different error about a bad schema class — but sometimes AD confuses those.

Step 4 — If using raw LDAP, check the objectClass attribute

In a raw LDAP add request, you're sending something like this in the ModifyRequest or as a string:

dn: CN=Jane Doe,OU=Users,DC=contoso,DC=com
objectClass: user
samAccountName: jane.doe
cn: Jane Doe

If you leave out the objectClass line, you'll get 0x0000207B. Some LDAP libraries let you set attributes as a dictionary, and if you forget to include objectClass, same result. Add that line, and you're good.

Step 5 — Test with a simple PowerShell script

To verify your fix works, run this in an elevated PowerShell console (run as administrator):

$ou = [ADSI]"LDAP://OU=Users,DC=contoso,DC=com"
$newUser = $ou.Create("user", "CN=TestUser")
$newUser.Put("samAccountName", "testuser")
$newUser.Put("givenName", "Test")
$newUser.Put("sn", "User")
$newUser.SetInfo()

If this runs without error, the issue was a missing objectClass in your original code. Delete that test user afterward — Remove-ADUser testuser.

What to check if it still fails

If you've added objectClass and you're still seeing 0x0000207B, check these three things:

• Are you using a valid container? If your distinguishedName points to a container that doesn't exist or is an invalid path, AD might not even get to the object class check. Verify your base DN with [ADSI]"LDAP://YourDomain" — if it fails, your connection string is wrong.
• Is the schema writable? On a read-only domain controller (RODC), you can't create objects. You'll get a different error usually, but I've seen edge cases where it throws this one. Make sure you're targeting a writable DC.
• Are there mandatory attributes missing? Some classes require more than just objectClass. For a user object, samAccountName is required. For a group object, groupType is required. If you're missing a mandatory attribute, AD might fail before it finishes processing the class — and the error can be misleading. Check the schema for the class you're using to see what's mandatory. The ADSI Edit snap-in or LDP.exe can show you.

In all the times I've helped techs with this, the fix is almost always the same: include objectClass with the right name. It's a simple thing that's easy to overlook. Once you get into the habit of checking that first, you'll resolve this in under a minute.