Use PowerShell to Find Locked-Out User Accounts

Dr Scripto

August 31st, 2011

Summary: Use a one-line Windows PowerShell command to find and unlock user accounts.

Hey, Scripting Guy! I am trying to find users who are locked out. For example, I have a number of users who log on only occasionally. They constantly lock themselves out. I have seen some VBScripts to search for locked out user accounts, and even a Windows PowerShell script to accomplish the same thing, but I am wondering if there is an easier way to accomplish this task. Help, please!

—CJ

Hello CJ,

Microsoft Scripting Guy Ed Wilson here. One problem with going on vacation is that the vacation eventually ends. I keep thinking that if we could sell our house in Charlotte, North Carolina, I might like to move to Hawaii to live. Right now, though, very few houses are actually selling in Charlotte, so there is little hope of making that move. One cool thing about living in Hawaii is that it is a couple of hours later than Redmond, Washington (Redmond is -8 GMT and Hawaii is -10 GMT). (This means that the next time someone schedules a meeting for 4:00 P.M. on a Friday, it would be 2:00 P.M. for me instead of the normal 7:00 P.M. meetings I get these days.)

CJ, I know exactly your predicament. You have users hiding in Active Directory Domain Services (AD DS) who are only occasional users. AD DS is essentially a database, and the old adage certainly applies: garbage in, garbage out. If a user cannot remember their password, the usefulness of network security diminishes rapidly. In addition, with the integration of directory services with messaging platforms, forgotten passwords can cause problems. However, when one has hundreds or thousands—or even hundreds of thousands of users—in Active Directory, finding a locked-out user can be as big of a challenge as finding the frogfish in the picture I took during my last scuba diving trip to Kauai.

Note This is the third in a series of three posts about working with the ActiveDirectory module. In the first post, I discussed the RSAT tools and the Get-ADUser cmdlet. In the second post, I talked about installing the Active Directory management web service. For additional Active Directory and Windows PowerShell posts, refer to this collection on the Hey, Scripting Guy! Blog.

When using the Microsoft Active Directory cmdlets, locating locked-out users is a snap. In fact, the Search-ADAccount cmdlet even has a lockedout switch.

The first thing to do is to import the ActiveDirectory module by using the Import-Module cmdlet. This command is shown here:

Import-Module activedirectory

Once the module is imported, use the Search-ADAccount cmdlet with the lockedout parameter. This command is shown here:

Search-ADAccount –LockedOut

Note Many network administrators who spend the majority of their time working with AD DS import the ActiveDirectory module via their Windows PowerShell profile. In this way, they never need to worry about first importing the module. I have an entire series of posts about working with profiles that discusses how to create a profile, and what sort of things to add to it.

The Search-ADAccount command and the associated output are shown in the following figure.

I can unlock the locked-out user account as well, assuming I have permission. In the following figure, I attempt to unlock the user account with an account that is a normal user. And an error arises.

Note People are often worried about Windows PowerShell from a security perspective. Windows PowerShell is only an application, and a user is not able to do anything that they do not have rights or permission to accomplish. This is a case in point.

Because the myuser account does not have administrator rights, I need to start Windows PowerShell with an account that has the ability to unlock a user account. To do this, I right-click the Windows PowerShell icon while pressing Shift. This allows me to click Run as different user in the shortcut menu. This produces the dialog box shown in the following figure.

After I start Windows PowerShell again with an account that has rights to unlock users, I need to import the ActiveDirectory module once again. I then check to ensure that I can still locate the locked-out user accounts. After I have proven to myself I can do that, I pipe the results of the Search-ADAccount cmdlet to Unlock-ADAccount. A quick check ensures I have unlocked all the locked-out accounts. The series of commands is shown here:

import-module ActiveDirectory

Search-ADAccount –LockedOut

Search-ADAccount -LockedOut | Unlock-ADAccount

Search-ADAccount –LockedOut

The commands and associated output are shown in the following figure.

Note Keep in mind that the command Search-ADAccount -LockedOut | Unlock-ADAccount will unlock every account that you have permission to unlock. In most cases, you will want to investigate before unlocking all locked-out accounts. If you do not want to unlock all locked-out accounts, use the confirm switch to be prompted before unlocking an account.

If I do not want to unlock all users, I user the confirm parameter from the Unlock-ADAccount cmdlet. As an example, I first check to see which users are locked out by using the Search-ADAccount cmdlet, but I do not want to see everything, only their names. Next, I pipe the locked-out users to the Unlock-ADAccount cmdlet with the confirm parameter. I am then prompted for each of the three locked-out users. I choose to unlock the first and third users, but not the second user. I then use the Search-ADAccount cmdlet one last time to ensure that the second user is still locked out. The following figure illustrates this technique.

CJ, that is all there is to finding and unlocking users in Active Directory by using the Microsoft ActiveDirectory module. I invite you back tomorrow when I will make a historic announcement. It is good, so check back. You will be glad you did.

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