> ## Documentation Index
> Fetch the complete documentation index at: https://docs.derekdinh.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Active Directory Account Lockout: Diagnose and Fix
> Unlock Active Directory accounts, trace the lockout source using Event Viewer, and eliminate stale credentials causing repeated lockouts.
Account lockouts are one of the most common helpdesk tickets in organisations using Active Directory. They are frustrating for end users and time-consuming to diagnose if you do not know where to look. Most lockouts stem from a predictable set of causes — stale saved credentials, mobile devices using an old password, or mapped drives that have not been updated after a password change — and all of them leave an auditable trail you can follow.
## Why Accounts Get Locked Out
Understanding the root cause prevents the account from locking again minutes after you unlock it.
A user mistyping their password repeatedly is the most straightforward cause. The domain lockout policy (typically 5–10 failed attempts) triggers the lockout. Confirm by asking the user whether they recently changed their password and then tried to log in from memory.
A smartphone or tablet configured for corporate email (Exchange ActiveSync, Outlook Mobile) will keep retrying with the old password after a password change, silently burning through the failed-attempt threshold in seconds. The device does not warn the user — the account simply locks.
Mapped drives saved with explicit credentials (`net use` with `/savecred`, or drives mapped via Group Policy with embedded credentials) will authenticate on every reconnect attempt, including at logon. If the password has changed and the saved credential has not been updated, each reconnect is a failed authentication.
If a Windows Scheduled Task is configured to run under a user account and that account's password has changed without updating the task, the task runner will generate failed authentications every time the task fires.
Saved credentials in **Windows Credential Manager** (`control keymgr.dll`) can hold an outdated password for a server, SharePoint site, or Teams/Skype resource, causing repeated background failures.
***
## Step-by-Step Resolution
The first priority is restoring access to the user. Investigation comes next.
1. Open **Active Directory Users and Computers (ADUC)** — press `Windows + R` and run `dsa.msc`.
2. Locate the user account. Use **Find** (`Ctrl + F`) and search by username or display name if you do not know the OU.
3. Right-click the account and select **Properties**.
4. Go to the **Account** tab.
5. Tick **Unlock account** (the checkbox reads *"Account is locked out"* when locked) and click **Apply → OK**.
You can also unlock an account directly from PowerShell without opening the GUI, which is faster when working remotely:
```powershell theme={null}
# Unlock a single AD account
Unlock-ADAccount -Identity "jsmith"
# Verify the account is no longer locked
Get-ADUser -Identity "jsmith" -Properties LockedOut | Select-Object Name, LockedOut
```
Unlocking the account **before** identifying the root cause means it will likely lock again within minutes if stale credentials are still active. Proceed immediately to the next steps.
**Event ID 4740** is logged on the Domain Controller (DC) that processed the lockout. It identifies both the source machine and the caller's computer name, giving you a precise starting point.
**On the Domain Controller (or via Remote Event Viewer):**
1. Open **Event Viewer** → expand **Windows Logs** → click **Security**.
2. In the right pane, click **Filter Current Log**.
3. In the **Event IDs** field, enter `4740` and click **OK**.
4. Find the most recent event for the affected username.
5. In the event details, note the value of **Caller Computer Name** — this is the machine sending bad credentials.
The lockout event is written on the **PDC Emulator** FSMO role holder, not necessarily the DC the user authenticated against. Run the query below to confirm which DC holds the PDC Emulator role.
```powershell theme={null}
# Find the PDC Emulator in your domain
(Get-ADDomain).PDCEmulator
```
**Query lockout events via PowerShell:**
```powershell theme={null}
# Search the Security log on the PDC for lockout events for a specific user
$PDC = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
LogName = 'Security'
Id = 4740
} | Where-Object { $_.Properties[0].Value -eq "jsmith" } |
Select-Object TimeCreated,
@{N='LockedUser'; E={ $_.Properties[0].Value }},
@{N='SourceMachine'; E={ $_.Properties[1].Value }}
```
Replace `"jsmith"` with the actual SAM account name.
Once you have the **Caller Computer Name** from Event ID 4740, connect to that machine and look for what is sending the bad credentials.
**Check for failed logon attempts (Event ID 4625) on the source machine:**
```powershell theme={null}
# Run on the source machine or via Invoke-Command
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625 } -MaxEvents 50 |
Select-Object TimeCreated,
@{N='User'; E={ $_.Properties[5].Value }},
@{N='LogonType'; E={ $_.Properties[10].Value }},
@{N='ProcessName'; E={ $_.Properties[18].Value }}
```
Logon Type codes to watch for:
| Logon Type | Source |
| ---------- | ----------------------------------------- |
| **2** | Interactive (keyboard) |
| **3** | Network (mapped drives, UNC paths) |
| **4** | Batch (Scheduled Tasks) |
| **7** | Unlock (screensaver) |
| **8** | NetworkCleartext (older IIS / basic auth) |
If the source machine belongs to the affected user, open **Windows Credential Manager** to remove any outdated stored passwords.
1. Press `Windows + R`, type `control keymgr.dll`, and press **Enter**.
2. Click **Windows Credentials**.
3. Expand any entry referencing your domain, server, SharePoint, or Outlook/Teams.
4. Click **Remove** for any entry associated with the user's credentials.
5. When prompted to re-authenticate, supply the **current** password.
```powershell theme={null}
# List all stored Windows Credentials via cmdkey
cmdkey /list
# Delete a specific stored credential
cmdkey /delete:target_name_here
```
Look specifically for entries beginning with `MicrosoftOffice`, `Domain:`, or `LegacyGeneric:` — these are common culprits after a password reset.
1. Open **File Explorer** and look for drives showing a red X (disconnected).
2. Right-click the disconnected drive and select **Disconnect**.
3. Reconnect the drive by browsing to the network path and providing updated credentials.
4. To make the fix persistent, re-map with a logon script or update the Group Policy Preference that manages the drive.
```powershell theme={null}
# Remove and re-map a drive with updated credentials
net use Z: /delete
net use Z: \\server\share /user:DOMAIN\jsmith CurrentPassword /persistent:yes
```
Open **Task Scheduler** (`taskschd.msc`) on the source machine and look for tasks running under the affected user account.
1. In the left pane, browse to **Task Scheduler Library**.
2. In the central pane, check the **Run As** column for the affected username.
3. Double-click the task → go to the **General** tab → click **Change User or Password**.
4. Re-enter the current password and click **OK**.
```powershell theme={null}
# Find all tasks running as a specific user
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like "*jsmith*" } |
Select-Object TaskName, TaskPath
```
If the lockout source points back to a server (e.g., your Exchange server), the originating device is almost certainly a mobile phone or tablet.
1. In the **Exchange Admin Center (EAC)** or via PowerShell, check ActiveSync devices registered to the user:
```powershell theme={null}
# List ActiveSync devices for a mailbox
Get-MobileDeviceStatistics -Mailbox "jsmith" |
Select-Object DeviceFriendlyName, LastSyncAttemptTime, Status
```
2. Ask the user to update the corporate account password on their mobile email client, or temporarily block the device using `Remove-MobileDevice` if the password update does not resolve the issue.
On Microsoft 365 / Exchange Online, you can view and wipe ActiveSync devices from **Microsoft 365 Admin Center → Users → \[User] → Mail → Manage email apps**.
After addressing the root cause, verify the account remains unlocked over the next 15–30 minutes.
```powershell theme={null}
# Monitor lock status (run repeatedly or wrap in a loop)
Get-ADUser -Identity "jsmith" -Properties LockedOut, BadLogonCount, LastBadPasswordAttempt |
Select-Object Name, LockedOut, BadLogonCount, LastBadPasswordAttempt
```
If `BadLogonCount` continues to climb after you have cleared credentials and updated mapped drives, escalate — there may be an additional source you have not identified yet.
***
## Escalation
Escalate to a senior AD administrator or the Security team if:
* The account continues to lock out every few minutes despite clearing all known credential sources.
* Event ID 4740 shows the source machine as a **server** you cannot identify — this may indicate a compromised service account or brute-force attack.
* Multiple user accounts are locking out simultaneously — this can indicate a domain-wide password-spray attack.
* You discover an unknown service or scheduled task using the account's credentials.
Include the username, the Caller Computer Name from the 4740 event, timestamps, and the steps you have already taken in your escalation ticket.