Fix 0xC00002E6: Foreign Security Principals in Universal Groups

You're trying to add a user from another domain to a universal group

You get this error and it stops you dead. I've seen this happen when someone tries to add a partner company's user account to a universal security group in AD.

Fix: Change the group scope

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the universal group that's giving you trouble.
3. Right-click it → Properties → Group scope.
4. Change from Universal to Global or Domain local.
5. Click OK. Now try adding that foreign security principal again.

That's it. The error goes away immediately.

Why this works

Here's the thing: universal groups replicate to all domain controllers in the forest. To keep replication efficient, Microsoft decided that universal groups can't contain foreign security principals—those are SIDs from outside the forest. A foreign security principal is just a placeholder object that represents a user or group from a trusted external domain.

The error code 0xC00002E6 literally means "no foreign security principals in universal groups." It's not a bug—it's by design. The group membership list for a universal group must be forest-wide consistent, and external SIDs would break that.

Domain local groups, on the other hand, only exist on the domain controller where you create them. They can contain users from any trusted domain, including foreign security principals. Global groups can contain users from the same domain, but not external ones—so if you need to add external users, use domain local.

Less common variations

• Nesting groups across domains: You might also see this if you try to nest a universal group from another domain into a universal group in your domain. Same restriction applies.
• Windows Server 2008 R2 vs newer versions: The behavior is consistent from Server 2008 R2 through Server 2022. No version-specific workaround exists.
• Azure AD Connect: If you're syncing groups to Azure AD, universal groups might not sync properly when they contain external members. Change to domain local first, then sync.
• PowerShell error: You can also hit this via Add-ADGroupMember. The fix is the same—change the group scope.

Prevention

Stop creating universal groups for cross-domain access. It's a common mistake. Use domain local groups for resources that external users need. Use global groups for internal users. Then nest global groups into domain local groups if you have to.

Check your existing universal groups for any external members by running this:

Get-ADGroup -Filter {GroupScope -eq "Universal"} -Properties Members | Where-Object { $_.Members -match "ForeignSecurityPrincipal" }

If any show up, change the group scope before you run into trouble.

One more thing: if you change a universal group to global, you might break permissions on resources that already use that group. Test in a lab first. Domain local is usually safer for cross-domain stuff.

That's the fix. No registry hacks, no reboot required. Just a scope change.