Fix ERROR_DS_ILLEGAL_SUPERIOR (0X00002099) in AD

I know this error is infuriating—you're trying to create a user or group in Active Directory, and the system slaps you with ERROR_DS_ILLEGAL_SUPERIOR (0X00002099). The message says the parent isn't on the list of possible superiors. But what the heck does that mean?

In plain terms: Active Directory has rules about what types of objects can live where. Those rules come from the schema. If you're trying to drop a computer into an OU that's not meant for computers—or a user object under a container that only allows groups—you'll hit this error.

Here's the kicker: the fix isn't always obvious, and sometimes you have to bend the schema to your will. Let's get into the most common cause first, because that's what you'll hit 90% of the time.

Cause 1: You're Creating an Object in the Wrong Container

The most common trigger for 0X00002099 is simple: you're trying to add an object to a container that doesn't allow that object type. For instance, you might be creating a new user directly under a Group Policy Object container, or maybe you're trying to put a printer under an OU that's specifically tied to a different class.

Let me give you a real-world scenario. I once had a junior admin open ADUC and try to create a user account inside the ForeignSecurityPrincipals container. That container has a specific object class and won't let you add standard user objects. The error appeared instantly. The fix? Create the user in the standard Users container or an appropriate OU, then move it later if needed.

Here's how to check what the schema actually allows for a particular container:

1. Open ADSI Edit (adsiedit.msc).
2. Connect to your domain's naming context.
3. Right-click the parent container where you're trying to create the object and choose Properties.
4. Look at the possibleInferiors attribute—that lists the object classes you can create inside that container.

If the object class you want isn't in that list, that's your problem. The fix is simple: pick a different parent container that actually supports your object type. For users and groups, that's usually an OU or the Users container. For computers, it's an OU or the Computers container.

Don't try to force it by using PowerShell to create the object directly—it'll still fail with the same error. Trust me, I've tried.

Cause 2: The Schema Doesn't Allow That Object Under an OU

Sometimes you're creating a brand new OU, and you want to place a specific type of object there—like an inetOrgPerson or a contact—and you get the error. That's because the schema's possSuperiors attribute for that object class doesn't include organizationalUnit.

This happens more often with custom or less common classes. For example, you might have extended your schema to include a custom class called myCompanyAsset. By default, that class might only allow domainDNS as a superior, not an OU. So when you try to create it under an OU, boom—error.

The fix here is to modify the schema to allow the object to reside under OUs. But be careful—schema changes are replicated to every domain controller in the forest, and they can't be easily undone. Only do this if you really need that placement.

Here's a PowerShell script to check what superiors an object class currently allows:

# Replace with your object's class name, e.g., 'user' or 'inetOrgPerson'
$schemaNamingContext = (Get-ADRootDSE).schemaNamingContext
$class = Get-ADObject -SearchBase $schemaNamingContext -Filter {Name -eq 'user'} -Properties possSuperiors
$class.possSuperiors

If organizationalUnit isn't in that list, you need to add it. That means editing the schema via the Schema Management MMC or using a script. Here's the PowerShell way to add OU as a possible superior for a class (requires Schema Admins):

# Load the schema module
Import-Module ActiveDirectory

# Get the class's DN
$schemaNamingContext = (Get-ADRootDSE).schemaNamingContext
$classDN = "CN=user,$schemaNamingContext"  # Adjust for your class

# Add organizationalUnit to possSuperiors
Set-ADObject -Identity $classDN -Add @{possSuperiors='CN=Organizational-Unit,$schemaNamingContext'}

After running that, wait for schema replication (or force it with repadmin /syncall), then try creating your object again. This fix is the nuclear option, so use it only when you're sure you need that placement.

Cause 3: The Parent Is a Container That Has Restrictions

Less common, but I've seen it: the parent container itself is a special system container with built-in restrictions. For example, the LostAndFound container or the System container might not allow certain object types because of security descriptors or schema rules.

Another scenario: you've moved an OU to a different part of the tree, but the OU's own class still has its original possSuperiors restrictions. For example, you might have a msExchManagementBoundary object that's only allowed under the Microsoft Exchange container, and you've moved it elsewhere—now you get 0X00002099 when trying to add child objects.

In this case, you need to check the object class of the parent itself. Use ADSI Edit to look at the objectClass attribute of the parent. If it's something like container rather than organizationalUnit, that might be the issue. Standard containers have a different set of allowed children than OUs.

The fix for this is less about schema changes and more about choosing the right parent. If you're trying to create a user under a plain container object (not an OU), that should generally work, but if it doesn't, check if the container has any custom auxiliaryClass that might be interfering.

One real-world example: I saw a custom application create a container class called serviceAdminContainer. That class only allowed its own children. When someone tried to create a standard user under it, they hit 0X00002099. The fix was to place the user in a regular OU and reference it from the application's configuration.

If you're absolutely stuck and the parent must stay as is, you can use the same schema modification technique from Cause 2 to add the desired child class to the parent's possibleInferiors attribute. But again, weigh the risks.

Quick Reference Summary

At the end of the day, this error is about Active Directory's rules—and those rules are there to keep order. But when they block legitimate work, you need to know how to work around them intelligently. Start with the first fix (it's the most common), then move to schema changes only if you really need that specific placement.

If you've tried all these and still see the error, double-check your permissions—sometimes the error message is misleading, and the real issue is that you don't have the right to create objects in that parent. But that's a story for another day.