Shore Up
A padlock on an office door swinging open as a key turns, a relieved worker waiting on the other side.
WindowsSecurity

Unlock a Locked-Out Active Directory Account with PowerShell

Ketan Aagja7 min read
No ratings yet

Before you run this

This guide uses the Unlock-ADAccount cmdlet to clear the locked-out state on an Active Directory user account — the state a user lands in after too many bad password attempts trip your domain lockout policy. Unlocking lets them log in again immediately; it does not change or reset their password.

Privileges: You need a domain account with delegated rights to unlock accounts (typically an account operator, a helpdesk role you've delegated, or a domain admin). Run PowerShell from a machine that has the ActiveDirectory module available — that means RSAT installed on a Windows client, or running directly on a domain controller. You do not need local Administrator on the box to unlock an account, but you do need the directory permission. Open a normal PowerShell session as your admin user; if the module isn't loaded, importing it (below) pulls it in.

Test first: Read each command before you run it. Unlocking is low-risk, but the filtered bulk version at the end acts on every locked account in the domain at once — run that against a test OU or a single test user before you turn it loose. If you have a lab domain or a throwaway test user, prove the workflow there first.

What it changes, and what it doesn't: Unlock-ADAccount clears the lockout flag. That is not a destructive operation — there is no matching "re-lock this user" cmdlet, and you wouldn't want one. If an account is locking repeatedly, unlocking treats the symptom, not the cause (a stale cached credential on a phone, a mapped drive with an old password, a scheduled task running as that user). Unlock to get the person working, then find the source. Do not reset the password unless the user actually forgot it — a needless reset creates its own lockout storm across their devices.

Assumptions

I'm assuming:

  • A domain-joined Windows machine (client with RSAT, or a domain controller) running Windows PowerShell 5.1.
  • The ActiveDirectory module is installed and you can reach a writable domain controller.
  • Your account can unlock users in the target OU.

Replace every example.com, jdoe, and OU=Staff,DC=example,DC=com below with your real values.

Load the module

# Pulls in Get-ADUser, Unlock-ADAccount, Search-ADAccount, etc.
Import-Module ActiveDirectory

If this errors with "module not found," RSAT isn't installed on this machine. On Windows 10/11 that's an optional feature (RSAT: Active Directory Domain Services tools); on Windows Server it's a feature you add. Install it, then re-run the import.

Step 1 — Confirm the account is actually locked

Before you unlock anything, check the state. A user who "can't log in" isn't always locked — they may have a wrong password, a disabled account, or an expired one. Look at the real flags:

# Replace jdoe with the user's samAccountName
Get-ADUser -Identity "jdoe" -Properties LockedOut,LockoutTime,Enabled,badPwdCount |
    Format-List Name,SamAccountName,Enabled,LockedOut,LockoutTime,badPwdCount
  • LockedOut : True — the account is locked; proceed.
  • LockedOut : False — the problem is something else; unlocking won't help.
  • Enabled : False — the account is disabled, which is a different fix.

LockoutTime shows when it locked. badPwdCount is the DC-local count of recent bad attempts and is a useful hint that something is repeatedly guessing wrong.

If you don't know the samAccountName, find it by name:

Get-ADUser -Filter "Name -like '*Doe*'" -Properties LockedOut |
    Select-Object Name,SamAccountName,LockedOut

Step 2 — Unlock the account

Once you've confirmed it's locked:

Unlock-ADAccount -Identity "jdoe"

Unlock-ADAccount doesn't print anything on success — no news is good news. It supports -WhatIf if you want to see what it would do without doing it, and -Confirm to prompt first:

Unlock-ADAccount -Identity "jdoe" -WhatIf     # shows the action, changes nothing
Unlock-ADAccount -Identity "jdoe" -Confirm    # asks Y/N before unlocking

You can also pass a full distinguished name to -Identity if you have naming collisions:

Unlock-ADAccount -Identity "CN=John Doe,OU=Staff,DC=example,DC=com"

Step 3 — Verify

Re-run the same read from Step 1 and confirm LockedOut is now False:

Get-ADUser -Identity "jdoe" -Properties LockedOut,LockoutTime |
    Format-List Name,SamAccountName,LockedOut,LockoutTime

LockedOut : False means the user can log in again. Have them try. If it locks again within minutes, you're not done — see the closing note.

Finding every locked account

Search-ADAccount is the standard cmdlet for this. To list all currently locked users in the domain:

Search-ADAccount -LockedOut -UsersOnly |
    Select-Object Name,SamAccountName,LockedOut,LastLogonDate

-UsersOnly keeps computer accounts out of the results. This is read-only — run it freely.

Unlocking in bulk — carefully

If you genuinely need to clear several locked accounts at once, scope it and dry-run it first. Start by scoping to a single OU so you're not sweeping the whole domain:

# 1) SEE what you'd act on — no changes yet
Search-ADAccount -LockedOut -UsersOnly -SearchBase "OU=Staff,DC=example,DC=com" |
    Select-Object Name,SamAccountName

# 2) Dry run the unlock with -WhatIf — still no changes
Search-ADAccount -LockedOut -UsersOnly -SearchBase "OU=Staff,DC=example,DC=com" |
    Unlock-ADAccount -WhatIf

# 3) When the -WhatIf output looks right, drop -WhatIf to do it for real
Search-ADAccount -LockedOut -UsersOnly -SearchBase "OU=Staff,DC=example,DC=com" |
    Unlock-ADAccount

Run steps 1 and 2 first, every time. The -WhatIf output lists exactly which accounts the last command will touch. If that list contains something you didn't expect, stop and narrow the -SearchBase.

On "undo"

There is no rollback for an unlock, and you don't need one — unlocking simply removes a temporary restriction. If an account should stay unavailable, that's a disable, not a lock, and it's a separate deliberate action (Disable-ADAccount). Don't reach for that to "reverse" an unlock; they solve different problems.

Why it locked, and where to look

Unlocking gets the user working; it doesn't stop a repeat. The usual culprits are a saved credential somewhere the user forgot about — a phone's mail profile, a Wi‑Fi or VPN saved password, a mapped drive, an RDP session, or a scheduled task or service running as that account after a password change.

The authoritative place to see which machine generated the bad attempts is the Security event log on the PDC-emulator domain controller — look for account lockout events (Event ID 4740) and the failed logon events (4625), which record the source workstation or IP. That's where you chase the root cause. For the exact cmdlet syntax and parameters used here, see Microsoft Learn for Unlock-ADAccount and Search-ADAccount.

That's the whole job: confirm it's locked, unlock it, verify LockedOut is False, and — if it keeps happening — go read the DC's Security log instead of unlocking it a fourth time.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.