0XC00002DA: Global group can't have cross-domain member fix

Why you're seeing this error (and why it's not the end of the world)

I ran into this one last month with a client who was migrating users from a legacy domain (oldcorp.local) to their new one (newcorp.com). Everything looked fine in ADUC, but when they tried to add a user from the new domain to a global group in the old domain, boom — the error popped up. The exact message: STATUS_DS_GLOBAL_CANT_HAVE_CROSSDOMAIN_MEMBER (0XC00002DA).

Here's the deal: Active Directory global groups can only contain members from their own domain. That's by design — it's not a bug. If you see this error, it means you're trying to add a user, group, or computer from another domain into a global group. Happens a lot during domain migrations, ADMT upgrades, or when someone drags-and-drops objects in ADUC without thinking about group scope.

Fix #1: Change the user's membership (30 seconds)

This is the easiest fix. Don't touch the group yet. Instead, check if the user from the other domain really needs to be in that global group. Often, you can just add them to a local group on the member server or use a universal group instead.

1. Open Active Directory Users and Computers (ADUC).
2. Find the user from the foreign domain that's causing the error.
3. Remove them from the global group (yes, it's that simple).
4. Add them to the local group on the resource server, or use a universal group if you need cross-domain membership.

I had a client whose accounting team needed access to a printer server across domains. Instead of forcing a global group, I added the users to a local group on the print server. Took 20 seconds and never saw the error again.

Fix #2: Change the group scope to Universal (5 minutes)

If the global group has to have members from multiple domains, change its scope. Universal groups can hold members from any domain in the forest. Here's how:

1. Open ADUC.
2. Find the group that's throwing the error. Right-click → Properties.
3. Go to the General tab.
4. Under Group scope, select Universal. Note: you can only change a global group to universal if it's not a member of any other global group. If it is, remove it from those groups first.
5. Click OK. That's it.

One gotcha: changing a global group to universal changes its security behavior. Universal groups are cached in global catalog, so they replicate more widely. For small-to-medium domains, this is usually fine. But if you've got a massive multi-site forest, you might want to reconsider.

Fix #3: Use ADSI Edit to force the membership (15+ minutes — advanced)

Okay, this is the nuclear option. Only use if you're absolutely sure the membership is valid and something got corrupted. I've seen this happen when an in-place domain upgrade leaves behind stale SID history or when ADMT doesn't clean up properly.

Warning: Messing with ADSI Edit can break things. Back up your AD database first.

1. Open ADSI Edit. (If you haven't used it before: Run → adsiedit.msc)
2. Connect to the domain partition of the domain containing the group.
3. Browse to the group object (CN=Users or wherever it lives).
4. Right-click the group → Properties.
5. Find the attribute member. Double-click it.
6. You'll see a list of DNs (distinguished names). Look for the foreign user's DN. If it's there and shouldn't be, remove it. If it's missing and should be there, add it.
7. To add: click Add, type the full DN of the foreign user (e.g., CN=jsmith,OU=Users,DC=newcorp,DC=com).
8. Click OK, then OK again.

After you do this, run repadmin /syncall to force replication. Then test membership. If the error persists, you might have a corrupted group object — in that case, recreate the group from scratch and migrate members manually.

What NOT to do

• Don't ignore this error and try to force-add the member with PowerShell or scripts. It'll just fail silently or corrupt the group.
• Don't delete the group unless you've verified every application that uses it.
• Don't change the group type to Distribution (unless it's a distribution group) — that breaks security permissions.

One quick tip: if you're in the middle of a domain migration and hitting this error left and right, batch-convert global groups to universal groups using PowerShell. Here's a one-liner that works for most groups:

Get-ADGroup -Filter {GroupScope -eq 'Global' -and GroupCategory -eq 'Security'} | Set-ADGroup -GroupScope Universal

That'll blast through all security global groups in one go. But test on a non-critical group first.

When to call a pro

If you're still seeing this error after trying all three fixes, you might have a deeper issue: forest trust problems, SID history corruption, or a broken schema. That's when you need to break out the domain controller logs and check for underlying replication errors. But in 9 out of 10 cases, one of the fixes above will get you back to work.

I've cleaned up after three different migrations where this error was the main culprit. It's always a group scope or a mis-applied ADMT rule. Start with Fix #1, work your way up. You'll be done before lunch.