Group membership isn't consistent in AD Users and Computers
This was the case of another interesting troubleshoot I ran across where users weren't enumerating properly in a PowerShell script.
Problem statement: An admin was working on a project known as the "Active Directory Group Cleanup", in which they needed to find and remove members from groups. So, he created a PowerShell script using Get-ADGroupMember. The script yielded 6 entries, although there were actually 15. This was not an issue with PowerShell, as it was doing its job. The root cause was discovered by going to the Members tab of the group showed 15 entries. Going into Attribute Editor (same as ADSI Edit), I saw under the member attribute, 6 entries. This was actually hindering his project.
For a fix, I have created a "Part 2" of sorts. Please refer to PS without BS: Fixing the user primary group for more information.
Some people probably going to be lost without visualizing 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
Reproducing the issue
The root cause of this issue is in changing the Primary Group for a user to something other than "Domain Users". 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 (the default)
An example screenshot for Susan showing group memberships and towards the bottom, the Primary Group changed:
And when we go into Test Group A, I can see the expected result of all 3 users: Ruth, Sandra, and Susan.
Going to the Attribute Editor to look at the member's attribute, I only see 2 of the users: Ruth and Sandra.
Sorting it out
Keep in mind that the following applies:
- Susan's Primary Group is now Test Group A
- Sandra's Primary Group is now Test Group B.
- When looking at Test Group A, a user who's Primary Group is in Group A (Susan) will not be shown, but the user in Group B (Sandra) will.
- Any user who's Primary Group is the default "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 its purpose in the much older NT days, like NT4, but today changing the setting doesn't do anything unless you are using old 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...
Import-Module ActiveDirectory
$RootDomain="test.local"
$OutputFile="c:\temp\adusers_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 property changed from the default of "Domain Users", and to be honest, it's been rare I've ever seen the need. If you have users configured like this, it's a good idea to set their Primary Group back to the default of "Domain Users". Unless you have some REALLY old systems running in your environment (for those of you actually alive and in IT in the Windows NT days), this change will be zero impact, zero break activity that will actually help produce better LDAP query results for your groups. 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: https://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.
Comments
- Anonymous
February 05, 2018
So what is the root cause? I see the difference in what the Attribute Editor reports and what AD reports but at no time does it appear that needs to be updated so Get-ADGroupMember reports correctly. Maybe Get-ADGroupMember needs to account for this? I've setup user accounts that have a very specific purpose and I don't want in the Domain Users group because there is no benefit and all downside to such a setup. As you mention in the next blog post, the Domain Users group is a privileged group and so not all users might not be in the group. The exclusion of users without Domain Users group as primary from Get-ADGroupMember might be a good way to evade detection. :-) Overall though, still a good blog post.- Anonymous
February 05, 2018
Don,My apologies, the comment was marked as spam and didn't see it right away. The root cause is a known issue with Primary Groups being something other than Domain Users, but you bring up a great point actually. If you wanted to avoid detection from PowerShell queries, that could be a way to do this. I may need to ruffle some feathers on the inside about this. :)Thanks again, good comment.
- Anonymous