You tried to drop a universal group into an account group and Active Directory slapped you with ERROR_DS_AG_CANT_HAVE_UNIVERSAL_MEMBER (0x00002182). Annoying, but the fix takes about two minutes once you know which group to change.
The fix
You have two paths, and which one you pick depends on why the nesting exists in the first place.
Option 1: Change the parent group's scope (most common fix)
An account group in AD terms is a domain local or global group with a specific membership restriction. A domain local group can hold universal members. A global group cannot. So if the parent is global, that's your problem.
- Open Active Directory Users and Computers (dsa.msc).
- Find the parent group that's throwing the error.
- Right-click it → Properties → General tab.
- Look at Group scope. If it says Global, you need to change it.
- Change it to Universal if you're in a single-domain forest, or Domain local if you plan to nest across domains.
- Click OK, then add the universal group as a member.
Same thing from PowerShell:
Set-ADGroup -Identity "Finance-ReadOnly" -GroupScope DomainLocal
Add-ADGroupMember -Identity "Finance-ReadOnly" -Members "All-Contractors-Universal"If you get a “The requested operation is not supported” error when converting scope, that group probably has a SID that's been replicated to a global catalog already, or it's a built-in group you can't touch. See the variations section below.
Option 2: Flatten the nesting
Sometimes the clean move is to skip the intermediate group entirely. If you were nesting Global-Group → Universal-Group just to piggyback permissions, add the universal group's members directly instead:
Get-ADGroupMember "All-Contractors-Universal" | ForEach-Object {
Add-ADGroupMember -Identity "Finance-ReadOnly" -Members $_.SamAccountName
}Not pretty, but it kills the scope conflict dead. Only do this if the universal group is small and static. If it churns, you'll be re-running this weekly.
Why this happens
AD group scopes have rules that were baked in back in Windows 2000 and haven't moved since. Here's the cheat sheet:
| Group scope | Can contain |
|---|---|
| Domain local | Users, computers, global groups, universal groups from any domain |
| Global | Users, computers, global groups from the same domain only |
| Universal | Users, computers, global groups, universal groups from any domain in the forest |
Read the middle row again. A global group can't hold a universal group. Not ever. That restriction is the entire reason ERROR_DS_AG_CANT_HAVE_UNIVERSAL_MEMBER exists.
Microsoft's recommended pattern is AGDLP: Accounts → Global → Domain Local → Permissions. Notice universal groups aren't in that chain. Universal groups belong in the middle of a forest-wide permission strategy, and they only make sense when you've got more than one domain.
Had a client last month — 40-person accounting firm, single domain, no trusts — who built a universal group for “vendors” because a blog post told them it was better for future growth. Two months later they tried to nest it in a global group for their file share ACLs and got 0x2182. Right answer for them was to convert the global group to domain local, not touch the universal group at all.
Less common variations
You can't change the group scope
If ADUC refuses to let you switch a group to universal, it's because the group is a member of another global group. AD won't let a group with global children become universal — you'd break the membership chain. Remove the parent memberships first, change the scope, then re-add.
Get-ADGroup -Identity "Parent-Group" -Properties MemberOf | Select-Object -ExpandProperty MemberOfForest functional level is too low
Universal groups don't exist at Windows 2000 mixed mode. If your forest is still at 2000 native or 2003 interim (rare but it happens in lab environments and old acquisitions), you'll get this error even on a domain local group. Check:
Get-ADForest | Select-Object ForestModeRaise it to at least Windows Server 2003 if you actually need universal groups. Nobody should be below 2008 R2 in 2024, but I've seen it.
You're trying to add a universal group to a mailbox-enabled account group
Exchange distribution groups are a different beast. If the target group is mail-enabled with a global scope, Exchange owns the scope field. You'll need to change it through the Exchange admin center or with:
Set-DistributionGroup -Identity "sales-all@company.com" -GroupType UniversalRegular Set-ADGroup will throw an access denied or schema violation on mail-enabled groups.
Third-party sync tools
Azure AD Connect, Okta, JumpCloud — most of them create groups with fixed scopes and won't let you change them from the AD side without breaking sync. If the group is synced from the cloud, edit the scope in the source system, not in ADUC. Changing it locally just gets overwritten on the next sync cycle.
Prevention
Stop building universal groups unless you've got multiple domains. That's it. That's the whole prevention strategy.
For everything else, follow AGDLP and you'll never see 0x2182 again. Universal groups are for scenarios where you need to grant access to resources across domains without putting accounts directly in domain local groups in every domain. If you're single-domain, universal is dead weight that just creates scope conflicts.
One more thing: document the scope of every security group you create and why. I've cleaned up so many AD messes where nobody remembered why a group was global versus domain local, and the next admin just guesses. A one-line description field in ADUC saves hours later. Use it.