Fixing ERROR_DS_GLOBAL_CANT_HAVE_CROSSDOMAIN_MEMBER (0x2147)

What's Actually Happening Here

You're trying to add a user (or group) from another domain into what Active Directory thinks is a global group. AD's global groups have a hard rule: they can only contain members from the same domain. The error code 0X00002147 is AD's polite way of saying "nope, that breaks the rules."

This usually pops up in environments with multiple domains connected by a forest trust — you have users in domainA.com and groups in domainB.com, and someone tried to drag a user across the boundary into a group that's scoped as Global. The fix isn't complicated, but you need to understand why the rule exists: global groups replicate to every domain controller in the forest. If they could hold cross-domain members, the replication overhead would explode, and membership resolution would become a nightmare.

Cause #1: The Group Is Scoped as Global — Should Be Universal

This is the most common trigger. You have a group — let's call it Finance-Users — sitting in domainA.com. It's a Global group. You try to add jsmith@domainB.com. AD says no.

The Fix

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the group. Right-click → Properties.
3. Go to the General tab. Look at Group scope. If it says Global, that's your problem.
4. Change it to Universal.

But wait — you can't always change a global group to universal directly. The restriction: the group must not be a member of another global group. If it is, remove it first, change the scope, then re-add it. Universal groups can contain members from any domain in the forest. That's exactly what you need.

Why this works: Universal groups store their membership in the Global Catalog. Every DC can resolve the members without replicating the full membership list to every domain. That's the trade-off — universal groups are for cross-domain membership, global groups are not.

Cause #2: The Group Is Nesting Incorrectly

Less common but trickier. You might have a Domain Local group that contains a Global group from another domain. That's actually allowed. But if you then try to nest that Domain Local group inside another Global group, AD throws the same error — because the Domain Local group now effectively contains cross-domain members.

Here's the real-world scenario: DL-Servers (domain local in domainA.com) contains G-Admins@domainB.com (a global group). You try to add DL-Servers to G-AllAdmins (global in domainA). Boom, error.

The Fix

1. Check the nesting depth. AD allows up to 10 levels, but cross-domain rules matter more.
2. Break the chain: either change G-AllAdmins to Universal, or stop nesting DL-Servers inside a global group.
3. If you need the final group to be explicit for permissions, use a Universal group as the final target instead. That's what they're designed for.

The rule is simple: Global groups = single domain only. Universal groups = any domain in the forest. Domain Local groups = can contain groups from any domain, but they're only usable for ACLs on resources in their own domain. Know these boundaries and you'll stop hitting this error.

Cause #3: Mixed-Mode Domain Still in Effect

If your domain is still running in mixed mode (Windows 2000 or NT 4 compatibility), universal groups might not exist. Older AD versions didn't support them. You're stuck with global and domain local only.

This is rare in 2025 — almost everyone is at least Windows Server 2008 functional level — but I've seen it in orgs with legacy apps that never migrated off old DCs. The error code 0X00002147 will fire if you try to add a cross-domain member to a global group, and there's no "convert to universal" option because the domain functional level doesn't support it.

The Fix

1. Open Active Directory Domains and Trusts.
2. Right-click your domain → Raise Domain Functional Level.
3. Choose at least Windows Server 2003 or higher. That enables universal groups.
4. Now go back and change the group scope to Universal as described in Cause #1.

One caveat: raising the functional level is one-way. You can't go back without restoring from backup. Test in a lab first if you're skittish.

Quick-Reference Summary Table

Final Thought

This error isn't a bug — it's AD enforcing a design constraint. Respect the group scope rules: Global = one domain, Universal = forest-wide, Domain Local = resource permissions in its own domain. Once you internalize that, 0X00002147 stops being a mystery and becomes a quick fix. Don't fight the tool; use the right scope.