Fix ERROR_DS_GLOBAL_CANT_HAVE_UNIVERSAL_MEMBER (0X00002145)
Active Directory won't let you add a universal group to a global group. The real fix is changing group scope or removing the bad membership.
You hit this error in Active Directory Users and Computers? Let's knock it out.
You're trying to add a universal group into a global group, and AD stops you cold with ERROR_DS_GLOBAL_CANT_HAVE_UNIVERSAL_MEMBER (0X00002145). I've seen this dozens of times. The fix is straightforward once you know the rule.
The direct fix: two ways to get this done
You have two options. Pick the one that fits your environment.
Option 1: Change the global group to universal
- Open Active Directory Users and Computers (dsa.msc).
- Find the global group that's causing the error. Right-click it and select Properties.
- Go to the General tab.
- Look for Group scope. Change it from Global to Universal.
- Click Apply. You should see the change take effect immediately—no error this time.
- Now add the universal group as a member. Right-click the group again, go to Members, and add the universal group. It should work.
When to use this: If the global group doesn't need to stay global for replication reasons (like across domains), this is the easiest path. Universal groups replicate to the global catalog, so if you're in a single-domain setup, it's fine.
Option 2: Remove the universal group membership
- Open Active Directory Users and Computers.
- Find the universal group you're trying to add. Right-click and select Properties.
- Go to the Member Of tab.
- Remove the global group from its membership list (if it's there).
- Click Apply. Then close the window.
- Now add the universal group to the global group. It should succeed.
When to use this: If you're locked into the current group structure—maybe the global group is used for permissions across domains and you can't change its scope.
Why this happens
Active Directory enforces group nesting rules from Windows 2000. Here's the short version:
- Universal groups can be members of domain local groups (and universal groups). Not global groups.
- Global groups can be members of universal groups and domain local groups.
The rule exists because global groups are meant to represent users from a single domain. Universal groups can contain users from any domain. If a universal group got into a global group, that global group would effectively span domains, breaking the whole model.
It's not a bug. It's by design. Annoying when you hit it, but it keeps your AD tidy.
Less common variations
Some scenarios look different but are the same root cause.
Nested universal groups in a global group
You have a universal group that itself contains another universal group. You try to add the parent universal group to a global group. Same error. The nesting depth doesn't matter—the first universal group in the chain triggers it.
Script or PowerShell errors
If you're using PowerShell with Add-ADGroupMember and get this error, the fix is identical. Check the group you're adding to and the group you're adding. Get-ADGroup <groupname> -Properties GroupScope will tell you the scope.
Get-ADGroup "YourGlobalGroup" -Properties GroupScope | Select-Object Name, GroupScope
If the output shows GroupScope : Global and you're trying to add a universal group, you need to change the scope or drop the universal member.
Third-party management tools
Tools like ManageEngine or Quest sometimes let you bypass the GUI check but still hit this error in the backend. Same fix applies.
Prevention
Plan your group scope before you build.
- Use universal groups for cross-domain permissions. They replicate to the global catalog, so all domain controllers see them.
- Keep global groups for user collections within a single domain. Don't nest universal groups inside them.
- If you need a group that spans domains, make it universal from the start.
One last thing: if someone else built the groups before you joined, run a quick audit. Use this PowerShell to find any global groups that contain universal members:
Get-ADGroup -Filter {GroupScope -eq "Global"} -Properties Members | Where-Object {
$_.Members | ForEach-Object {
(Get-ADObject $_).ObjectClass -eq "group"
}
} | Select-Object Name
That'll catch the ones that might cause trouble later. Save yourself a headache.
Was this solution helpful?