Fix ERROR_MEMBER_IN_GROUP (0X00000528) in Active Directory

You're managing Active Directory on a Windows Server 2019 or 2022 domain controller. You run a script or use ADUC to add a user (say, jdoe) to a security group called 'SalesTeam'. Instead of success, you get the error ERROR_MEMBER_IN_GROUP (0X00000528). The message is clear: "The specified user already belongs to this group." But you check and don't see the user listed. It's confusing, but there's a simple reason and an even simpler fix.

Why This Happens

The culprit here is almost always nested group membership. The user jdoe might not be directly in 'SalesTeam', but they're a member of a group that is a member of 'SalesTeam'. For example, jdoe is in 'MarketingTeam', and 'MarketingTeam' is nested inside 'SalesTeam'. When you try to add jdoe directly, AD says "Hold up — they're already an indirect member." It's a safety check to prevent duplicate memberships that can cause confusing inheritance loops.

Other triggers:
- You're using PowerShell with Add-ADGroupMember and the user is already a transitive member.
- You're modifying group membership via LDAP directly (like with dsmod group) and hitting the same check.
- The group has a membership rule that includes the user from a parent OU or universal group.

Don't bother removing and re-adding the user — that won't work either. The fix is to identify the indirect membership and either accept it or restructure your groups.

How to Fix It

The fix is straightforward once you know where to look. You've got three options. Try them in order.

Option 1: Check for Indirect Membership (Recommended)

1. Open AD Users and Computers on a domain controller.
2. Right-click the group (e.g., 'SalesTeam') and select Properties.
3. Go to the Members tab. You won't see jdoe listed here if they're only indirect.
4. Instead, use PowerShell to see the full membership (including nested groups):
   

   Get-ADGroupMember -Identity "SalesTeam" -Recursive | Select-Object Name, SamAccountName

5. If jdoe shows up in the output, that's your indirect membership. You're done — you don't need to add them again.

If you really need jdoe to be a direct member for some scripting reason (like a filter that only checks direct membership), you can remove the nested group that contains them and add jdoe directly. But in my experience, that's rarely needed — just adjust your script to use -Recursive.

Option 2: Remove the Nested Group (If You Must)

1. Find which group is causing the nesting. Run:
   

   Get-ADGroupMember -Identity "SalesTeam" | Where-Object { $_.objectClass -eq "group" }

2. Check each returned group for jdoe via Get-ADGroupMember -Identity "MarketingTeam".
3. Once you find it, remove 'MarketingTeam' from 'SalesTeam' using ADUC or:
   

   Remove-ADGroupMember -Identity "SalesTeam" -Members "MarketingTeam" -Confirm:$false

4. Now add jdoe directly:
   

   Add-ADGroupMember -Identity "SalesTeam" -Members jdoe

Option 3: Bypass the Check (Advanced)

If you're using dsmod group or LDAP, you can sometimes bypass the duplicate check by adding the DN directly with the -chmbr switch. But I've seen this cause replication issues in multi-domain environments. Skip this unless you really know what you're doing.

Still Failing? Check These

If you still get the error after the steps above, look at these less common causes:

• Replication lag: The user was recently removed from the group on another DC, but the change hasn't replicated. Force replication with repadmin /syncall.
• Protected group: Is 'SalesTeam' a built-in protected group (like Domain Admins)? Those have special membership rules. You might need to use the AdminSDHolder process — but that's a whole other topic.
• Corrupted membership attribute: Rare, but the member attribute on the group can get corrupted. Use repadmin /showattr to check for duplicate DNs. If you see duplicates, you'll need to clean them with ADSI Edit.
• Cross-domain membership: Are you adding a user from another domain? Universal groups can contain foreign security principals, but domain local groups can't. Double-check group scope.

In 14 years, I've seen this error exactly twice where it wasn't solved by simply recognizing the indirect membership. Most of the time, you just need to accept that the user is already there and move on. Stop fighting AD — it's usually right.