More from the mailbag….
I just downloaded and tried your memberof utility, but I think I’m missing something.
What I want to do is – in the Windows logon script – determine if the logged on user is in a particular group so I can take a specific action. The easy part has been to figure out this information, but the impossible part has been communicating that result back to the logon script in a way that it can handle.
Anyway, I saw this utility and thought it might have a way to do what I want. So I downloaded it and ran it from the command prompt to check out what it does, and when I typed memberof and hit enter, I got a list which includes my name and all of the groups I belong to. Then I tried memberof –group domainname\groupname to see if, by specifying the group, I could get a simple yea/nay that I’m in it or not. I also tried the same command with a group I’m not in – and got the same results. All I get back in every case is these two lines.
Security Principal: [GROUP] domainname\groupname
Group Memberships:
Of course, where is say “domainname” and “groupname” I specified the actual ones. Also, I know I should be able to do this as a normal user, but I have domain admin rights and this is still what I get.
Am I just mistaken about what the tool does or am I missing some obvious syntax? Any help is appreciated.
My response…
The -group and -computer switches are for if you want to specify looking at the memberof attribute of a specific group or computer, not to check for existence of that group or computer in the user’s memberof attribute.
You could pipe memberof’s output to findstr and then check that way, something like
[Thu 08/07/2008 9:33:29.70]
G:\new1\Dev\CPP\MemberOf>memberofMemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006
Security Principal: [USER] TEST\$joe
Group Memberships:
[Local Security] [Administrators] CN=Administrators,CN=Builtin,DC=test,DC=loc
[Local Security] [DnsAdmins] CN=DnsAdmins,CN=Users,DC=test,DC=loc
[Global Security] [Domain Admins] CN=Domain Admins,CN=Users,DC=test,DC=loc
[Global Security] [Domain Users] CN=Domain Users,CN=Users,DC=test,DC=loc
[Universal Security] [Enterprise Admins] CN=Enterprise Admins,CN=Users,DC=test,DC=loc
[Universal Security] [Schema Admins] CN=Schema Admins,CN=Users,DC=test,DC=loc
[Local Security] [Users] CN=Users,CN=Builtin,DC=test,DC=loc[Thu 08/07/2008 9:34:21.31]
G:\new1\Dev\CPP\MemberOf>memberof |findstr /i “CN=Users,CN=Builtin,DC=test,DC=loc”MemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006
[Local Security] [Users] CN=Users,CN=Builtin,DC=test,DC=loc
[Thu 08/07/2008 9:34:30.29]
G:\new1\Dev\CPP\MemberOf>echo %errorlevel%
0[Thu 08/07/2008 9:34:33.12]
G:\new1\Dev\CPP\MemberOf>memberof |findstr /i “CN=Users2,CN=Builtin,DC=test,DC=loc”MemberOf V02.03.00cpp Joe Richards (joe@joeware.net) June 2006
[Thu 08/07/2008 9:34:38.90]
G:\new1\Dev\CPP\MemberOf>echo %errorlevel%
1joe
Joe,
I wanted to thank you for this great tool. It has saved me a lot of time and grief. Recently, I was troubleshooting a problem with a 3rd-party NAS device that was balking (or even crashing) when users with high group membership (over ~250 security groups) were accessing its shares. Wanting to enumerate my user objects and their nested groups, I headed off to do a one-liner with DSFIND and DSGET–DSFIND the samid of my users, pipe it to DSGET to obtain the memberOf backlink, count the results and summarize by the groupType attribute to ensure I was only counting Security groups and not distribution groups. What could be easier?
Except that DSGET has some anomalies when working with inetOrgPerson objects. Like it can’t return results when querying for “memberOf.”
I opened a call through our Premier agreement, and was met with this fine response:
Hello Aaron,
The problem you are seeing with DSGET is a known issue. The issue was not fixed because the functionality of the tools was replaced with PowerShell. I have verified that you can query the “memberof” property of an inetorgperson, and it returns the groups, using PowerShell.
Command:
$User = [ADSI]”LDAP://CN=user1,OU=UsersOU,DC=Contoso,DC=Com”
$User.Get(“memberof”)
Result:
“CN=Group1,OU=Group,DC=Contoso,DC=Com”
“CN=Group2,OU=Group,DC=Contoso,DC=Com”
“CN=Group3,OU=Group,DC=Contoso,DC=Com”
“CN=Group4,OU=Group,DC=Contoso,DC=Com”
Now, this is one specific way of doing this from a PowerShell command window. I am in no way an expert, and there are examples of scripts to run that would automate this a little more. One being, instead of loading one user into the $user expression, you could load a text file with multiple entries. For example:
Text file contains(users.txt):
CN=user1,OU=UsersOU,DC=Contoso,DC=Com
CN=user2,OU=UsersOU,DC=Contoso,DC=Com
CN=user3,OU=UsersOU,DC=Contoso,DC=Com
CN=user4,OU=UsersOU,DC=Contoso,DC=Com
Command to load file:
$users = get-content c:\users.txt
You would then run the following command to loop through the newly loaded data:
$users | foreach {$_; $DN = [ADSI]”LDAP://$_; $DN.Get(“memberof”)}
Result:
CN=user1,OU=UsersOU,DC=Contoso,DC=Com
CN=Group1,OU=Group,DC=Contoso,DC=Com
CN=Group2,OU=Group,DC=Contoso,DC=Com
CN=Group3,OU=Group,DC=Contoso,DC=Com
CN=Group4,OU=Group,DC=Contoso,DC=Com
Hopefully this is not too confusing. I agree, it is not the quickest way to grab the information. However it is a special case because of the inetorgperson object. Because of the issue with DSGet and the inetorgperson query, it should have taken a few minutes, but since that functionality was brought into PowerShell it introduces a steep learning curve on a seemingly easy task.
I don’t believe it get the nested groups, I will have to test that.
No, not confusing at all. Much easier to use DSGET to dump my users full DN and then spend a while trying to figure out how to write a PS script to loop through my users and then loop through those groups to find their nested groups.
Thanks for helping my admin life not totally suck.