The Hidden Group Membership in Active Directory

You pull a report of everyone in Domain Admins, it looks clean, and you move on. But Active Directory has a quiet way for an account to belong to a group without showing up in that group's member list. It's called the primary group, and if you only ever read the usual membership, you can miss it.

This isn't exotic. It's a normal AD attribute that most environments never touch, which is exactly why a wrong value stands out once you know to look. Here's what it is, why it's a blind spot, and how to check your own domain in a few minutes.

Quick answer

Every AD account has a primaryGroupID. Its group membership does not show up in the group's member list or the user's memberOf, so reports that read those attributes miss it. The normal value for users is Domain Users (513). Anything else is worth checking, and you can list them in one PowerShell line.

What the primary group is

Every user and computer account in Active Directory has a primaryGroupID attribute. It holds the RID of one group and makes the account a member of that group, without an entry in the normal member list.

The attribute is a leftover from POSIX and old Services for UNIX and Macintosh setups, where a primary group was needed for file ownership. Almost nothing uses it now, so in a modern domain it should sit at its default and stay there. That is what makes a changed value interesting.

Why it's a blind spot

Here's the quirk. When an account's membership comes from its primary group, Active Directory does not write it into the group's member attribute or the user's memberOf. Those two attributes are what most tools, scripts and audit reports read.

So a user can have a primary group of, say, a privileged group, and:

• The group's Members tab in ADUC doesn't list them.
• Their Member Of tab doesn't list that group.
• A quick export of group membership doesn't include them.

The access is real, but the usual membership view doesn't show it. This is why a tidy-looking Domain Admins report isn't the whole story on its own.

The default values

Each account type has a normal primary group. Knowing these is the whole trick, because anything off this list is worth a closer look.

Account type	Default primary group	primaryGroupID
User	Domain Users	513
Computer	Domain Computers	515
Domain controller	Domain Controllers	516
Read-only DC	Read-only Domain Controllers	521

Privileged groups have low RIDs too: Domain Admins is 512 and Enterprise Admins is 519. A standard user account whose primary group reads 512 is the pattern you're looking for.

How to check your domain

You don't need a tool for a first pass. From a machine with the Active Directory PowerShell module, list any user whose primary group isn't Domain Users:

Get-ADUser -Filter 'primaryGroupID -ne 513' -Properties primaryGroupID |
    Select-Object SamAccountName, primaryGroupID

Then do the same for computers, which should be 515. Leave your domain controllers out, since they're correctly 516:

Get-ADComputer -Filter 'primaryGroupID -ne 515 -and primaryGroupID -ne 516' -Properties primaryGroupID |
    Select-Object Name, primaryGroupID

In most domains both lists come back empty or very short. Each result is either something you can explain or something to fix.

Reading it in ADUC

To see one account's primary group in the console, open the user, go to the Member Of tab, and look at the Primary group line below the member list. If the tab is missing because you opened the user from search, that's the ADUC quirk I covered in getting the Attribute Editor tab back.

What to do with a non-default value

For each account on your list, there are two clean outcomes.

• It's legitimate: if the account genuinely should be in that group, add it as a normal member, then reset the primary group back to the default. The access stays, but now it shows up in reports.
• It's not: reset the primary group to the default for that account type and investigate how it changed. A standard user pointed at 512 is a red flag, not a config choice.

To stay ahead of it, turn on directory service change auditing and watch for edits to the primaryGroupID attribute. In the Security log, a user account change shows as event 4738, and a directory object modification as 5136. Microsoft Defender for Identity also ships a built-in assessment that lists accounts with a non-default primary group ID, which is a good scheduled check.

This is the kind of quiet gap a proper review turns up. If you want a second pair of eyes on your AD and network, it's part of my Office Network Review.

Frequently asked questions

Does the primary group actually grant access?

Yes. The primaryGroupID gives the account membership in that group with the same rights as a normal member. The only difference is that it does not appear in the group member list or the user memberOf attribute.

Why does a report not show primary group membership?

Because Active Directory does not store it in the group member attribute or the user memberOf. Most reports read those attributes, so a primary-group relationship is invisible to them unless they check primaryGroupID directly.

What is the normal primaryGroupID value?

513 for users (Domain Users), 515 for computers (Domain Computers), 516 for domain controllers and 521 for read-only domain controllers. Other values, especially 512 for Domain Admins, are worth checking.

How do I fix an account with the wrong primary group?

If the membership is legitimate, add the account to the group as a normal member and set its primary group back to the default. If it is not, reset the primary group to the default for that account type and investigate the change.