Another interesting troubleshoot I ran across where users weren't enumerating properly in a PowerShell script.
Problem statement: PowerShell script using Get-ADGroupMember was showing 6 entries, although there were actually 15. How did I know? Going to the Members tab of the group, I saw 15 entries. Going into Attribute Editor, I saw under the member attribute, 6 entries. This was actually hindering a project of cleaning up Active Directory groups.
Some are probably going to be lost without seeing this, so here is a practical example:
Note the names were changed to protect the innocent (actually, they were from my random name and user generator - https://blogs.technet.microsoft.com/leesteve/2017/09/19/ps-without-bs-creating-random-test-users-in-active-directory/ (and cheap plug complete).
Users: Susan Martinez, Sandra Johnson, Ruth Robinson, and Richard Harris.
Groups: Test Group A - Global, Test Group B - Universal
Membership: Test Group A - Global
Ruth Robinson
Sandra Johnson
Susan Martinez
Membership: Test Group B - Universal
NestedGroupA (a group from another domain)
Richard Harris
Sandra Johnson
How this all reproduces
The issue is in setting the Primary Group for a user. So, in this case, I set the following:
Susan Martinez: Primary Group: Test Group A
Sandra Johnson: Primary Group: Test Group B
Ruth Robinson: Primary Group: Domain Users
An example screenshot for Susan:
And when we go into Test Group A, I can see all 3 users: Ruth, Sandra, and Susan
When I go to the members attribute, I only 2 of the users: Ruth and Sandra.
Why is this?
Keep in mind that the following applies:
- Susan's primary group is Test Group A
- Sandra's primary group is Test Group B.
- When looking at Test Group A, a user who's primary group is in Group A will not be shown, but the user in Group B will.
- Any user who's primary group is Domain Users will not see this issue.
What are, and why primary groups?
When you are querying Active Directory with a LDAP utility such as LDP, the members attribute is not populated with the primary group. Primary groups served their purpose in the much older NT days, like NT4, but really today are irrelevant unless you are using POSIX or Mac clients.
The purpose it served is back in Windows 2000, when there was a limitation of 5000 users in a group. However, Windows Server 2003 Forest Functional Level removed such a limitation. So, this made setting the primary group irrelevant.
Detecting the problem
PowerShell to the rescue: I have created a quick and dirty PowerShell script which will help detect who is not set to primary group "Domain Users":
Feel free to season this to taste, obviously change the root domain and output file as needed...
$RootDomain="test.local"
$OutputFile="c:tempadusers_pg.txt"
Function ProcessDomain($strDomain){
$intUsers=0
$UserScan=(Get-ADUser -Filter {PrimaryGroupID -ne 513 -and SAMAccountName -ne "Guest"} -Server $Domain)
foreach ($User in $UserScan){
$intUsers++
$strDomain+","+$User.SamAccountName+"`n" | Out-File $OutputFile -Append
}
write-host $Domain": "$intusers
return $intUsers
}
$totalusers=0
$adDomain=Get-ADdomain $RootDomain
$Domain=$adDomain.DNSRoot
$users=(ProcessDomain -strDomain $Domain)
$totalusers+=$users
foreach($Domain in $adDomain.childdomains)
{
$users=ProcessDomain -strDomain $Domain
$totalusers+=$users
}
write-host "Total Users: $totalusers"
Moral of the story
Users shouldn't need the Primary Group attribute set any longer, and to be honest, it's been rare I've ever seen the need. It is highly recommended to set the user's primary group as "Domain Users" and leave it as default. This is a zero impact, zero will break activity that will actually help correct your scripting and produce better LDAP results. Keep in mind what the screenshot said "There is no need to change Primary Group unless you have Macintosh clients or POSIX-compliant applications". I'll leave it there.
— Easy link to my blog: http://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.