Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell and WMI associations to find user group membership. Microsoft Scripting Guy, Ed Wilson, is here. Today is sort of a mellow day. I just finished reading a mystery story called Some Like it Hawk by Donna Andrews. Donna is really a nice person, and her book is downright funny. Anyway, when I finish reading a book, I am always a little mellow … it is like I want more, but also am not quite ready to go to my unread book pile, and grab another one—just yet. So instead, I grab my laptop and begin playing around with Windows PowerShell. In some ways, Windows PowerShell is sort of like a good mystery story—I basically know how it will turn out, but I am not always certain how complicated things will get. At least with Windows PowerShell, I always know “whodunit.”

Using a WMI association class to find group memberships

Yesterday, I talked about using a WMI association class to find members of the local administrators group. Today, I will reverse that process and find group memberships for a specific user. One of the key things to remember about WMI association classes is that they work two ways—that is, they link (or associate) one WMI class with another WMI class. In this way, you can always use one member of that association to find the other members of the association. The workflow, might be something like this … I am exploring members of the local administrators group on a specific computer. I can use the code from yesterday to do this. (In fact, the code will work on a local computer or remotely across the network assuming you have proper rights to do so). I discover a user in the local administrators group that I do not believe should be there. I decide to investigate and see what other groups the user may be a member of. So, using Windows PowerShell 2.0, I can do the following:

Get-WmiObject win32_groupuser |

Where-Object { $_.partcomponent -match ‘name=”ed”‘} |

Foreach-Object {[wmi]$_.groupcomponent}

(Keep in mind, the code can be shortened quite a bit by using aliases.)

When I run the code, the following is shown in the Windows PowerShell console.

16:28 C:> gwmi win32_groupuser |

>> Where-Object { $_.partcomponent -match ‘name=”ed”‘} |

>> Foreach-Object {[wmi]$_.groupcomponent}

>> 

Caption               Domain               Name                 SID

——-               ——               —-                 —

EDLTAdministrators   EDLT                 Administrators       S-1-5-32-544

IAMMREDDomain Admins IAMMRED              Domain Admins        S-1-5-21-14579568…

IAMMREDDomain Users  IAMMRED              Domain Users         S-1-5-21-14579568… If I have access to Windows PowerShell 3.0, I can use the new CIM cmdlets to perform this query. I first need to use the Get-CImInstance cmdlet to retrieve a specific CIM Instance of the Win32_UserAccount WMI class. I use the –filter parameter to limit the returned object to a specific user. I pipe this CIM instance to the Get-CimAssociatedInstance cmdlet and then specify the association of the Win32_GroupUser. The command is shown here.

Get-CimInstance -Filter “name = ‘ed'” -ClassName win32_useraccount |

Get-CimAssociatedInstance -Association win32_groupuser The command and its output is shown here.

16:31 C:> Get-CimInstance -Filter “name = ‘ed'” -ClassName win32_useraccount |

>> Get-CimAssociatedInstance -Association win32_groupuser

>> 

SID                    Name             Caption                Domain

—                    —-             ——-                ——

S-1-5-32-544           Administrators   EDLTAdministrators    EDLT

S-1-5-21-1457956834… Domain Admins    IAMMREDDomain Admins  IAMMRED

S-1-5-21-1457956834… Domain Users     IAMMREDDomain Users   IAMMRED Well, that is about it for today. Join me tomorrow as I begin a new week on the Hey, Scripting Guy! Blog. It will be cool … I promise. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy