This chapter covers Account Lockout Policies in Windows environments, a critical security mechanism tested in CompTIA A+ 220-1102 (Objective 2.2). Account lockout policies help prevent brute-force attacks by disabling a user account after a specified number of failed logon attempts. Expect 2-3 exam questions on this topic, focusing on default values, configuration tools (Group Policy, Local Security Policy), and the interaction between lockout threshold, lockout duration, and reset counter.
Jump to a section
Imagine a bank vault with a digital keypad. The bank manager sets a policy: after 3 incorrect PIN entries, the vault locks for 15 minutes. This prevents a thief from rapidly guessing combinations. When an employee enters the wrong PIN, a counter increments. On the third wrong attempt, a timer starts, and the vault refuses all PIN entries—even correct ones—until the timer expires. The bank's security system logs each attempt: username (employee ID), timestamp, and workstation (branch location). If the employee later remembers the correct PIN, they must wait the full 15 minutes. The manager can manually override the lockout from a central console, but that requires administrative credentials. In a corporate network, Active Directory acts as the bank manager, setting the lockout threshold (3 attempts), lockout duration (15 minutes), and reset counter after (30 minutes). The domain controller logs failed attempts in the Security event log. Help desk technicians can unlock accounts using Active Directory Users and Computers, but only if they have delegated permissions. This mechanistic analogy directly mirrors Windows account lockout policies: the threshold, duration, and reset timer are configurable, and the lockout applies per user account, not per workstation.
What is Account Lockout and Why Does It Exist?
Account lockout is a security policy that temporarily disables a user account after a defined number of failed logon attempts within a specified period. Its primary purpose is to mitigate brute-force password guessing attacks. Without lockout, an attacker could attempt thousands of passwords per minute until they find the correct one. By locking the account after a few failed attempts, the system makes brute-force attacks impractical.
In Windows environments, account lockout policies are part of the Account Policies section under Security Settings in Local Security Policy or Group Policy Management. They apply to domain accounts (via Group Policy) or local accounts (via Local Security Policy). The three key settings are:
Account lockout threshold: The number of failed logon attempts that triggers a lockout.
Account lockout duration: How long the account remains locked before automatically unlocking.
Reset account lockout counter after: The time after which the failed attempt counter resets to zero.
How Account Lockout Works Internally
When a user attempts to log on, the authentication process involves the Local Security Authority (LSA) on the workstation or the domain controller (DC) for domain accounts. The DC or local machine maintains a badPwdCount attribute for each user account. This attribute is incremented on each failed logon attempt and reset to 0 on a successful logon or after the reset period.
Step-by-step mechanism:
User enters username and password.
The authentication package (Kerberos or NTLM) sends the credentials to the DC (domain) or LSA (local).
If the password is incorrect, the DC increments badPwdCount for that user.
The DC checks if badPwdCount >= lockout threshold.
If yes, the account is locked: the userAccountControl attribute is modified to include the LOCKOUT flag (0x10).
The DC returns an error: STATUS_ACCOUNT_LOCKED_OUT (0xC0000234) or ERROR_ACCOUNT_LOCKED_OUT (0x775).
The client displays a generic message: "The referenced account is currently locked out and may not be logged on to."
During the lockout duration, all subsequent logon attempts fail immediately, even with the correct password.
After the lockout duration expires, the DC automatically clears the LOCKOUT flag and resets badPwdCount to 0.
Alternatively, an administrator can manually unlock the account via Active Directory Users and Computers (ADUC) or net user command.
Key Components, Values, Defaults, and Timers
Default values:
Account lockout threshold: Not defined (0) by default in Windows Server and client OS. This means no lockout occurs. The exam expects you to know that the default is 0 (disabled).
Account lockout duration: Not defined until threshold is set. Once threshold is set, Windows suggests a default of 30 minutes.
Reset account lockout counter after: Not defined until threshold is set. Windows suggests a default of 30 minutes.
Common recommended values (not default, but often set by organizations):
Threshold: 5-10 attempts
Duration: 15-30 minutes
Reset counter after: 15-30 minutes
Important timers and behavior:
The badPwdCount attribute is maintained on the domain controller that processed the authentication. In multi-DC environments, there is replication latency, which can cause lockout confusion (a user may be locked out on one DC but not another until replication completes).
The lockout duration timer starts at the moment the account is locked, not at the time of the last failed attempt.
The reset counter timer starts after each failed attempt. If the user makes no further failed attempts within the reset period, the counter resets to 0. If they make another failed attempt before the reset period expires, the counter remains and the timer restarts.
Configuration and Verification Commands
Local Security Policy (secpol.msc):
Navigate to Security Settings > Account Policies > Account Lockout Policy. Configure three settings:
Account lockout threshold
Account lockout duration
Reset account lockout counter after
Group Policy Management (gpmc.msc):
For domain accounts, configure the same settings in a Group Policy Object (GPO) linked to the domain or OU containing the users.
Command-line tools:
- net accounts – displays current account lockout policy settings for the local machine.
- net user <username> /domain – shows account properties including Account active, Account expires, Password last set, Password expires, User may change password, Workstations allowed, Logon script, User profile, Home directory, Last logon, Logon hours allowed, Local Group Memberships, Global Group memberships. It also shows if the account is locked: Account locked will be Yes or No.
- net user <username> /ACTIVE:YES – unlocks a locked account (if the lockout is due to account disabled, this won't help; for lockout, use net user <username> /ACTIVE:YES after unlocking via other means). Actually, net user with /ACTIVE:YES enables a disabled account, not a locked one. To unlock an account locked due to lockout policy, use:
- net user <username> /DOMAIN to check status.
- net user <username> /ACTIVE:YES does NOT unlock a locked account; it only enables an account that is disabled. The correct command to unlock is net user <username> /LOCKOUT:NO or net user <username> /ACTIVE:YES is not correct. Actually, in Windows, there is no direct command to unlock a locked account via net user with a lockout flag. The proper method is:
Use Active Directory Users and Computers: right-click user > Properties > Account tab > Unlock account.
Or use PowerShell: Unlock-ADAccount -Identity <username>.
Or use dsmod user <DN> -disabled no but this also enables disabled accounts.
The exam may test that you can unlock an account using the GUI or PowerShell, and that net user can display lockout status but not directly unlock.
Event Viewer:
Failed logon attempts generate Event ID 4625 (Logon Failure). Account lockout events generate Event ID 4740 (A user account was locked out). These are logged on the domain controller (for domain accounts) or local machine (for local accounts).
Interaction with Related Technologies
Account lockout policies interact with:
Password policies: Password complexity and history policies don't directly affect lockout, but they influence password strength, which reduces the likelihood of successful brute-force attacks.
Smart card authentication: Smart card logon uses a PIN. Failed PIN attempts can also trigger account lockout if the PIN is tied to the user's password (common in some configurations). However, many smart card implementations use a separate lockout for the PIN.
Biometric authentication: Windows Hello for Business uses a PIN or biometric. Failed attempts may lock the local credential manager but not the domain account.
Remote Desktop Services: Failed RDP logon attempts count toward the lockout threshold. A common support issue is users being locked out due to many failed RDP attempts from multiple workstations.
Service accounts: Service accounts often have passwords that are not frequently changed. If a service account is locked out, critical services may fail. Administrators should exclude service accounts from lockout policies or set high thresholds.
Common Misconfigurations
Setting lockout threshold too low: Users get locked out frequently, increasing help desk calls.
Setting lockout duration too short: Attackers can wait out the lockout and continue guessing.
Not setting reset counter: If reset counter is not set (or set too long), a user who makes a few failed attempts over several days may eventually hit the threshold.
Replication delay: In multi-DC environments, a user may be locked out on one DC but not another, causing inconsistent behavior until replication completes.
Exam-Specific Details
The 220-1102 exam expects you to know:
Default lockout threshold is 0 (disabled).
Default suggested lockout duration is 30 minutes.
Default suggested reset counter is 30 minutes.
The three settings: threshold, duration, reset counter.
How to configure via Local Security Policy and Group Policy.
How to unlock an account using ADUC or PowerShell.
The Event IDs: 4625 (failed logon), 4740 (account locked out).
That lockout applies per user account, not per workstation.
That failed logon attempts are tracked per domain controller, and replication latency can cause issues.
User Attempts Logon
The user enters their username and password at the logon screen (Ctrl+Alt+Del). The credentials are passed to the Local Security Authority (LSA) on the client machine. For domain accounts, the client sends an authentication request to a domain controller (DC) using Kerberos or NTLM. The DC receives the request and looks up the user account in Active Directory.
Password Verification
The DC hashes the entered password and compares it to the stored hash (NTLM hash or Kerberos key). If the hashes match, authentication succeeds. If they don't, the DC increments the `badPwdCount` attribute for that user account. The `badPwdCount` is stored on the DC that processed the authentication. The DC also logs Event ID 4625 in the Security log, recording the username, workstation, and failure reason.
Threshold Check
After incrementing `badPwdCount`, the DC checks if the new value equals or exceeds the configured `account lockout threshold`. If the threshold is 0 (default), no lockout occurs regardless of failures. If threshold is set (e.g., 5), and `badPwdCount` reaches 5, the DC sets the `LOCKOUT` flag in the `userAccountControl` attribute. The account is now locked. The DC logs Event ID 4740.
Account Lockout
The locked account cannot authenticate, even with the correct password. Any subsequent logon attempt returns error `STATUS_ACCOUNT_LOCKED_OUT`. The client displays a message: "The referenced account is currently locked out and may not be logged on to." The lockout duration timer starts at the moment the account is locked. The account remains locked until the timer expires or an administrator manually unlocks it.
Automatic Unlock or Admin Intervention
When the lockout duration expires, the DC automatically clears the `LOCKOUT` flag and resets `badPwdCount` to 0. Alternatively, an administrator can unlock the account early using Active Directory Users and Computers (right-click user > Properties > Account tab > Unlock account) or PowerShell (`Unlock-ADAccount -Identity <username>`). The admin can also reset the password, which clears the lockout status. After unlock, the user can log on with the correct password.
In a large enterprise with 10,000+ users, account lockout policies are critical for security but require careful tuning. A common scenario: the security team sets a lockout threshold of 3 attempts with a 15-minute duration. However, users often have multiple devices (laptop, phone, VDI) and may accidentally trigger lockouts by typing wrong passwords repeatedly. The help desk receives hundreds of unlock requests daily. To mitigate, the organization implements a self-service password reset (SSPR) solution that allows users to unlock their accounts by answering security questions or using multi-factor authentication. The lockout policy is adjusted: threshold raised to 5, duration remains 15 minutes, reset counter set to 30 minutes. This balances security and usability.
Another scenario: a domain controller in a remote site with slow WAN link. When a user fails logon, the badPwdCount is updated on that DC. If the user then connects to a different site, the other DC may not have the updated count yet (replication latency). This can cause the user to exceed the threshold on one DC but not another, leading to intermittent lockouts. The solution is to ensure all DCs are in the same site or increase replication frequency. Also, some organizations set a higher threshold to reduce false positives.
A third scenario: service accounts for automated tasks. These accounts often have long, complex passwords that rarely change. If a service account is locked out due to a misconfigured application that repeatedly tries a wrong password, critical services stop. Best practice is to exclude service accounts from lockout policies by placing them in a separate OU with a different GPO that has a very high threshold (e.g., 100) or no lockout. Alternatively, use managed service accounts (gMSA) which automatically rotate passwords and are less prone to lockout.
Common misconfiguration: setting the lockout duration too short (e.g., 1 minute) to reduce help desk calls. This defeats the purpose because an attacker can wait 1 minute and continue guessing. The recommended minimum duration is 15 minutes. Another misconfiguration: not setting the reset counter, so failed attempts accumulate indefinitely, eventually locking out users who have occasional typos over weeks. Always set the reset counter to a reasonable value (e.g., 30 minutes).
The 220-1102 exam (Objective 2.2) tests your understanding of account lockout policies as part of Windows security settings. You must know the three policy settings: account lockout threshold, account lockout duration, and reset account lockout counter after. The default threshold is 0 (disabled). The exam often asks: 'What is the default account lockout threshold in Windows?' Answer: 0 (meaning no lockout).
Common wrong answers: Candidates choose '3 attempts' because many organizations set it to 3, but the default is 0. Another trap: 'Account lockout duration defaults to 30 minutes.' Actually, it's undefined until threshold is set. The suggested default is 30 minutes, but the actual default is 'Not defined.' The exam may phrase it as: 'What is the default value for account lockout duration?' Correct answer: 'Not defined' or '0 minutes.'
Another frequent question: 'What Event ID is logged when an account is locked out?' Answer: 4740. Candidates may confuse with 4625 (failed logon) or 4776 (credential validation). Know the numbers.
Edge cases: The exam may present a scenario where a user is locked out but can still access network resources. This is possible if the user has cached credentials from a previous successful logon. The lockout only prevents new authentication; existing sessions remain active until the ticket expires. Also, a locked account can still receive email if the mail client uses cached credentials.
Another edge case: The reset counter timer resets after each failed attempt. For example, if threshold=5, reset after=30 minutes, user fails 3 times at 9:00, then 2 times at 9:20, the counter is at 5? Actually, the counter resets after 30 minutes of no failed attempts. If the user fails at 9:00, 9:05, 9:10 (3 attempts), then waits until 9:35 (25 minutes later) and fails again, the counter is now 4? No, because the reset counter is 30 minutes, but the timer restarts after each attempt. So after the 3rd attempt at 9:10, the counter will reset to 0 at 9:40 if no further attempts. At 9:35, the counter is still 3, so the 4th attempt at 9:35 brings it to 4. At 9:40, if no more attempts, counter resets to 0. This is a common point of confusion.
To eliminate wrong answers, focus on the mechanism: lockout is per user, not per workstation; the counter is per DC; lockout duration starts at lockout time; reset counter is the time after which the counter resets if no new failures occur.
Account lockout threshold default is 0 (disabled).
Account lockout duration and reset counter are undefined until threshold is set; suggested default is 30 minutes.
Lockout is per user account, not per workstation.
Failed logon attempts are tracked per domain controller; replication latency can cause inconsistent lockout status.
Event ID 4740 is logged when an account is locked out; Event ID 4625 for failed logon.
Unlock an account using ADUC (Unlock account checkbox) or PowerShell Unlock-ADAccount.
A locked account can still use existing sessions with cached credentials until they expire.
These come up on the exam all the time. Here's how to tell them apart.
Local Security Policy
Applies to local machine only
Configured via secpol.msc
Used for standalone workgroups or local accounts
No replication; immediate effect
Limited to one computer at a time
Group Policy
Applies to all computers/users in a domain or OU
Configured via GPMC.msc or Group Policy Editor
Used for domain-joined computers
Replicates across domain controllers; may have latency
Centralized management for many computers
Mistake
Account lockout policies apply per workstation.
Correct
Lockout policies apply per user account, not per workstation. If a user is locked out, they cannot log on from any device. The failed attempt counter is stored in Active Directory for domain accounts, so failures from any workstation count toward the same threshold.
Mistake
The default account lockout threshold is 3 attempts.
Correct
The default threshold is 0 (disabled). Many organizations configure a threshold of 3-5, but the out-of-box default is no lockout. The exam tests the default value, not the common configuration.
Mistake
Account lockout duration defaults to 30 minutes.
Correct
The lockout duration is undefined until a threshold is set. When you set a threshold, Windows suggests a default of 30 minutes, but the actual default is 'Not defined' (0 minutes). If you set threshold without setting duration, the account will remain locked until an administrator unlocks it.
Mistake
A locked account cannot access any network resources.
Correct
A locked account cannot perform new authentication, but existing sessions with cached credentials or Kerberos tickets continue until they expire. For example, a user with an open Outlook session can still read email because the session was established before the lockout.
Mistake
Resetting the password automatically unlocks a locked account.
Correct
Resetting the password does not automatically unlock a locked account. The lockout flag must be cleared separately. However, some tools (like Active Directory Users and Computers) allow you to reset password and unlock in one operation, but the two actions are distinct. The exam may test that unlocking requires a separate step.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default account lockout threshold in Windows 10 is 0, meaning account lockout is disabled. This is a common exam question. Many candidates mistakenly think it's 3 because that's a common configuration, but the default is no lockout.
You can unlock a locked domain user account using Active Directory Users and Computers (ADUC): right-click the user, go to Properties, Account tab, and uncheck 'Account is locked out'. Alternatively, use PowerShell: `Unlock-ADAccount -Identity <username>`. The `net user` command can display lockout status but cannot unlock; `net user <username> /ACTIVE:YES` only enables a disabled account, not unlock a locked one.
Event ID 4740 is logged on the domain controller when a user account is locked out. This is important for auditing and troubleshooting. Event ID 4625 is for failed logon attempts. The exam may ask you to differentiate between these IDs.
Yes, a user can still access network resources if they have an existing authenticated session. For example, if they are already logged on and have a valid Kerberos ticket, they can continue to access file shares or email until the ticket expires. However, they cannot perform new authentications, such as logging on to another computer.
Lockout duration is the time the account remains locked after reaching the threshold. Reset counter is the time after a failed attempt that the counter resets to 0 if no further failures occur. For example, if threshold=5, duration=30 min, reset=15 min: after 3 failed attempts, if the user waits 16 minutes, the counter resets to 0. If they fail again after 10 minutes, the counter stays at 3+1=4.
Each domain controller maintains its own copy of the `badPwdCount` attribute. When a user fails logon, the DC that processed the request increments its local copy. Replication updates other DCs. If replication is slow, a user might be locked out on one DC but not another. This can cause intermittent lockout issues. Best practice is to have all DCs in the same site or use fine-grained password policies.
There is no single recommended value; it depends on the organization's security vs. usability balance. Common values are 5-10 attempts. The exam does not test a specific recommended value but expects you to know that the default is 0 and that a lower threshold increases security but may increase help desk calls.
You've just covered Account Lockout Policies — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?