Fix Active Directory error 0xC00002DB: cross-domain local group

This error pops up when you try to add a domain local group from another domain into a local group. Only universal or global groups from other domains can be members of a local group.

Quick answer for advanced users

You cannot nest a domain local group from a different domain into another domain local group. Change the member group's scope to Universal, or add a universal/global group from the other domain instead.

What's happening here?

This error occurs specifically in multi-domain Active Directory environments. Say you're in the corp.contoso.com domain and you try to add a domain local group named Finance-Admins from the europe.corp.contoso.com domain into a local group on a server or into another domain local group. Windows stops you cold with error code 0xC00002DB.

The reason is simple: domain local groups are designed to contain members from any domain, but only at the universal or global scope. If you try to stuff a domain local group from another domain into a local group, Active Directory says "nope" because that would create a security boundary headache. Domain local groups can only contain other domain local groups from the same domain, plus universal groups and global groups from any trusted domain. A local group on a member server or workstation has the exact same rule—it's basically the same restriction.

I've seen this happen most often when an admin tries to centralize permissions across domains by nesting groups. They grab a group from another domain without checking its scope, and boom—this error shows up in the GUI or in PowerShell.

Fix steps

Identify the offending group. Open Active Directory Users and Computers (ADUC) on a domain controller. Find the group you tried to add—the one from the other domain. Right-click it, go to Properties, and look at the "Group scope" field. If it says "Domain local", that's your problem.
Change the group's scope to Universal. You can only change scope if the group isn't a member of any other group and doesn't have any members that are domain local groups from other domains. In ADUC, right-click the group, choose Properties, then under "Group scope" select "Universal". Click Apply. You'll see a warning about possible conversion issues—proceed only if you're sure. After you click OK, the group's scope changes immediately.
Re-attempt the membership add. Now go back to the target group where you originally got the error. Add the universal group you just converted (or a different universal/global group from the other domain). This time it should succeed. You'll see the group appear in the membership list without errors.
If you can't change the scope (maybe the group has nested groups that prevent it), create a new universal group in the source domain, add the domain local group as a member of that universal group (same domain, so it's allowed), then add the universal group to your target local group. That's a workaround but works fine.

Alternative fixes

If changing scope isn't an option, here's what else you can try:

Use a global group instead. If the group you're adding is a domain local group because it needs to grant access to resources in its own domain, you might be overthinking it. Create a global group in the source domain, put the users in there, and add that global group to your local group. Global groups from any trusted domain can be nested into local groups—no restrictions there.
Switch to a universal group for the target. If the target is another domain local group, consider changing the target group to universal scope (if that fits your design). Universal groups can contain any security principal from any domain, including domain local groups. But be careful—universal groups replicate to global catalog, so don't go wild.
Use group nesting within the same domain first. Put the domain local group from the source domain into a universal group in that same domain. Then add that universal group to your local group. This avoids the cross-domain nesting error entirely.

Prevention tip

Here's a rule I drill into every admin I train: domain local groups are local to their domain only. They can't cross domain boundaries as members. If you're designing a multi-domain AD structure, stick to the AGDLP principle (Accounts, Global groups, Domain Local groups, Permissions) or the newer AGUDLP (Accounts, Global groups, Universal groups, Domain Local groups, Permissions). That means cross-domain membership should always use universal or global groups on the member side. Verify the scope of any group you're pulling from another domain before you try to add it. A quick Get-ADGroup <GroupName> -Properties GroupScope | fl GroupScope in PowerShell saves you this headache.