How to unlock AD user account using PowerShell

Locked accounts are a tax on the help desk. A user mistypes a password three times, a mapped drive retries with stale credentials, a phone in a drawer syncs mail in the background, and suddenly the ticket queue lights up.

What is an Active Directory (AD) account lockout? When a user exceeds the account lockout threshold set in Group Policy, the domain controller flips the lockoutTime attribute on their object and rejects all further logons until the account lockout duration expires, an admin unlocks the account manually, or the reset account lockout counter window passes. Native AD does not provide a built-in self-service account unlock workflow for end users.

Common causes of AD account unlocks include:

• Mistyped passwords at the Windows logon screen
• Cached credentials on laptops still presenting an old password to the DC
• Service accounts whose password rotated but the service wasn't restarted
• Mobile devices polling Exchange with stale credentials
• Mapped drives reconnecting with a saved password that no longer matches

For teams managing this manually, PowerShell and the AD module offer a clean, scriptable workflow. This guide walks through each, shows a reusable bulk script you can schedule, and covers where automation can take this process further.

Prerequisite: Install the Active Directory module for PowerShell

1. Install the Active Directory PowerShell module

Before any of the cmdlets below will run, the Active Directory Module for PowerShell has to be installed. It ships as part of RSAT (Remote Server Administration Tools).

For Windows 11 and Windows 10 (Version 1809 and later) use the following PowerShell script

• Get-WindowsCapability: Retrieves the installation status of Windows optional features and capabilities on the current image.
• -Name RSAT.ActiveDirectory*: Filters capabilities by name, using a wildcard to match all RSAT Active Directory-related features.
• -Online(in Get-WindowsCapability): Queries the current running Windows image instead of an offline image.
• Add-WindowsCapability: Installs a Windows optional feature or capability to a Windows image.
• -Online(in Add-WindowsCapability): Installs the capability to the current running Windows image.

For Windows 10 (Version 1803 and earlier), Windows 8.1, and Windows 7, perform the following steps

1. Download and install RSAT manually from the Microsoft Download Center.
2. After installation, enable the Active Directory Domain Services and Lightweight Directory Services Tools feature via: Control Panel > Programs > Turn Windows features on or off > Remote Server Administration Tools.

For Windows Server 2012 R2 and later (including 2016, 2019, 2022, 2025), use the following PowerShell script

• Install-WindowsFeature: Installs one or more Windows Server roles, role services, or features on a local or remote server.
• RSAT-AD-PowerShell: Specifies the feature name for the Remote Server Administration Tools Active Directory PowerShell module.

For Windows Server 2008 R2, enter the following scripts in PowerShell

1. Install the ServerManager module (Windows Server 2012 R2 and later).
   CopyImport-Module ServerManager
   • Import-Module: Loads a module into the current PowerShell session, making its cmdlets and functions available for use.
   • ServerManager: Specifies the name of the module to load, which enables server role and feature management cmdlets.
2. Install the Windows Server roles.
   CopyAdd-WindowsFeature RSAT-AD-PowerShell
   • Add-WindowsFeature: Installs one or more Windows Server roles, role services, or features; the predecessor to the Install-WindowsFeature cmdlet on Windows Server 2008 R2.
   • RSAT-AD-PowerShell: Specifies the feature name for the Active Directory PowerShell tools on Windows Server 2008 R2.

2. Import the Active Directory module

1. Import the AD module:
   CopyImport-Module ActiveDirectory
   • Import-Module: Loads a module into the current PowerShell session, making its cmdlets and functions available for use.
   • ActiveDirectory: Specifies the name of the module to load into the current PowerShell session.
2. Check whether the module is installed:
   CopyGet-Module -ListAvailable ActiveDirectory
   • Get-Module: Retrieves a list of modules that have been imported or are available to be imported into the current session.
   • -ListAvailable: Returns all modules installed on the system, regardless of whether they are currently loaded.
   • ActiveDirectory: Filters the results to only show modules matching this name.
3. Verify that the module loaded successfully:
   CopyGet-Command -Module ActiveDirectory
   • Get-Command: Retrieves all commands available in the current PowerShell session, including cmdlets, functions, aliases, and scripts.
   • -Module ActiveDirectory: Restricts the output to only cmdlets and functions belonging to the AD module.

Required permissions

• The account running PowerShell needs Account Operator membership or delegated Reset Password / Unlock rights on the target organizational unit (OU). Domain Admin works but is overkill.
• Create a dedicated help-desk group and delegate the right on the relevant OUs.
• If the domain functional level is below 2008 R2, ADWS may not be running on every DC. You must use -Server to target a DC that has the following attributes:
  CopyUnlock-ADAccount -Identity jsmith -Server "dc01.corp.local"
  • -Identity: Accepts a SAM account name, UPN, DN, or GUID. jsmith here is the SAM account name, the most common form in scripts.
  • -Server: Targets a specific DC by hostname or FQDN. Useful when ADWS isn't running on all DCs, or when you want to avoid replication lag by hitting the PDC emulator
  directly.

Find locked out accounts using Search-ADAccount

Get user details

To get the user details of each locked user account in the domain with attribute information—such as SamAccountName, DistinguishedName, SID, ObjectClass, and LastLogonDate—use the following PowerShell script:

• Search-ADAccount -LockedOut: Queries AD for all accounts with the lockout flag set. No extra filter needed; the flag is a direct attribute.
• -UsersOnly: Restricts results to user accounts, filtering out computers and service accounts that can also appear in lockout queries.
• Select-Object: Trims the output to four useful columns:
  • SamAccountName: The login name
  • Name: Display name
  • DistinguishedName: Full LDAP path, useful for confirming which OU the account lives in
  • LastLogonDate: Helps spot stale or dormant accounts mixed in with real lockouts
• Format-Table -AutoSize: Renders as a table and adjusts column widths to fit the content rather than truncating.

Find AD accounts within a specific OU

To search for locked AD accounts within a specific OU, use the following PowerShell script:

• -SearchBase: Scopes the search to a specific OU rather than the entire directory. Takes a distinguished name; here, OU=Sales,OU=Users,DC=corp,DC=local targets only the Sales OU under Users.

Export a CSV of locked-out user accounts

To export locked-out user accounts to a CSV file for auditing, use the following PowerShell script:

• Export-Csv: Writes the output to a CSV file instead of the console, making it suitable for audit trails or sharing with non-technical staff.
• -Path: Specifies the destination file path. The directory must exist before running the script.
• -NoTypeInformation: Omits the #TYPE header line that PowerShell adds by default, keeping the CSV clean for Excel or log ingestion.

How is this different from Get-ADUser?

Get-ADUser -Filter {LockedOut -eq $true} looks like it should work, but it won't reliably since the LockedOut parameter is derived at query time and not stored as an AD attribute. Search-ADAccount -LockedOut is the right call here; it reads the lockoutTime parameter directly and applies the domain's lockout duration math on the server side. As a rule, use Search-ADAccount for state queries and Get-ADUser for attribute-level inspection.

Use this PowerShell script to get the properties of an identified account

• -Identity: Targets a single account and accepts several formats.

  Here's a quick look at the different identity formats that can be input:

  CopyGet-ADUser -Identity jdoe # SamAccountName Get-ADUser -Identity "jdoe@corp.local" # UPN Get-ADUser -Identity "CN=John Doe,OU=Sales,DC=corp,DC=local" # DN Get-ADUser -Identity "S-1-5-21-1111111111-2222222222-3333333333-1234" # SID
• -Properties: Requests attributes not returned by default. Without this, LockedOut, BadLogonCount, and LastBadPasswordAttempt are absent from the output.

Unlock a single AD account with Unlock-ADAccount

The most direct method to unlock an AD account with PowerShell is to use Unlock-ADAccount to clear the lockoutTime attribute on the user object, as shown in this PowerShell script:

To incorporate a confirmation call as a safety net, force a yes/no prompt:

Here is a sample PowerShell script to identify locked AD user accounts, unlock them, and verify that the account is accessible to the use:

If LockedOut flips back to True within a few minutes, a common cause is cached credentials.

Find and unlock all locked AD user accounts in bulk with PowerShell

To unlock all locked user accounts in bulk, use the following PowerShell script:

• Unlock-ADAccount: Accepts pipeline input from Search-ADAccount and clears the lockout flag on each account in the results. No -Identity needed—the pipeline handles the binding automatically.

  For a thorough bulk unlock of AD user accounts in PowerShell, complete with logging and error handling, use the following script:

  Copy <# Bulk-UnlockADAccounts.ps1 #>

param(
[string]$SearchBase = "OU=Users,DC=corp,DC=local", [string]$LogPath = "C:\Logs\BulkUnlock.log", [string]$Server = (Get-ADDomainController -Discover -Service PrimaryDC).HostName )

Import-Module ActiveDirectory

function Write-Log {
param([string]$Message) "$((Get-Date).ToString('s')) $Message" | Out-File -FilePath $LogPath -Append }

$locked = Search-ADAccount -LockedOut -UsersOnly -SearchBase $SearchBase -Server $Server

if (-not $locked) {
Write-Log "No locked accounts found under $SearchBase."
return
}

foreach ($u in $locked) {
try {
Unlock-ADAccount -Identity $u.DistinguishedName -Server $Server -ErrorAction Stop
Write-Log "Unlocked $($u.SamAccountName)"
}
catch {
Write-Log "FAILED $($u.SamAccountName) :: $($_.Exception.Message)"
}
}
• $SearchBase: Scopes the search to a specific OU. Defaults to OU=Users,DC=corp,DC=local: Adjust to match your directory structure.
• $LogPath: Destination for the log file. The directory must exist before running the script.
• $Server: Targets the PDC emulator by default, ensuring consistent reads and writes against a single authoritative DC. Pass a hostname to override.
• Write-Log: Stamps each action with an ISO 8601 timestamp and appends it to the log file.
• -ErrorAction Stop: Forces non-terminating errors into the catch block so failures are logged per account rather than silently skipped.

Account lockout policy best practices to prevent repeated lockouts

A well-tuned policy stops most lockouts before they start. The following table is Microsoft's current security baseline.

Setting the account lockout threshold to 0 disables lockout entirely and is not recommended for any environment, especially those required to maintain compliance with regulatory frameworks like NIST and PCI DSS.

Limitations to unlocking AD accounts with PowerShell

• There is no support for end users to unlock their locked accounts on their own from their Windows login screen or their mobile phones.
• Creating multiple automatic AD account unlock schedulers via PowerShell for different sets of users is a highly laborious process.

Simplify AD account unlocking with ADSelfService Plus

ADSelfService Plus cuts the help desk out entirely. Users verify their identity using advanced authentication methods—such as FIDO2 passkeys, biometrics, or time-based one-time passcodes—and unlock their own account. The help desk overhead is removed, and the end user saves time spent waiting for a resolution.

Enable self-service AD account unlock with ADSelfService Plus

1. Go to the ADSelfService Plus admin portal.
2. Navigate to Configuration > Self-Service > Policy Configuration.
3. Select Account Unlock.
4. Click Select OUs/Groups to granularly select which sets of users need to be provided with self-service account unlock capability.
5. Click Save.

Enable multi-factor authentication (MFA) for self-service account unlocks

1. Navigate to Configuration > Self-Service > Multi-Factor Authentication > Authenticator Setup.
2. Select a policy from the Choose the Policy drop-down.
3. Select and configure the authenticators you want to enforce for the account unlock flow.
4. Go to Configuration > Self-Service > Multi-Factor Authentication > MFA for Reset/Unlock.
5. In the MFA for Account Unlock section, enter the number of authentication methods to be enforced for account unlocks and select the authentication methods to be used.
6. Click Save Settings.

Schedule automatic account unlocks

ADSelfService Plus also supports scheduled automatic account unlocks, allowing administrators to define a specific time window at which accumulated lockouts are cleared in bulk. This is useful for environments where overnight lockouts from expired cached credentials or failed sync attempts would otherwise generate a wave of morning help desk calls.

To configure:

• Go to the ADSelfService Plus admin portal.
• Navigate to Configuration > Self-Service > Policy Configuration > Advanced.
• Check the Automatically unlocks locked-down accounts in your domain box.
• Click OK.

Why choose ADSelfService to unlock AD accounts?

• No admin in the loop: ADSelfService Plus enables self-service account unlocks to happen in under a minute, at any hour, without a ticket.
• Adaptive MFA on every unlock: Adaptive identity verification is supported with access time, geolocation, IP address, and device type analyzed via automated conditional access policies to authenticate every unlock attempt.
• OU and group-level scoping: Self-service account unlock policies apply precisely and with different rules for different departments, roles, or risk tiers.
• Automatic scheduled unlocks: Bulk unlocks can run on a defined schedule without a script to maintain.
• An audit trail that's built in: Every unlock is logged centrally in built-in reports, not scattered across log files on individual machines.

Frequently asked questions

Why do Active Directory accounts get locked out?

Active Directory (AD) accounts lock when incorrect password attempts cross the lockout threshold defined in Group Policy. The usual suspects are typos at the logon screen, cached credentials on remote machines, mapped drives still trying an old password, mobile devices polling Exchange using an old password, and service accounts whose password rotated without a service restart.

Where is an account lockout policy found in AD?

It's found in by going to Account Policies > Account Lockout Policy > Group Policy. It has three settings: Account lockout threshold (failed attempts before lockout), Account lockout duration (how long the account stays locked), and Reset account lockout counter after (the window in which bad attempts accumulate).

How do I prevent AD accounts from getting locked out?

Update saved credentials in Credential Manager, refresh mapped drives, sign mobile mail clients out and back in after every password change, and rotate service account passwords through a managed identity. Tune the lockout threshold so legitimate typos don't trigger it.