Active Directory 0X0000215A: Source Object Must Be Group or User

You're Seeing 0X0000215A — Here's Why

You were in the middle of moving or linking something in Active Directory Users and Computers (ADUC), and boom — that error. I've seen it a dozen times. Had a client last month whose entire print queue died because they accidentally tried to move a printer object into a group scope. The error's blunt: the source object has to be a user or a group. Nothing else.

The Fix: Check the Object Class

1. Open ADSI Edit (install it from Server Manager if you haven't — it's under AD DS tools).
2. Connect to the partition where the object lives (usually the domain partition).
3. Navigate to the object throwing the error. Right-click it, choose Properties.
4. Find the objectClass attribute. Look at its values. You'll likely see something like computer, contact, printQueue, groupPolicyContainer, or inetOrgPerson.
5. If user or group isn't the top-class value (or at least one of them), you've found the problem.

The quick workaround: convert the object to a user or group if that's appropriate. But honestly, 90% of the time you're just grabbing the wrong object. Go back to ADUC, make sure you're selecting a real user or group. If you need to move a computer, use the Computer container or delegate permissions properly.

Real-World Example

Had a sysadmin trying to add a contact object to a domain local group for email distribution. The contact wasn't a security principal — it's just a directory entry. Error popped immediately. Fix was creating a disabled user account with the same email, then adding that user to the group. Not elegant, but AD requires a security principal for group membership.

Why This Happens

Active Directory enforces strict object type rules for operations like moving, linking to groups, or delegation. The 0X0000215A is NTDS's way of saying "I can't process this — the object you gave me isn't a supported class." Under the hood, the DS checks the objectCategory and objectClass attributes. If the source doesn't match the expected user or group schema classes, it throws the error.

Common triggers:

• Dragging a computer into a group's member list
• Using ADUC's Move on a printer object
• Running PowerShell's Move-ADObject on a contact
• Group Policy management scripts targeting the wrong object type

Less Common Variations

Sometimes the error shows up in unexpected places:

• DFS Replication: If you're trying to add a DFS link to a group object (shouldn't, but people do).
• Exchange Management Console: Old Exchange 2010 tools might throw this when adding a mailbox-enabled contact to a distribution group without a proper security principal.
• Azure AD Sync: When synchronizing objects that aren't users or groups — like a service account with a broken objectClass — you'll get a similar error in the sync logs.
• LDAP scripts: Custom scripts using ldap_add or ldap_modify that pass the wrong DN to a group attribute.

If you're seeing it across many objects, check your schema modifications. A bad schema update can corrupt the objectClass inheritance. I once spent a day tracking down a schema extension that set auxiliaryClass wrong on a bunch of users. Re-registering the schema fix pack sorted it.

Prevention

Two things stop this from biting you again:

1. Know your object types. Train your junior admins — and yourself — to verify what you're clicking. A quick properties check in ADUC shows the object class under the Object tab (enable Advanced Features first).
2. Script with validation. If you're writing PowerShell scripts, always check objectClass before moving or modifying:

Get-ADUser -Filter * | Where-Object {$_.ObjectClass -eq 'user'} | Move-ADObject -TargetPath 'OU=Users,DC=domain,DC=com'

You can also set up a scheduled task to audit objects with unexpected objectClass values. Use Get-ADObject -Filter {objectClass -ne 'user' -and objectClass -ne 'group'} to catch strays before they cause trouble.

Last piece of advice: don't try to force the error by changing object classes manually unless you really know what you're doing. I've seen people corrupt the directory doing that. Stick to the standard classes, and if you need a non-user object to behave like one, create a dummy user and link it.