STATUS_DS_OID_MAPPED_GROUP_CANT_HAVE_MEMBERS (0XC000A087) Fix

When This Error Hits

You're in Active Directory Users and Computers (ADUC) or PowerShell, trying to add a user or computer to a security group. The group's type shows as Security Group – Universal with a weird attribute set. You click OK and get slapped with STATUS_DS_OID_MAPPED_GROUP_CANT_HAVE_MEMBERS (0XC000A087). The operation fails immediately — no partial success, no members added.

This happens most often when someone created a group with an OID-mapped groupType value — usually from a script or third-party tool that set the flag GROUP_TYPE_OID_MAPPED (0x80000000) on the groupType attribute. You'll see this on Windows Server 2016, 2019, and 2022 AD environments.

Root Cause

What's actually happening here is that the group has the OID_MAPPED bit set in its groupType attribute. This bit tells AD the group is linked to an external OID (Object Identifier) scheme — think of it as a group that maps to an attribute in another directory or schema. AD explicitly forbids adding direct members to these groups because the membership is supposed to be computed from the OID mapping, not manually assigned. The error code 0XC000A087 is NTSTATUS for "this group type can't have members added directly."

The trigger's almost always a script that creates groups using a value like 0x80000002 (universal + OID mapped) instead of 0x80000000 (universal only). Or someone accidentally set the flag in an attribute editor. Either way, the group's stuck in a state where AD won't let you touch its membership.

The Fix

The real fix is to clear the OID_MAPPED bit from the group's groupType attribute. You can't do this through ADUC's GUI — it won't show the option. You need ADSI Edit or PowerShell. Skip recreating the group from scratch; that loses ACL history and SID references. Just flip the bit.

1. Open ADSI Edit — Run adsiedit.msc. Connect to the domain partition that holds the group (usually DC=yourdomain,DC=com).
2. Find the group — Navigate to the OU where the group lives. Right-click the group and choose Properties.
3. Locate the groupType attribute — In the attribute editor, find groupType. Double-click it. You'll see a decimal value like -2147483646 (which is 0x80000002 in hex).
4. Remove the OID_MAPPED bit — The OID_MAPPED flag is 0x80000000. To clear it, subtract that hex value. So if your value is 0x80000002 (universal + OID mapped), change it to 0x00000002 (universal only). In decimal: from -2147483646 to 2. Click OK.
5. Apply and test — Close the properties, then try adding a member via ADUC or PowerShell. If it works, the fix stuck.

If you prefer PowerShell, here's the command:

Get-ADGroup -Identity "YourGroupName" | Set-ADGroup -Replace @{groupType=2}

The reason this works is that groupType=2 is a pure universal security group with no OID mapping. AD then treats it like a normal group and lets you add members. Just be sure the group's scope is actually universal before you do this — if it's global or domain local, use the correct base value (2 for global, 1 for domain local).

Still Failing?

If changing groupType doesn't help, there's a second possibility: the group might be a linked-value group in a forest with restricted membership policies. Check the msDS-GroupMembershipLDAPFilter attribute — if it's populated, the group uses dynamic membership rules, and you can't add direct members. You'd need to clear that filter attribute entirely. But that's rare. 99% of the time, it's the OID_MAPPED bit.

Another thing to verify: if the group was created by Azure AD Connect or a similar sync tool, it may have the OID_MAPPED flag set intentionally to prevent local edits. In that case, you're fighting the sync engine — disable the sync rule for that group first, then clear the flag. Or create a separate group for on-prem membership.

Bottom line: don't recreate groups. Fix the attribute. Took me an hour the first time I hit this because I assumed the group was corrupt. It wasn't — just a bad flag.