FIX: ERROR_DS_GLOBAL_CANT_HAVE_LOCAL_MEMBER (0X00002144) – Global Groups Can't Nest Local Groups

You just got hit with this error

It's annoying, especially when you're in the middle of setting up nested groups for permissions and AD Management Studio throws ERROR_DS_GLOBAL_CANT_HAVE_LOCAL_MEMBER (0X00002144) at you. The error message is clear enough: "A global group cannot have a local group as a member." But what does that actually mean, and how do you work around it?

The fix: don't put a local group inside a global group

The immediate fix is straightforward: instead of adding the local group (like Domain Local Group) to the global group, add the user account directly to the global group. Or, if you need the permissions that the local group was supposed to carry, add the global group to the local group instead — that's the allowed direction.

Here's the exact step-by-step:

1. Identify the member you're trying to add — right-click it in AD Users and Computers and check its Group scope property. If it says Domain Local, that's your problem member.
2. Instead of adding that Domain Local group to the Global group, remove it from the Global group's membership list.
3. Now add the global group to the Domain Local group's membership instead. That's allowed. Or add the user account directly to the global group if that gives you the same access.
4. Wait for replication if needed — but usually this takes effect immediately within the same domain.

Why this restriction exists

The reason step 3 works is rooted in how Active Directory group scopes are designed. Group scopes aren't arbitrary — they control where a group can be used and what can be a member.

• Global groups can contain user accounts and other global groups from the same domain only. They can't contain Domain Local groups or Universal groups from anywhere.
• Domain Local groups can contain users, global groups, and universal groups from any domain in the forest — but they can't be members of any other group outside their domain.
• Universal groups can contain users, global groups, and other universal groups from any domain, but they can't contain Domain Local groups.

What's actually happening here is a scope mismatch. AD enforces these rules to prevent circular nesting and to keep replication traffic predictable. Imagine if a global group (which replicates to the global catalog) could contain a Domain Local group (which doesn't replicate at all) — membership calculations would break across domains. The rule prevents that.

Less common variations of the same problem

This error doesn't just pop up in ADUC. You might see it in:

• PowerShell when using Add-ADGroupMember — the error looks the same but with a PowerShell exception wrapper around it.
• LDIFDE import scripts — if you're importing group membership via LDIF, the error surfaces at the LDAP level. Same fix applies: check the member DN's groupScope attribute.
• Cross-forest group nesting — a global group from Forest A can't contain a Domain Local group from Forest B, even though the error wording is the same. The root cause is still scope mismatch, but you'll need to use a Universal group or direct user membership instead.
• Exchange or SharePoint auto-nesting — some admin scripts that automate group provisioning try to nest groups without checking scope. You'll get this error during script execution. Audit the script logic to add users, not groups.

A specific real-world scenario: you're setting up a file server permissions structure. You have a Domain Local group called FS_Sales_Read that grants read access to the sales share. You try to add that group to a Global group called G_Sales_Team thinking it will cascade permissions. Nope — 0X00002144 every time. The fix: add G_Sales_Team to FS_Sales_Read instead, or add individual sales users to both groups.

How to prevent this in the future

Prevention is about understanding group scope before you start nesting. A simple rule: never try to put a Domain Local group inside anything else. Domain Local groups are designed to be the outermost container — they hold permissions for resources and can include users and global groups from anywhere.

When designing your AD group structure, follow the standard AGDLP model (Accounts, Global groups, Domain Local groups, Permissions). That means:

• Put user accounts into Global groups.
• Put those Global groups into Domain Local groups that represent resource permissions.
• Assign the Domain Local group to the resource's ACL.

If you're using a script to automate group membership, add a check on the groupType attribute before adding a group as a member. Something like:

$group = Get-ADGroup -Identity "TargetGroup"
if ($group.GroupScope -ne 'DomainLocal') {
    Add-ADGroupMember -Identity $group -Members $userDN
} else { Write-Warning "Can't add to Domain Local group as member" }

Also, document your group scope plan. If everyone on the team knows that Global groups only hold users (or other Global groups from the same domain), this error won't surprise you again.

Remember: the error is telling the truth. You just can't do what you tried. The fix is simple — reverse the nesting direction or add users directly. Don't fight the scope rules, work with them.