More than six years ago, I wrote a post, detailing how I could identify users’ Active Directory group memberships. While the method I detailed certainly works, it isn’t as simple as it might have been. Having recently found myself needing to perform that very same task again, I decided to revisit this topic, to show how I did it this time around.
Last week, I showed you how you can easily find the OU to use when looking for the members of a specific OU. Today, I’d like to show you how I use that information. The background was that we use AD groups to control access to network shares. In order for IT support to know who is authorized to approve requests for access to these shares, we use the Managed By tab, assigning the owner of the network share as manager:
Using PowerShell, I was building a script to identify a subset of the groups in a given organizational unit (OU). As you may know, these are built up of subsections with the prefixes CN (common name) and DC (Domain Component). In order to have the script run successfully, you need to specify the OU using the full path, which looks something like this:
Sometimes, you need a list of all groups whose name contain a specific string, whether that is in the beginning, middle, or end of the group name. As we’ve seen previously, looking up groups in PowerShell is done with the Get-ADGroup command. Adding the -filter parameter allows us to find groups that satisfy our needs. Using asterisks as wildcards, we can specify whether the string should be at the start, middle, or end:
From time to time, I get tickets where one of many possible root causes may be a full disk. While accessing this information over RDP is often an option, it is rather more intrusive than needed. What’s more, I usually don’t have access to access file servers over RDP. Enter PowerShell and the
In a recently closed ticket, I had specified that the solution would be automatically applied upon reboot of a computer. As so often happens one of the twenty or so users affected by the solution emailed to say that it didn’t work. Having dealt with said user before, I had a hunch that they hadn’t actually read the solution text, and wanted to see if I could find out when the computer had last been rebooted.
Last week, I showed you how to get specific properties for all users in a given OU. Knowing that the output of that query quickly gets hard to navigate, wanting to remove the extraneous data that the customer didn’t request, and assuming that they wanted to manipulate the data, I decided to return the results as a CSV-file.
Two weeks ago, I showed you how I got some specific properties for a specific user. Perhaps unsurprisingly, the next request from my customer was a similar dump from a specific OU. While the Identity parameter works well when you’re dealing with a specific user, it doesn’t help when you want all users.
I was asked to provide an overview of all available properties in an Active Directory user object for an upcoming project. As it turns out, that is very easily accomplished. Unsurprisingly, PowerShell has an applet for this. We use the
Get-ADUser applet, with the parameters
Identity to identify the user in question and
Properties with a wildcard to return all properties.
Last week, I showed you how I find all the nested members of a specified group. When we get requests for such audits, however, they usually specify doing so for a number of groups. Now, we could of course do it, one group at a time, adding information to our output as we go, however the script as written overwrites the file. What, then, if we want to run this on a number of groups, and avoid overwriting the file? That requires the -Append parameter: