PowerShell Problem Solver: Get Local Active Directory Group Members with PowerShell

Posted on February 11, 2015 by Jeff Hicks in PowerShell with 0 Comments

In some recent articles we have looked at retrieving members of an Active Directory group with PowerShell, with an eye toward exporting to a CSV file. Of course, our servers and desktops also have groups, and it might be useful to know what users and groups are in those local groups. The local administrator’s group comes immediately to mind, but you can query any local group using the techniques I’m going to show you.

I’m going to assume that you are running in a domain environment with credentials that have administrator rights on any servers you plan to query. Most of what I am going to show you doesn’t support alternate credentials. Although, you can probably take many of my examples, wrap them in a file or script block, and execute with Invoke-Command where you can specify an alternate credential as last resort.

I am going to run all of my commands from a Windows 8.1 desktop running PowerShell under a domain administrator credential. I am going to get the members of the Administrators group on CHI-Core01.

Administrators Properties in Windows 8.1. (Image Credit: Jeff Hicks)

Administrators Properties in Windows 8.1. (Image Credit: Jeff Hicks)

 

As you can see the group has a mix of local and domain users and groups. I’ll define some variables to use with my examples.

If you were developing a script or function, these could become parameters eventually.

Using ADSI

The first option takes us back to the days of VBScript and ADSI.

We can accomplish the same things in PowerShell using the ADSI type accelerator. Unfortunately, we still have to work with COM objects. There is nothing intuitive or easy about this approach, although it works once you figure it out. The following is technically a one-line command:

Note that the WinNT moniker is case-sensitive. The result is a collection of strings.

Using the ADSI accelerator in Windows PowerShell. (Image Credit: Jeff Hicks)

Using the ADSI accelerator in Windows PowerShell. (Image Credit: Jeff Hicks)

 

I am using the ADSPath member to distinguish domain from local accounts. You could use “Name” instead but then you would only get the last part of each member.

Using ADSPath member to distinguish domain from local accounts in Windows PowerShell. (Image Credit: Jeff Hicks)

Using ADSPath member to distinguish domain from local accounts in Windows PowerShell. (Image Credit: Jeff Hicks) 

The [ADSI] type accelerator is a shortcut to creating a System.DirectoryServices.DirectoryEntry object. Unfortunately, I’ve never found a good .NET class for working with local users and groups. This is the best choice. Instead of using ADSI, I can do this:

Sadly, we still have the same COM issues. Using the Foreach method from PowerShell v4, the results will be the same:

Sponsored

Using CIM and WMI

Another approach is to use WMI. You can use either the WMI or CIM cmdlets. First, let’s take a brief sidetrip and list all of the local groups on the server.

When querying a server that is a member of a domain, you need to filter for local accounts. Otherwise, you will list all of the domain based groups.

Using Get-CimInstance in Windows PowerShell. (Image Credit: Jeff Hicks)

Using Get-CimInstance in Windows PowerShell. (Image Credit: Jeff Hicks)

 

But I already know I want to query members of the Administrators group. To do that, I first need the group itself from WMI.

Now, here’s the tricky part. Many objects in WMI are related or have what we refer to as associations. One of the associations for the Win32_Group class is Win32_GroupUser, which represents the members. Retrieving these associations is the job of Get-CimAssociatedInstance.

However, this is where it gets extra tricky. Here’s the result querying the server from my desktop.

Using Get-CimAssociatedInstance in Windows PowerShell. (Image Credit: Jeff Hicks)

Using Get-CimAssociatedInstance in Windows PowerShell. (Image Credit: Jeff Hicks)

 

No domain accounts. Yet look at the result of the same command run at the console on CHI-Core01.

 CHI-Core01 results. (Image Credit: Jeff Hicks)

CHI-Core01 results. (Image Credit: Jeff Hicks)

 

Now I get the domain-based accounts. If you think about it, this makes sense. In my first command, I am making a remote connection to another server. But retrieving the domain members of the associated class appears to require another hop to a domain controller. By default Windows, and thus PowerShell, don’t like that second hop because it can’t be authenticated. This is where setting up CredSSP can help. Or you can employ a workaround.

In order for this to properly work, I need a way to authenticate to the second hop. One way to accomplish this is to use the legacy NET USE command and map a drive using credentials. I’ll need to wrap everything up in a scriptblock that I can execute using Invoke-Command.

I have hard-coded the name of the domain controller that holds the PDC emulator role in my scriptblock. At least in my network, this seems to be the most reliable method. I’ve also hard coded a drive letter to make it easier to remove the temporary drive mapping. I will pass a credential object over the wire so the password is not sent in the clear. On the remote computer, I can pull the plaintext password from the credential and use it with my drive mapping. The rest of the code consists of my CIM commands. To execute, I’ll define the credential to use and invoke the scriptblock.

.

Sponsored

Legacy Tools

The final technique is to take advantage of the legacy NET LOCALGROUP command. Here’s how it works locally.

If all you want is a quick look, this may be all you need. Otherwise, we can use some PowerShell tricks to parse the text output and wrap it up with Invoke-Command to execute remotely.

Using Invoke-Command to execute remotely. (Image Credit: Jeff Hicks)

Using Invoke-Command to execute remotely. (Image Credit: Jeff Hicks)

 

Just a list of strings, but it works.

It sure would be nice if we had a set of reliable cmdlets from Microsoft for working with local users and groups. But until that day, we will have to build own using some of the techniques I’ve shown here.

Sponsored

Tagged with , , ,