A Great Free Tool for Finding Disabled and Inactive Active Directory User Accounts
I’ve written several different articles demonstrating a variety of techniques for discovering disabled and inactive Active Directory user accounts with PowerShell. But for the sake of thoroughness, there is one final option. Although the Microsoft Active Directory cmdlets are easy to acquire and use, they do require a more updated infrastructure. Unfortunately, not everyone has access to the latest and greatest tools. If you are running an older version of PowerShell or have older domain controllers, and you don’t want to have to struggle with scripting .NET classes, then you have another option.
Quest Software, now part of Dell, has long offered their set of Active Directory PowerShell cmdlets for free. These cmdlets are designed to support their commercial product, ActiveRoles Server, but can be used even if you are not running that product. The most current version of the PowerShell cmdlets is only available to licensed users of that product. But, you can download the previous version for free, and it should handle most of your needs. Visit Dell’s website to get a copy of the download, and click on the link to download the freeware version of the ActiveRoles Management Shell.
You will need to have a Dell account to download the file. The most current version I could find was 1.60. Download either the 32 or 64 bit version. Extract the files and run the setup on your client. If necessary, reboot.
Open a PowerShell prompt. It doesn’t even have to be an elevated session, but you must be running with a credential that can read and potentially modify Active Directory. There is one major distinction between Microsoft and Quest cmdlets. The former take a web service approach, and the latter follow the traditional LDAP approach. That means that the Quest cmdlets are designed to contact domain controllers over traditional LDAP ports, which means your domain controllers are not in the cloud. On the plus side, you don’t have to install anything on the domain controllers. They don’t even need PowerShell.
What is “Inside Microsoft Teams”?
“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.
Another major difference is that the Quest cmdlets are packaged as a snap-in. You have to install them on any computer you intend to run them. This also means that PowerShell won’t automatically load the snap-in when you attempt to use a Quest cmdlet. To verify the install, get a list of installed snap-ins.
You need to add the snap-in to your session before you can use any commands,. You can specify the name or use a wild card.
Use Get-PSSnapin to see all loaded snap-ins. And what do we get for our troubles? Quite a bit. These cmdlets have full help and examples. Some of them are designed for use with ActiveRoles Server, which you can ignore. You'll also note that all of their cmdlets have a noun prefix of QAD, so that you can identify them as Quest cmdlets. This helps avoid naming collisions. Right. Let's get to work. If you look at help for Get-QADUser, then you'll most likely see some easy-to-use parameters.
The cmdlet searches the entire domain by default. We can easily limit the search scope.
Another difference with these cmdlets compared to the Microsoft equivalent is that you get the full user object back, which makes it easier to retrieve user information.
I'm displaying the results with Out-Gridview, but as I've shown you in earlier articles you could just as easily export to a CSV file. Before I get too far, let me point out that by default the Quest cmdlets will only return the first 1000 objects. To retrieve everything set the value of the –SizeLimit parameter to 0. I apparently have exactly 6,200 user accounts in my domain. Back to the task at hand, what about inactive accounts? Get-QADuser has parameters related to inactivity. You can manually specify a condition based on a number of days using -InactiveFor. The cmdlet will check any of these condition using the value for -InactiveFor:
- The account remains in the expired state for at least the number of days.
- The account does not have its password changed for at least the number of days.
- The account has not been used to log on for at least the number of days.
Even better, Get-QADUser has parameters –ExpiredFor, -NotLoggedOnFor, and –PasswordNotChangedFor that let you get more granular. Specify the number of days for one of these parameters to find matching user accounts. The Quest cmdlets can also use a policy to define what is inactive. Use the –Inactive parameter to apply this policy.
The policy is simple enough to modify to meet your requirements:
The Quest cmdlets are very easy to use and most everything you would want to accomplish is parameterized. It is very important that you read complete help and examples. Best of all, the cmdlets are free and should work with just about any version of PowerShell or Windows.