Fix 0XC00002D9: Universal Group Can't Have Local Member

This error is annoying, but the fix is straightforward.

You're working in Active Directory Users and Computers, trying to add a group to another group, and bam — you get error 0XC00002D9. The message says: "A universal group cannot have a local group as a member." It usually happens when you're nesting groups across domains or within a single forest. I've seen it most often when someone tries to add a local group from a member server to a universal group in AD.

The direct fix: change the group scope

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the universal group you're trying to add members to. Right-click it and select Properties.
3. Go to the Members tab. If the error just happened, you'll see the failed entry is still there but grayed out or missing.
4. Close Properties. Right-click the group again, choose Properties, then the General tab.
5. Look at the Group scope section. You'll see it's set to Universal. Change it to Global or Domain local — but here's the catch:
   — If the group contains other universal groups or users from other domains, you cannot change it to Global. In that case, change it to Domain local.
   — If it only has users from the same domain, changing to Global works fine.
6. Click Apply. You should see no error. Then click OK.
7. Now, go back to the Members tab and add the local group again. It should take without complaint.

Quick test: After changing the scope, try adding a test user from the same domain. If that works, you're golden.

Why this works

Active Directory has strict rules about group nesting. Universal groups live in the global catalog. They can contain users, other universal groups, and global groups — but not domain local groups. Domain local groups are meant for resource permissions on a single domain. Mixing them breaks the forest-wide replication logic. By changing the universal group to domain local, you're telling AD: "This group only applies within this domain, so it's fine to have local members." Or, if you change it to global, you're saying: "This group is for same-domain users only, and it can still be added to universal groups elsewhere."

Less common variations of this issue

Here are two other scenarios where you'll see the same error, but the fix differs slightly:

1. Cross-forest trust with a universal group

You have a universal group in Forest A and you're trying to add a domain local group from Forest B. The error is the same. Fix? You can't nest groups across forests this way. Instead, add the domain local group's members (users or global groups) directly to the universal group. Or, create a new universal group in Forest B and add it to the universal group in Forest A.

2. Using ADSI Edit or PowerShell

If you're scripting group membership changes and hit this error, you're likely passing a domain local group SID to a universal group's member attribute. Check your script — ensure you're only adding objects with the correct scope. In PowerShell, use Get-ADGroup -Identity "YourGroup" -Properties groupType to verify scope before adding.

How to prevent this from happening again

• Plan your group nesting structure before you build it. Standard rule: domain local groups contain global groups, global groups contain users. Universal groups contain global groups or other universal groups. That's AGDLP (Accounts, Global, Domain Local, Permissions) or AGUDLP if you involve universal groups.
• Use descriptive naming that indicates scope. Prefix universal groups with "U-", domain local with "DL-", global with "G-". That way, you won't accidentally mix them.
• Train your team on the rules. I've seen this error more from junior admins who don't know the difference. A 10-minute training session saves hours of troubleshooting.
• Test in a lab first. If you're changing group scopes or adding cross-domain members, spin up a test environment. The error is obvious there, not in production.

One last thing: if you're in a hurry and just need to get a resource permission working, skip the universal group entirely. Use a domain local group on the resource server, add your global groups or users to it, and be done. That avoids the whole nesting headache.