Active Directory Universal Group Nesting Error 0XC0000358 Fix
Your account group can't contain a universal group. Here's the quick and real fix, no fluff.
The 30-Second Fix – Check What You're Adding
I've seen this error more times than I care to count. Usually, someone's trying to add a universal group to a security group that's in a domain local or global group – and it just won't stick. The error message says 0XC0000358 (STATUS_DS_AG_CANT_HAVE_UNIVERSAL_MEMBER), and it's about group scope rules.
Real-world scenario: Last month, a client's HR department couldn't give their payroll team access to a shared folder. They'd created a universal group called 'Payroll-All' and tried adding it to 'HR-Security-Group' – an account group. Boom, error.
Here's the 30-second check: Look at the group you're adding the universal group to. Is it a domain local or global security group? If yes, check its scope in Active Directory Users and Computers. Account groups (like 'Domain Admins' or custom ones) cannot contain universal groups as members. It's a Windows Server limitation, not a bug.
If you're sure it's an account group, the fix is simple: don't nest a universal group inside it. Either change the universal group's scope to global or domain local, or use a different group for membership.
To verify: Right-click the group, go to Properties, check the 'Group scope' field. If it says 'Domain local' or 'Global', you're in the clear for adding universal groups. If it says 'Security' and 'Domain local', you're fine. But if it's an 'Account group' (like a distribution group turned security group), that's your problem.
The 5-Minute Fix – Change Group Scope or Nesting
Did the quick check not resolve it? Let's get hands-on. The error means the target group's scope doesn't allow universal members. Here's how to fix it properly.
Step 1: Check the target group's scope
Open Active Directory Users and Computers (ADUC). Find the group you're adding the universal member to. Right-click, Properties, 'General' tab. Under 'Group scope', note it. If it's 'Domain local' or 'Global', you can add universal groups. If it's 'Universal', you can't add another universal group (no nesting of same scope is allowed).
Step 2: Change the target group's scope
If it's a universal group and you need it to contain a universal group, you can't. But if it's a domain local or global, and you're still getting the error, check the group type. If it's a 'Security' group but you see 'Account group' in the description, change it to a 'Domain local' or 'Global' scope. Right-click the group, choose 'Properties', then under 'Group scope', select 'Domain local' (or 'Global'), and click OK. This might require elevating privileges.
Step 3: Use a different membership method
If changing scope isn't possible (like if it's a built-in group), create a new group that can contain the universal group. For example, make a new domain local security group, add the universal group to it, then add that domain local group to the original account group. It's a workaround, but it works.
I've done this dozens of times. It's not elegant, but it keeps things running while you plan a proper restructuring.
The Advanced Fix (15+ Minutes) – Restructure Group Nesting
If you're reading this, the quick fixes didn't cut it, or you're dealing with a complex AD environment. I get it – I've had to rebuild group structures for clients who had hundreds of groups with messed-up nesting.
Here's the deep dive: The error occurs because of group nesting rules in Active Directory. Specifically, account groups (also called 'security groups' with the 'Account' group type) cannot contain universal groups. Universal groups can only be members of domain local groups or other universal groups (but not universal groups in the same domain – that's a different error).
Why this matters in real life: You might have a universal group that spans multiple domains in a forest. If you try to add it to a domain local group in another domain, it'll work. But if you add it to an account group (like a domain local group in the same domain that's also an account group), you get 0XC0000358.
Step 1: Audit your groups
Run this PowerShell command to list all groups with their scope and type:
Get-ADGroup -Filter * -Properties GroupScope, GroupCategory | Select Name, GroupScope, GroupCategoryLook for groups with GroupCategory = Security and GroupScope = Universal. Those are your problem children if they're in an account group.
Step 2: Recreate or convert the universal group
If the universal group is only used in one domain, convert it to a global group. That's safe and resolves the nesting issue. Use PowerShell:
Set-ADGroup -Identity "YourUniversalGroup" -GroupScope GlobalThis only works if the group doesn't have universal members already (you'll get an error if it does). Remove those first.
Step 3: Restructure using domain local groups
Best practice: Use domain local groups for resource access (like file shares), global groups for users and computers, and universal groups only when necessary (like cross-domain access). If you have a universal group being added to a group that's already domain local, you're fine. But if it's an account group, create a new domain local group, add the universal group to that, then add the new domain local group to your account group.
Step 4: Check for duplicate or corrupted groups
Rare, but I've seen it. Use repadmin to check replication. If the group object is corrupted, delete and recreate it.
Real story: A client had a forest with three domains. Their universal group 'Corp-Users' was supposed to give access to an app in Domain B. They kept getting 0XC0000358. Turned out the app's security group in Domain B was a domain local group, but it was marked as an account group (the previous admin had misconfigured it). Changed it to a security group, and it worked instantly.
Pro tip: Always use domain local groups for resource permissions. Global groups for user collections. Universal groups for cross-domain needs. Never nest universal groups inside account groups. It's a rule that will save you headaches.
If you're still stuck, check the exact error in the event log (Event ID 0). It'll tell you the specific group that's failing. Then you can target it directly.
Was this solution helpful?