3 Best PowerShell Cmdlets for AD User Management

When it comes to managing Microsoft's Active Directory, PowerShell can be one of the most powerful tools when it comes to quickly gathering information — especially in bulk. In order to take advantage, it takes some familiarity with how to use some fundamental PowerShell cmdlets that are used to manage AD.  If you need a refresher on Power Shell's purpose, you'll find it in our Advanced Windows Server training.

Active Directory Users and Computers (ADUC) is a great window into all the layers of information when it comes to user objects and properties. But it comes at a clicking cost! Lots of searching, clicking through tabs, and scrolling can get very tedious when working inside of ADUC daily. Here are a few fundamental cmdlets that will allow anyone to manage AD much more efficiently.

Setting Up PowerShell to Manage Active Directory

Out of the box, PowerShell doesn't really know how to communicate with Active Directory. The Active Directory module for PowerShell needs to be installed. There are an ever-growing number of ways to accomplish this. Unfortunately, it's starting to look like the Wild West with getting this installed. Different Windows Server versions, Windows 10 versions, and PowerShell Core versions all seem to have varying ways to get this module installed to use. For the sake of this post, it will be assumed that this is being installed on Windows 10 build 1809 and above.

The tool that is needed is a part of the trusty Remote Server Administration Tools (RSAT) that most are very familiar with when it comes to managing a Windows environment. On Windows 10 1809 and newer builds the RSAT became a part of Features on Demand (FoD). You can install AD RSAT Tools from the Settings menu:

Settings > Apps > Optional Features > Add features > RSAT: Active Directory Domain Services and Lightweight Directory Tools > Install

This can also be installed with a command inside of PowerShell:

Add-WindowsCapability –online –Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"

Once this is completed, the cmdlets that are a part of the module become available to any new PowerShell sessions. Feel free to have PowerShell list all the new cmdlets that are now available:

Get-Command -Module ActiveDirectory

It should also be noted that the machine in which these commands will be used should be member of the Windows domain that is to be managed.

Starting Out With Get-ADUser

Get-ADUser will quickly become a staple when it comes to querying user objects in AD. To start using Get-ADUser, it will need something to look up. To look up a specific user object, use the -Identity parameter. A user object can be identified by its distinguished name (DN), GUID, security identifier (SID), Security Account Manager (SAM) account name, or name:

Get-ADUser -Identity luke.skywalker

The simple query will return a default set of properties and values that are as follows:

DistinguishedName

Enabled

GivenName

Name

ObjectClass

ObjectGUID

SamAccountName

SID

Surname

UserPrincipalName

To view the comprehensive list of all the properties and values of the user object, simply use:

Get-ADUser -Identity luke.skywalker -Properties *

Adding the parameter -Properties * tells the console to spit out everything about the object. This is helpful because it allows you to see all the information and properties that are stored for each user object. This will help in the future when it comes to filtering for specific users based on properties within their user accounts.

To query more than one user with Get-ADUser, use the -Filter parameter. The Filter parameter uses the PowerShell Expression Language to write query strings for Active Directory. For instance, to look up the all the users in a specific Organizational Unit (OU):

Get-ADUser -Filter * -SearchBase “OU=Accounting,OU=Users,DC=deathstar,DC=net"

This command will grab all (-Filter *) the user objects from a specific OU using the -SearchBase parameter to pass the specific OU to query. The pipeline would be useful here along with Select-Object to display just the properties that are needed from all the objects. Without this, the console will return either the default properties for all the objects that were found. For example, to display just the SamAccountName, DistinguishedName, and the Enabled flag for all the gathered users:

Get-ADUser -Filter * -SearchBase “OU=Accounting,OU=Users,DC=deathstar,DC=net" | Select-Object SamAccountName,DistinguishedName,Enabled

These few iterations of Get-ADUser will certainly provide plenty of options on gathering user object information within Active Directory. As stated before, this can easily morph into making bulk changes after knowing exactly what information to look for.

Making Changes With Set-ADUser

Almost anything that can be gathered by using Get-ADUser can be modified with the cmdlet, Set-ADUser. That is why the bulk of this post is focused on Get-ADUser, because it is the key to viewing the properties that are changeable. Once the property in question is found, it is then just a matter of using Set-ADUser to make the necessary modification. Bulk changes are a goal for most when it comes to managing Active Directory, but as with anything, test all these in a test environment.

If a test environment is not available, work with a team of peers to come up with a next-best scenario. This could be a subset of test user objects that reside inside a test OU. If anyone has been managing Active Directory long enough, they likely have a few stories to share about some extensive changes that ended up really ruining their day. It's best to know exactly what to expect when running automated bulk actions using Set-ADUser. Here are just a few examples of using Set-ADUser.

The most important parameter when using Set-ADUser is -Identity. PowerShell needs to know exactly what object or objects to make changes on. Remember, user objects can be identified by distinguished name, GUID, security identifier, Security Account Manager account name, or name. There are a few popular ways to look at using Set-ADUser. Using it directly using the -Identity parameter and making direct changes or utilizing Get-ADUser and using the pipeline to pass the object to Set-ADUser. Here is an example of using these two ways to change the Title field of Luke Skywalker after completing his training with Master Yoda:

Set-ADUser -Identity luke.skywalker -Title ‘Jedi Master’

Get-ADUSer -Identity luke.skywalker | Set-ADUser -Title ‘Jedi Master’

As you can see in these examples, the logic is just a tad different. In the first line, the change is being made directly to the user object, plain and simple. The second line shows that the object is retrieved using Get-ADUser and then that object is passed through the pipeline to Set-ADUser to make the change. Notice that Set-ADUser is without the -Identity parameter. That is because the object has already been found with Get-ADUser and PowerShell knows to make the change to the object in the pipeline.

Seasoned Active Directory administrators who use PowerShell extensively, will likely be all over the map in terms of which they think is best to use. It typically comes down to error-handling, logging, and preference as to which logic they use. The logic may also differ based on the types of changes being made as well. It's good to understand the logic and what may be most efficient when making mass-changes. Making a single ad-hoc change will almost never show a difference, but logic becomes critical in terms of efficiency when managing thousands of accounts.

It should be noted that by default, Set-ADUser does not have any output when the command completes successfully. There is no warm and fuzzy, "Hey that worked!" output in the console when Set-ADUser is used. Feel free to use the -Verbose switch to get some of the detailed information about what the cmdlet is doing. It's also why having a good grasp of Get-ADUser is even more important, as it can be used to validate any changes made by Set-ADUser.

Another quick application of Set-ADUser is in enabling and disabling user accounts. It is always a best practice to disable any unused accounts in the domain. This is not only good for organization, but also for security purposes. Many of the recent security breaches that are featured in the news are typically stale, unused accounts that are used to access systems and data that end up costing companies lots of money to investigate and remediate.

To disable and user object, simply use the following:

Set-AdUser -Identity trooper.fn2187 -Enabled $False

To validate the result, simply use Get-ADUser along with the pipeline to display just enough information to check the results:

Get-ADUser -Identity trooper.fn2187 | Select-Object Name,SamAccountName,Enabled

The output would then display a True/False value for the Enabled property to validate the change made by Set-ADUser.

Final Thoughts

When it comes to managing Active Directory using PowerShell, it is very clear how fundamental these two cmdlets are and how dependent they are on one another. The efficiency of how PowerShell is designed really allows AD administrators to catch on quickly when it comes to querying user objects and their respective properties. Get-ADUser becomes exponentially more powerful when used with specific filtering to gather just the objects needed to make mass changes. Set-ADUser can be an incredible ally or nasty enemy, depending on how carefully it is used, especially when making bulk changes.

Testing is key using various scenarios to ensure that the expected outcome is what is produced. Investing the time to get more familiar with these cmdlets will certainly produce quick returns in terms of time savings, even with using them against single objects.