Helpdesk: "Dana's account locked again at 8:05, 8:40, and 9:15. I've unlocked it four times today and she swears she typed the right password every time. She changed it on Monday. The lockout event says the caller computer is EXCH01, which isn't even her PC. Marco in Finance has the same problem, and his event has no caller computer at all. Can you just raise the lockout threshold, or set them to never lock?"
Don't unlock it again yet. "Account keeps getting locked out" is rarely the user mistyping. It's usually one layer in a documented chain: the account is locked on the PDC emulator, under a policy (domain or fine-grained) that may be stricter than you think → event 4740 on the PDC emulator names the caller computer that sent the attempt that locked it → when that name is blank or a server, the bad attempts were relayed (RADIUS/NPS, Exchange, a web app), and 4771, 4776, and the Netlogon log show where they came from → on the source computer, something is still using the old password (a service, a scheduled task, a saved credential, a mapped drive, a disconnected session, a phone) → in a hybrid tenant, the lock may be Entra smart lockout instead of AD, or cloud sign-ins may be reaching AD through pass-through authentication → many accounts at once is a password spray, not a stale credential. Get-ADUser against the PDC emulator, Get-WinEvent for 4740, 4771, 4776, and 4625, the Netlogon log, and the Entra sign-in logs are the sources for that chain. Unlocking clears the lock. It doesn't clear the stale credential, which locks the account again.
If the user changed the password through self-service password reset and the change never reached AD, start with Entra Connect Password Writeback Not Working. If cloud sign-ins still accept the old password after an AD change, use Entra Connect Password Hash Sync Not Working. This post covers "an Active Directory account locks out again and again, after a password change or for no visible reason, and you need a read-first path to the source before you unlock it, raise the threshold, or turn lockout off."
TL;DR
-
Ask the PDC emulator. When a DC sees a bad password, it checks with the PDC emulator in case the password just changed, so the PDC emulator's bad password count for the user is the current one.
badPwdCountandbadPasswordTimearen't replicated between DCs. -
Event 4740 is the lockout, and its Caller Computer Name is the next hop. It's logged under Audit User Account Management. In the event XML, the caller computer is stored in the
TargetDomainNamefield. -
A blank or server caller name means the attempt was relayed. Microsoft's example is a RADIUS server forwarding Wi-Fi sign-ins, which shows up in the Netlogon log as
(via LOB11-RADIUS)returning0xC000006A. Follow 4771 (Client Address) and 4776 (Source Workstation) on the DCs. - The source computer holds the stale credential. Microsoft's list: services, scheduled tasks, saved credentials, persistent drive mappings, disconnected Remote Desktop sessions, programs that cache credentials, and the user still signed in on another computer.
- Recent old passwords usually don't count. With password history of 3 or more, a bad attempt that matches one of the two most recent passwords doesn't add to the count for Kerberos and NTLM. RADIUS and some other protocols may still count them, which is why phones and Wi-Fi lock accounts.
- Hybrid: check which directory locked it. Entra sign-in error 50053 is smart lockout (or a sign-in from a malicious IP). With pass-through authentication, Microsoft says the Entra lockout threshold must be lower than the AD threshold.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Account, two or more lock times, password change date, devices, exact message | "She keeps getting locked out" with no times |
| 2. Lock state and policy | You've read the lock on the PDC emulator and the policy that actually applies to this user | Locks after three tries; "it unlocks itself" or never does |
| 3. Lockout event | 4740 on the PDC emulator with a caller computer name | No 4740 at all because auditing is off |
| 4. Relayed attempts | The caller is a client, or the relay's source is found through 4771, 4776, or Netlogon | Caller blank, or an Exchange, NPS, RDS, or web server |
| 5. Source computer | The process or saved credential using the old password is found | Locks every few minutes after a password change |
| 6. Hybrid and cloud | You know whether AD, Entra ID, AD FS, or Entra Domain Services locked it | Locked in Microsoft 365 but not in AD, or the reverse |
| 7. One user or an attack | One account with a known source, or many accounts at once | Dozens of accounts lock together |
| 8. Change | Only after Steps 1–7 agree: fix the credential, then unlock | Unlocked five times, threshold raised, still locking |
Step 1: Capture the exact symptom (read-only)
Write these facts on the ticket before anyone unlocks the account again:
| Fact | Why it matters |
|---|---|
| The account (sAMAccountName and UPN) | You'll query it on the PDC emulator and in the Entra sign-in logs |
| At least two lock times | A steady interval points at a service, task, or app retrying. Random times point at a person or a phone |
| When the password last changed, and how | Ctrl+Alt+Del, self-service password reset, or an admin reset. Most repeat lockouts start right after a change (Step 5) |
| Every device and app the user signs in with | PCs, RDS or Citrix hosts, phone mail, Wi-Fi, VPN, line-of-business apps |
| Where the lock message appears | A Windows sign-in or file share points at AD. "Your account is temporarily locked to prevent unauthorized use" on a Microsoft sign-in page is Entra smart lockout (Step 6) |
| One user or many | Many at once goes to Step 7 first |
| Is it a service account? | Service accounts are Microsoft's classic example (Step 5) |
Then match the symptom:
| What you see | Likely layer |
|---|---|
| Locks again within minutes of every unlock | A process retrying an old password (Step 5) |
| Started right after a password change | The old password is cached somewhere (Steps 4 and 5) |
| 4740 caller is an Exchange, NPS, RDS, or web server | Relayed authentication (Step 4) |
| 4740 caller is blank | Relayed network logon, such as RADIUS (Step 4) |
| Locked at a Microsoft 365 sign-in, AD account not locked | Entra smart lockout (Step 6) |
| Many accounts lock together, callers outside your domain | Password spray or denial of service (Step 7) |
| Lockouts jumped after a security baseline was applied | The threshold changed (Step 2) |
Step 2: Is it locked, where, and under which policy? (read-only)
Read the account on the PDC emulator first. Microsoft's TechNet Wiki test of account lockout explains why: whenever a DC finds a bad password, it immediately contacts the PDC emulator to check whether the password was recently changed. If the PDC emulator says it's still bad, the PDC emulator increments its own count. Its values for the user are the current ones. badPwdCount, badPasswordTime, and logonCount aren't replicated, so every other DC has its own, smaller numbers. lockoutTime is on the urgent replication list in Microsoft's AD protocol spec, so the lock itself spreads quickly. Urgent replication still isn't instant convergence, especially between sites.
# Read-only. ActiveDirectory module (RSAT). The PDC emulator has the current lockout state
$pdc = (Get-ADDomain).PDCEmulator
Get-ADUser -Identity 'dana' -Server $pdc `
-Properties LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet |
Format-List SamAccountName, Enabled, LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet
# Read-only: every locked account in the domain, as the PDC emulator sees it
Search-ADAccount -LockedOut -UsersOnly -Server $pdc | Select-Object Name, SamAccountName
# Read-only: the per-DC bad password count (not replicated). Shows which DCs the attempts hit
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
Get-ADUser -Identity 'dana' -Server $dc -Properties BadLogonCount, LastBadPasswordAttempt |
Select-Object @{n='DC';e={$dc}}, BadLogonCount, LastBadPasswordAttempt
}
A DC whose LastBadPasswordAttempt keeps moving is the DC the source talks to. That narrows the site, and often the subnet, before you open a single event log.
Which policy applies. Read both the domain policy and any fine-grained policy:
# Read-only: the domain's lockout policy
Get-ADDefaultDomainPasswordPolicy |
Format-List LockoutThreshold, LockoutDuration, LockoutObservationWindow, PasswordHistoryCount
# Read-only: a fine-grained password policy (PSO) that wins for this user, if any
Get-ADUserResultantPasswordPolicy -Identity 'dana' |
Format-List Name, Precedence, LockoutThreshold, LockoutDuration, LockoutObservationWindow, AppliesTo
| Setting | What Microsoft documents |
|---|---|
| Account lockout threshold | 0–999 failed attempts. 0 means the account never locks, and 0 is the Default Domain Policy's default. Microsoft's "Configuring Account Lockout" baseline post picked 10 attempts, 15 minutes, 15 minutes (10/15/15). The Windows Server 2025 security baseline lowers the threshold to 3 and keeps 15/15 |
| Account lockout duration | 1–99,999 minutes. 0 means locked until an admin unlocks it. It must be greater than or equal to the reset counter value |
| Reset account lockout counter after | Minutes after a failed attempt before the counter returns to 0. Microsoft's wiki test shows it's measured from the last time badPasswordTime was updated, not a fixed window from the first attempt |
| Enforce password history | Needs to be at least 3 for the "two most recent passwords don't count" behavior below |
| Fine-grained policy (PSO) | A PSO linked directly to the user beats one linked through a group. Among several, the lowest precedence value wins. Get-ADUserResultantPasswordPolicy returns the winner |
Three documented details that change how fast an account locks:
-
The two most recent passwords don't count, for Kerberos and NTLM. On Windows Server 2003 functional level and later, a bad attempt matching either of the two most recent passwords in history doesn't increment
badPwdCount. Microsoft's wiki adds that RADIUS and PEAP may still count them, and some protocols don't forward bad attempts to the PDC emulator at all. That's how a phone or Wi-Fi profile with last month's password can lock an account when a person typing it wouldn't. - Kerberos encryption type retries can count. The threshold page says Kerberos can automatically retry sign-in attempts during encryption type negotiation, and those count toward the threshold. So can apps that reconnect over and over after a dropped connection.
- Unlocking a PC with a different password goes to a DC. Microsoft: if you type a different password from the one you signed in with, Windows has to contact a DC in case the password changed on another machine. Those failed unlock attempts count.
If lockouts jumped right after someone imported the Windows Server 2025 security baseline, compare the threshold before and after. Going from 10 to 3 turns every stale credential into a lockout much faster.
Step 3: Read event 4740 on the PDC emulator (read-only)
Event 4740, "A user account was locked out," is in the Audit User Account Management subcategory. Microsoft's PowerShell blog post on tracing lockouts notes that from Windows Server 2008 on, the lockout registers on the PDC emulator as 4740 with the source included. Check that the subcategory is audited on your DCs before you trust an empty result:
# Read-only, on a DC (elevated): is User Account Management audited?
auditpol /get /subcategory:"User Account Management"
# Read-only: lockouts for one user on the PDC emulator, last 24 hours
$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -LogName Security -FilterXPath `
"*[System[EventID=4740 and TimeCreated[timediff(@SystemTime) <= 86400000]] and EventData[Data[@Name='TargetUserName']='dana']]" |
Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='CallerComputer';e={$_.Properties[1].Value}}
| Field | What Microsoft documents |
|---|---|
| Account That Was Locked Out | The account. In the XML it's TargetUserName
|
| Caller Computer Name | The computer the logon attempt was received from, after which the account locked. In Microsoft's sample XML it's the TargetDomainName value (WIN81), which is why the script reads the second property |
| Subject | Usually SYSTEM (the DC's computer account). Microsoft recommends reporting any 4740 where it isn't |
| A caller outside your domain | Microsoft: you still get a computer name, not an IP address. Microsoft recommends monitoring for these |
If the policy for User Account Management shows No Auditing, there's nothing to read yet. Turn on auditing for that subcategory in a GPO linked to the Domain Controllers OU (Advanced Audit Policy Configuration → Account Management), then wait for the next lockout. Events are only captured from the time auditing is on.
Microsoft's older EventCombMT tool can search many DCs at once, but its built-in Account Lockouts search uses the pre-2008 event IDs (529, 644, 675, 676, 681). If you use it, add 4740, 4771, and 4776.
Step 4: Caller blank or a server? Follow the bad attempts (read-only first)
The caller computer is the last hop, not always the device with the old password. When an Exchange server, RDS host, NPS (RADIUS) server, web app, or VPN authenticates on the user's behalf, that server is the caller. Microsoft's Entra Domain Services lockout article explains the blank case: Source Workstation in 4776 and 4740 can be empty when the bad password came in over a network logon through another device, and its example is a RADIUS server.
Read the DCs' failure events for the same minutes as the 4740:
# Read-only: Kerberos pre-auth failures (4771) and NTLM validations (4776) for the user, every DC, last 2 hours
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
Get-WinEvent -ComputerName $dc -LogName Security -ErrorAction SilentlyContinue -FilterXPath `
"*[System[(EventID=4771 or EventID=4776) and TimeCreated[timediff(@SystemTime) <= 7200000]] and EventData[Data[@Name='TargetUserName']='dana']]" |
ForEach-Object {
$e = $_
$d = @{}
foreach ($n in ([xml]$e.ToXml()).Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
[pscustomobject]@{ DC = $dc; Time = $e.TimeCreated; Id = $e.Id; Status = $d['Status']; ClientAddress = $d['IpAddress']; Workstation = $d['Workstation'] }
}
}
| Event | What Microsoft documents |
|---|---|
| 4771 Kerberos pre-authentication failed | Only on DCs (Audit Kerberos Authentication Service). Client Address is the IP the request came from. Failure code 0x18 is a wrong password. 0x17 is an expired password, which is a different ticket. Not logged for accounts set to not require Kerberos pre-authentication |
| 4776 credential validation (NTLM) | On the computer that's authoritative for the account, which is a DC for domain accounts (Audit Credential Validation). Source Workstation is where the attempt came from. 0xC000006A is a bad password, 0xC0000234 is a locked account, 0xC0000071 is an expired password, 0xC0000064 is an unknown user name |
When the events stop at a relay, use the Netlogon log. Microsoft's Netlogon debug logging article covers account lockout troubleshooting. On Windows Server 2012 R2 and later you don't usually need to restart Netlogon:
# Diagnostic change (reversible): verbose Netlogon logging on the PDC emulator first
nltest /DBFlag:2080FFFF
# Read-only: after the next lockout, find the user's lines
Select-String -Path "$env:windir\debug\netlogon.log" -Pattern 'dana' | Select-Object -Last 20
# Turn it back off when you're done
nltest /DBFlag:0x0
Microsoft's sample line looks like SamLogon: Transitive Network logon of contoso\user from (via LOB11-RADIUS) Returns 0xC000006A. The name after via is the server that relayed the attempt. If it names another DC, read that DC's log next, and keep following it until you reach a server that isn't a DC. The log rolls to netlogon.bak at 20 MB by default. Microsoft advises against turning verbose Netlogon logging on through a policy that applies everywhere, such as the Default Domain Policy.
Once you've named the relay, read its logs for the client: the Security log 4625 events on that server (Source Network Address, Step 5), the NPS logs for a Wi-Fi or VPN RADIUS server, or the web logs for Exchange or another IIS app. A phone with an old password usually shows up there, not in AD.
Step 5: On the source computer, find the stale credential (read-only)
Event 4625, "An account failed to log on," is logged on the computer where the logon was attempted. On the source computer it tells you what kind of logon kept failing and which process asked for it:
# Read-only, on the source computer (elevated): failed logons for the user, last 2 hours
Get-WinEvent -LogName Security -FilterXPath `
"*[System[EventID=4625 and TimeCreated[timediff(@SystemTime) <= 7200000]] and EventData[Data[@Name='TargetUserName']='dana']]" |
ForEach-Object {
$e = $_
$d = @{}
foreach ($n in ([xml]$e.ToXml()).Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
[pscustomobject]@{ Time = $e.TimeCreated; LogonType = $d['LogonType']; Status = $d['Status']; SubStatus = $d['SubStatus']; Process = $d['ProcessName']; SourceIP = $d['IpAddress'] }
}
| Logon type in 4625 | Microsoft's description | Where to look |
|---|---|---|
| 3 Network | Logged on to this computer from the network | The source IP is another hop. Repeat Step 5 there |
| 4 Batch | Processes running on behalf of a user without their direct intervention | Scheduled tasks |
| 5 Service | A service started by the Service Control Manager | Services |
| 7 Unlock | The workstation was unlocked | The user, or someone, unlocking with a different password |
| 10 RemoteInteractive | Remote Desktop | An RDS host or a disconnected session |
Then read the places Microsoft lists for stale credentials:
# Read-only (elevated): services and scheduled tasks that run as the user
Get-CimInstance Win32_Service | Where-Object { $_.StartName -like '*dana*' } |
Select-Object Name, StartName, State
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like '*dana*' } |
Select-Object TaskPath, TaskName, State
# Read-only, signed in as the user: saved credentials and mapped drives
cmdkey /list
net use
# Read-only: sessions on an RDS host or server, including disconnected ones
query user
| Cause | What Microsoft documents |
|---|---|
| Service running as the user | The Service Control Manager caches the service's password. After a reset, the service keeps retrying the old one and locks the account |
| Scheduled task | Tasks may be configured with credentials that have since changed |
| Saved credentials | Stored user names and passwords can keep an old password. Remove the ones that only duplicate the logon credential |
| Persistent drive mapping | A drive mapped with explicit credentials retries at every logon and restore. Microsoft's options: net use /persistent:no, or disconnect and reconnect the drive |
| Disconnected Remote Desktop session | A process in the old session keeps using outdated credentials. The source is the single RDS host |
| Signed in on several computers | Programs on the other computers keep the old password. Microsoft's advice: sign out of all computers, change the password in one place, then sign out and back in |
| Programs and apps | Many programs cache credentials or keep threads that retain them after a password change. An app or service with an old password is also one of Microsoft's three common causes in Entra Domain Services |
Why it starts a few minutes after the change. Microsoft documents that after a domain user changes a password over NTLM, the old password still works for NTLM network access for five minutes by default (OldPasswordAllowedPeriod on the DCs). A service or mapped drive can keep working for a short time after the change, then start failing and lock the account. Fix the credential instead of stretching that window.
Step 6: Hybrid and cloud: which directory locked it? (read-only)
A user who says "I'm locked out" may be locked in Entra ID, not AD. Read the Entra sign-in logs (Monitoring & health → Sign-in logs) for the user and look for error 50053. Microsoft's error reference gives it two reasons: IdsLocked, too many sign-in attempts with a wrong user ID or password, or a sign-in blocked because it came from an IP address with malicious activity. The Failure reason in the log tells you which.
| Setup | What Microsoft documents |
|---|---|
| Smart lockout (every tenant) | Default: locks after 10 failed attempts (Azure Public). The first lockout lasts one minute and later ones last longer. It tracks the last three bad password hashes, so the same wrong password repeated doesn't add to the count. Familiar and unfamiliar locations have separate counters. Changing the values needs Entra ID P1 or higher |
| Password hash sync | Microsoft says smart lockout can protect on-premises AD accounts from attackers in hybrid deployments with password hash sync or pass-through authentication |
| Pass-through authentication | The password is checked on-premises, and hash tracking isn't available. The Entra lockout threshold must be less than the AD threshold (Microsoft suggests AD at two or three times the Entra value), and the Entra lockout duration must be longer than AD's. Entra's is in seconds, AD's in minutes. Microsoft's example: Entra 10 attempts and 120 seconds, AD 20 attempts and 1 minute |
| AD FS | AD FS 2016 and 2019 have Extranet Lockout and Extranet Smart Lockout. Microsoft recommends moving to managed authentication |
| Entra Domain Services | Its own default: 5 bad attempts in 2 minutes, automatic unlock after 30 minutes, set by fine-grained password policy. A password changed on-premises takes a few minutes to sync, and sign-ins before then can lock the account |
| Self-service password reset with writeback | By default, Entra ID unlocks the on-premises account when it resets the password. Allow users to unlock accounts without resetting their password separates the two |
With pass-through authentication, a phone retrying an old password against Microsoft 365 is checked against AD, so a wrong PTA threshold lets cloud sign-ins lock the AD account. With password hash sync, the cloud sign-in is checked in Entra ID, so the same phone shows up as smart lockout and 50053 in the sign-in logs instead. Read the setup before you blame either directory.
On the cloud side, Microsoft notes that I forgot my password in self-service password reset resets the lockout duration to 0, while I know my password leaves the timer running.
Step 7: One user, or an attack? (read-only)
Microsoft's lockout threshold page is blunt about the tradeoff. A lockout threshold makes denial of service possible: anyone with network access who knows account names can lock them, with no other credentials.
| Signal | What Microsoft's monitoring guidance says |
|---|---|
| Many accounts lock in the same minutes | Not a stale credential. Treat it as an attack until proven otherwise |
| 4740 caller computers that aren't in your domain | Microsoft recommends monitoring for exactly this |
| Bursts of 4771 with 0x18 or 4776 with 0xC000006A | "N events in the last N minutes" can indicate a brute-force password attack |
| Bursts of 4776 with 0xC0000064 | Can indicate account enumeration |
| 4740 Subject isn't SYSTEM | Microsoft recommends reporting it |
Don't fix an attack by turning lockout off. Microsoft's countermeasure for a threshold of 0 applies only if both conditions are met: all passwords are complex with 8 or more characters, and a robust audit mechanism alerts admins to a series of failed sign-ins. In a hybrid tenant, smart lockout set correctly (Step 6) filters attacks before they reach AD.
Step 8: Change one layer, then watch (only after the read)
Pick the one change Steps 1–7 point at:
- Fix the credential at the source first: update the service's logon password, the scheduled task's credentials, the saved credential, or the drive mapping, sign out the disconnected session, or update the phone's mail profile.
- Then unlock the account, on the PDC emulator, so the unlock doesn't wait on replication.
-
Watch one reset window: rerun the Step 2 and Step 3 reads.
BadLogonCounton the PDC emulator should stay at 0 and no new 4740 should appear. -
Turn diagnostics back off:
nltest /DBFlag:0x0on every DC where you turned it on. - Policy, only with the security owner's sign-off: a fine-grained policy for one group, rather than loosening the domain policy, and only after the source is fixed.
- Hybrid: line up the pass-through authentication thresholds as Microsoft describes, and consider the unlock-without-reset option for self-service password reset.
# Change (one account): unlock on the PDC emulator, after the stale credential is fixed
$pdc = (Get-ADDomain).PDCEmulator
Unlock-ADAccount -Identity 'dana' -Server $pdc
# Read-only: confirm it stays unlocked through the next reset window
Get-ADUser -Identity 'dana' -Server $pdc -Properties LockedOut, BadLogonCount, LastBadPasswordAttempt |
Format-List LockedOut, BadLogonCount, LastBadPasswordAttempt
If it locks again, the new 4740 names the next source. A user with two stale devices locks twice.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Service or scheduled task with the old password | Update that service or task, then unlock | Raising the threshold for the whole domain |
| 4740 caller is an Exchange or NPS server | Follow the Netlogon via chain and the relay's logs to the device |
Unlocking every hour until the user gives up |
| Phone or Wi-Fi profile with an old password | Update or remove the profile on the device | Disabling lockout because "phones do this" |
| Disconnected RDS session | Sign out the session | Rebuilding the user's profile |
| Threshold dropped to 3 after the Server 2025 baseline | Decide the value deliberately with the security owner | Silently reverting the baseline |
| Service account that has to keep a password | A fine-grained policy for that group, plus a list of where the account is used | Turning off lockout for everyone |
| Locked in Entra ID, not AD | Read 50053's Failure reason; SSPR or an admin unlock in Entra | Unlocking the AD account that isn't locked |
| Many accounts at once | Treat as an attack; check callers and sources | Setting the threshold to 0 |
FAQ
How do I find the source of an account lockout?
Find the PDC emulator ((Get-ADDomain).PDCEmulator) and read event 4740 for the user. Its Caller Computer Name is the computer the attempt came from. If that's blank or a server, read 4771 (Client Address) and 4776 (Source Workstation) on the DCs, then the Netlogon log's via name, and repeat on that server until you reach the device.
Why does my AD account keep getting locked out after a password change?
Something still has the old password: a service, a scheduled task, a saved credential, a mapped drive, a disconnected Remote Desktop session, an app, another computer you're signed in on, or a phone. Kerberos and NTLM don't count the two most recent passwords, but RADIUS and some other protocols may, which is why phones and Wi-Fi are common sources.
Why is the caller computer name blank in event 4740?
The bad attempt reached the DC through another server, such as a RADIUS (NPS) server. Microsoft's example shows the relay in the Netlogon log as (via LOB11-RADIUS). Follow the relay's own logs to the client.
What is event ID 4740?
"A user account was locked out." It's logged under Audit User Account Management, with the Caller Computer Name in the event. Microsoft's event reference says it's generated on domain controllers, member servers, and workstations. For a domain account, read it on the PDC emulator, which is where Microsoft's lockout-tracing post collects it.
Should I raise the account lockout threshold?
Not to stop repeat lockouts. Microsoft's Entra Domain Services article says the same: find the source before you change the thresholds. Microsoft's baselines picked 10 attempts (10/15/15), and the Windows Server 2025 baseline uses 3. A threshold of 0 only fits Microsoft's two conditions (complex passwords of 8 or more characters, plus alerting on failed sign-ins).
Related posts
- Entra Connect Password Writeback Not Working (self-service resets and unlocks that never reach AD)
- Entra Connect Password Hash Sync Not Working (when the cloud still takes the old password after an AD change)
- Group Policy Not Applying (when the lockout or audit policy you set isn't the one the DCs are using)
Free checklist
A lockout storm is often the first visible sign of a password spray, and that's the afternoon someone wants to rush "require MFA" or "block legacy authentication" into Conditional Access for everyone. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=ad-account-keeps-getting-locked-out
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 favor read-only checks: Get-ADUser, Search-ADAccount, Get-ADDomainController, Get-ADDefaultDomainPasswordPolicy, Get-ADUserResultantPasswordPolicy, auditpol /get, Get-WinEvent, Select-String on the Netlogon log, Get-CimInstance, Get-ScheduledTask, cmdkey /list, net use, query user, and the Entra sign-in logs. Turning on Netlogon debug logging or auditing, unlocking accounts, changing service, task, or saved credentials, and changing lockout, fine-grained, smart lockout, or self-service password reset settings are deliberate changes. Change one layer at a time, watch one reset window, and check current Microsoft Learn for policy values and console labels.
Top comments (0)