Account Lockout
Index
- Overview
- Password Policies
- Account Lockout Policies
- Enable Logs on domain controllers
- How to keep all event log records and avoid event log overwrites?
- Collecting Account Lockout Event Log
- Enable Net logon Log.
- Backup Netlogon Log
- Troubleshooting Account Lockout
- Common causes for Account Lockouts
- Useful tools
Overview
This article examines
the advantages and disadvantages from a security standpoint of implementing
account lockout on a network running Active Directory. Account lockout is a
feature of password security in Windows 2000 and later that lock a user account
when a certain number of failed logons occur due to wrong passwords within a
certain interval of time. The purpose behind account lockout is to prevent
attackers from brute-force attempts to guess a user's password--too many bad
guess and you're locked out.
To configure Password
Policies and account lockout Policies in a domain environment we typically use
the Default Domain Policy, a Group Policy Object (GPO) linked to the
domain.
To find the password policy settings, which are under the Account Policy, open up the following path of policy folders: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies. Once there, you'll find three policy folders:
Password Policy
Account Lockout Policy
Kerberos Policy
The default settings for the policies are below.
Password Policy
To find the password policy settings, which are under the Account Policy, open up the following path of policy folders: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies. Once there, you'll find three policy folders:
Password Policy
Account Lockout Policy
Kerberos Policy
The default settings for the policies are below.
Password Policy
|
Policy Setting
|
Default Setting Value
|
|
Enforce password history
|
24 days
|
|
Maximum password age
|
42 days
|
|
Minimum password age
|
1 day
|
|
Minimum password length
|
7
|
|
Password must meet complexity requirements
|
Enabled
|
|
Store passwords using reversible encryption
|
Disabled
|
Account Lockout Policy
|
Account lockout duration
|
Not defined
|
|
Account lockout threshold
|
0
|
|
Reset account lockout counter after
|
Not defined
|
Kerberos Policy
|
Enforce user logon restrictions
|
Enabled
|
|
Maximum lifetime for service ticket
|
600 minutes
|
|
Maximum lifetime for user ticket
|
10 days
|
|
Maximum lifetime for user ticket renewal
|
7 hours
|
|
Maximum tolerance for computer clock
synchronization
|
5 minutes
|
The main account
lockout policies and their definitions are below.
|
Account
lockout duration
|
How
long (in minutes) a locked-out account remains locked-out (range is 1 to
99,999 minutes).
|
|
Account
lockout threshold
|
·
How many failed logons it will take until the
account becomes locked-out (range is 1 to 999 logon attempts).
|
|
Reset
account lockout counter after
|
·
How long (in minutes) it takes after a failed
logon attempt before the counter tracking failed logons is reset to zero
(range is 1 to 99,999 minutes).
|
A few special cases are:
|
Account
lockout duration
|
0
means once locked-out the account stays locked-out until an administrator
unlocks it
|
|
Account
lockout threshold
|
0
means the account will never be locked out no matter how many failed logons
occur
|
Handling account lockout issues are
quiet crucial, if we have sufficient log to determine the bad password source
then fine, if we do not have proper log systems in place, then it would be hard
to identify the source. The key component for troubleshooting Account Lockout
its Log (Event Log, Net Logon etc…)
How to enable account lockout
events in domain
Open Group Policy Management Console by
running the command gpmc.msc
Expand the domain
node, expand the Domain Controllers OU,
then Right-click on the Default
Domain Controllers Policy, and click the Edit option.
Expand the Computer Configuration node; go to
the node Audit Policy (Computer
Configuration->Policies->Windows Settings->Security Settings->Local
Policies->Audit Policy)
Navigate to the right
side pane, select the policy Audit
account management, and set the success audit
value.
Enable log system via command Auditpol
Auditpol.exe is
the command line utility tool to change Audit Security settings as category and
sub-category level. It is available by default Windows 2008 R2 and
later versions/Windows 7 and later versions.
By using Auditpol, we can get/set Audit Security settings per user level and computer level.
Note: You should run Auditpol command with elevated privilege (Run As Administrator);
You can enable Active Directory Account Lockout audit event (Event ID 4740) through User Account Management subcategory by using the following command
Auditpol /set /subcategory:"User Account Management" /success:enable
By using Auditpol, we can get/set Audit Security settings per user level and computer level.
Note: You should run Auditpol command with elevated privilege (Run As Administrator);
You can enable Active Directory Account Lockout audit event (Event ID 4740) through User Account Management subcategory by using the following command
Auditpol /set /subcategory:"User Account Management" /success:enable
The below Event Log
will help us to Identify the Bad password source
Event ID 529: Unknown user name or bad
password
Event ID 644: User account locked out
Event ID 675: Pre-authentication failed
Event ID 676: Authentication Ticket
Request Failed
Event ID 681: Logon failed. There error
code was:
Note:
If we want to know the corresponding event id for windows 2008 and above
add 4096 from the original 2003 event value (644 + 4096 = 4740).
Although we enabled
monitoring systems to capture the event log for directory service account
management, due to default size limitation from domain controller’s event logs,
the log will overwrite over period time.
The default Security
Event Log size for 2000 server and above 100MB we can extend the log size
maximum of 4GB, although the Event Viewer UI in Windows Server 2003 lets you
set the maximum size of an event log as 4 GB, in actual fact you should
generally never exceed 300 MB for this setting. There are several reasons for
this recommendation. First, Event Viewer wasn't designed to scale well for very
large event log sizes. And second, setting the maximum size too large could
lead to missing events or even corruption of the event log.
How
to keep all event log records and avoid event log overwrites?
SOLUTION: Enable automatic
archiving of event logs. Automatic backup of Security logs can be enabled in
the system as follows:
Go to
HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security, value set the
"AutoBackupLogFiles" (DWORD) value to 1 and set the
"Retention" (DWORD) value to 0xFFFFFFFF (do not overwrite)
Once event log reaches the maximum file size 100MB, the file
will Archive automatically to the below location in Domain controllers.
Collecting
Account Lockout Event Log
We all know the limitations of Security
event log and how to archive the event log, but how to handle the event log
effectively. To identify the account lockout source, most important event id it’s
644 - Account Lockout for 2008 and above its 4740, as soon as the account
reached maximum number of bad password attempt, the respective domain
controller will send the bad password quires to PDC master and PDC master will
lock the account, and create the 4740 event log in security.
Hence I made script to
capture the 4740 event log remotely by using LogParser (LogParser is the
fantastic MS tool to capture the log live server and manipulate offline
captured logs).
The script that I have
written below to achieve.
Copy to notepad and
save it bat and run every 30mins once to capture exclusive account lockout
event 4740.
==============================================================
set local
REM Preparing Timestamp Information
set year=%date:~6,4%
set month=%date:~3,2%
set day=%date:~0,2%
set hour=%time:~0,2%
:replace leading space with 0 for hours < 10
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set minute=%time:~3,2%
set seconds=%time:~6,2%
set timestamp=C:\AccountLockout\AL-%day%-%month%-%year%-%hour%-%minute%-%seconds%.csv
Rem set infodata=%time:~0,2%-%time:~3,2%-%time:~6,2%-%date:~-4,4%%date:~-10,2%%date:~-7,2%.csv
C:\AccountLockout\LogParser.exe -i:evt "SELECT TimeGenerated, SourceName, EventCategoryName, Message INTO %timestamp% FROM \\PDCName\Security WHERE EventID = 4740" -resolveSIDs:ON
REM Preparing Timestamp Information
set year=%date:~6,4%
set month=%date:~3,2%
set day=%date:~0,2%
set hour=%time:~0,2%
:replace leading space with 0 for hours < 10
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set minute=%time:~3,2%
set seconds=%time:~6,2%
set timestamp=C:\AccountLockout\AL-%day%-%month%-%year%-%hour%-%minute%-%seconds%.csv
Rem set infodata=%time:~0,2%-%time:~3,2%-%time:~6,2%-%date:~-4,4%%date:~-10,2%%date:~-7,2%.csv
C:\AccountLockout\LogParser.exe -i:evt "SELECT TimeGenerated, SourceName, EventCategoryName, Message INTO %timestamp% FROM \\PDCName\Security WHERE EventID = 4740" -resolveSIDs:ON
Enable Net logon Log.
Although we have 4740 event log to identify the source of bad password, few conditions the regular event log will not help us to track the source of bad password. Hence we might require Additional logs, Netlogon service in Windows in order to monitor or troubleshoot authentication, DC locator, account lockout, or other domain communication-related issues.
Although we have 4740 event log to identify the source of bad password, few conditions the regular event log will not help us to track the source of bad password. Hence we might require Additional logs, Netlogon service in Windows in order to monitor or troubleshoot authentication, DC locator, account lockout, or other domain communication-related issues.
How do I enable verbose Netlogon
logging?
To enable Netlogon
logging, run the following command (w/o quotes): “nltest /DBFlag:0x2080FFFF”
To disable Netlogon
logging, run the following command (w/o quotes): “nltest /DBFlag:0x0”
Setting
the maximum log file size for Netlogon logs:
The MaximumLogFileSize registry entry can be used to specify the maximum size of the Netlogon.log file. By default, this registry entry does not exist, and the default maximum size of the Netlogon.log file is 20 MB. When the file reaches 20 MB, it's renamed to Netlogon.bak, and a new Netlogon.log file is created.
If issue is intermittent, or spans longer intervals, we may wish to increase the maximum log file size for the Netlogon.log and Netlogon.bak file to help ensure pertinent data is not overwritten.
This registry entry has the following parameters:
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Value Name: MaximumLogFileSize
Value Type: REG_DWORD
Value Data: <maximum log file size in bytes> increased up to 4GB (4294967295 bytes) at its maximum
Remember that the total disk space that's used by Netlogon logging is the size that's specified in the maximum log file size times two (2). This is required to accommodate space for the Netlogon.log and Netlogon.bak file. For example, a setting of 50 MB can require 100 MB of disk space. This provides 50 MB for Netlogon.log and 50 MB for Netlogon.bak. Windows Server 2003 and later versions of the operating system, you can use the following policy setting to configure the log file size (value is set in bytes):
\Computer Configuration\Administrative Templates\System\Net Logon\Maximum Log File Size
The MaximumLogFileSize registry entry can be used to specify the maximum size of the Netlogon.log file. By default, this registry entry does not exist, and the default maximum size of the Netlogon.log file is 20 MB. When the file reaches 20 MB, it's renamed to Netlogon.bak, and a new Netlogon.log file is created.
If issue is intermittent, or spans longer intervals, we may wish to increase the maximum log file size for the Netlogon.log and Netlogon.bak file to help ensure pertinent data is not overwritten.
This registry entry has the following parameters:
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Value Name: MaximumLogFileSize
Value Type: REG_DWORD
Value Data: <maximum log file size in bytes> increased up to 4GB (4294967295 bytes) at its maximum
Remember that the total disk space that's used by Netlogon logging is the size that's specified in the maximum log file size times two (2). This is required to accommodate space for the Netlogon.log and Netlogon.bak file. For example, a setting of 50 MB can require 100 MB of disk space. This provides 50 MB for Netlogon.log and 50 MB for Netlogon.bak. Windows Server 2003 and later versions of the operating system, you can use the following policy setting to configure the log file size (value is set in bytes):
\Computer Configuration\Administrative Templates\System\Net Logon\Maximum Log File Size
Backup Netlogon Log
Though we have options to increase the Netlogon file, on busy domain environment the log will overwrite over period of time. Hence I have created the below bat files to move the files into centralized location.
Copy the below script to notepad and save to bat.
Though we have options to increase the Netlogon file, on busy domain environment the log will overwrite over period of time. Hence I have created the below bat files to move the files into centralized location.
Copy the below script to notepad and save to bat.
@echo off
REM set curr_date=%time:~0,2%-%time:~3,2%-%time:~6,2%-%date:~-7,2%-%date:~-10,2%-%date:~-4,4%
set local
REM Preparing Timestamp Information
set year=%date:~6,4%
set month=%date:~3,2%
set day=%date:~0,2%
set hour=%time:~0,2%
:replace leading space with 0 for hours < 10
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set minute=%time:~3,2%
set seconds=%time:~6,2%
set curr_date=%day%-%month%-%year%-%hour%-%minute%-%seconds%
MOVE \\ServerName\C$\Windows\debug\netlogon.bak C:\AccountLockout\Netlogon\ServerName\%curr_date%_netlog.bak
MOVE \\ServerName\C$\Windows\debug\netlogon.bak C:\AccountLockout\Netlogon\ServerName\%curr_date%_netlog.bak
REM set curr_date=%time:~0,2%-%time:~3,2%-%time:~6,2%-%date:~-7,2%-%date:~-10,2%-%date:~-4,4%
set local
REM Preparing Timestamp Information
set year=%date:~6,4%
set month=%date:~3,2%
set day=%date:~0,2%
set hour=%time:~0,2%
:replace leading space with 0 for hours < 10
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set minute=%time:~3,2%
set seconds=%time:~6,2%
set curr_date=%day%-%month%-%year%-%hour%-%minute%-%seconds%
MOVE \\ServerName\C$\Windows\debug\netlogon.bak C:\AccountLockout\Netlogon\ServerName\%curr_date%_netlog.bak
MOVE \\ServerName\C$\Windows\debug\netlogon.bak C:\AccountLockout\Netlogon\ServerName\%curr_date%_netlog.bak
From the above summary, we learn some basic concepts how to enable directory service account event
logs, Netlogon log and
how to move them into centralized locations to handle the log effectively.
Now we will see how to manipulate them for our day to day operations.
Check User Account Status in Active Directory
Check the TimeStamp of the last bad password supply from Account Lockout Tool
Filter
4740 on PDC Master Security Event and check if problematic user appear to be in
the list
If
user does not exist on PDC, check the relevant timestamp from the backup and
identify the source of bad password.
If
user is WIFI or VDI user, check Netloglog file to identify the exact bad
password source (event log will not provide the exact source for WIFI or VDI)
Match
last bad password time stamp from PDC
Server
ABC time is matching with PDC hence selects the relevant time stamp for PDCMaster,
Use nlparse tool to extract the bad password source.
The
extraction will provide output like below.
Open
the CSV file into Notepad and find user name.
==============================================================================
$Username = "UserAccountNAme" # Replace with the actual username
$PDC = (Get-ADDomain).PDCEmulator # Find the PDC Emulator, where lockouts are typically logged
Get-WinEvent -ComputerName $PDC -FilterHashtable @{LogName = 'Security'; ID = 4740} |
Where-Object { $_.Properties[0].Value -eq $Username } |
Select-Object TimeCreated, @{Name='LockedAccount'; Expression={$_.Properties[0].Value}}, @{Name='CallerComputerName'; Expression={$_.Properties[1].Value}} |
Format-Table -AutoSize
=====================================================================
Common
causes for Account Lockouts
§
Stale Sessions: a
user may be logged on to more than one computer; those other logons may be
using old credentials that are cached and being used by some applications.
§
Applications: numerous applications either cache the
users credentials or have credentials explicitly defined in their
configuration.
§
Windows
Services: Windows services
by default are configured to start using the local system account, however,
windows services can be configured to use a specific account, typically
referred to as service accounts.
§
Scheduled Tasks: the
windows task scheduler requires credentials for any task that is configured to
run whether or not a user is logged on to the computer, specific tasks may be
configured to use domain credentials.
§
Persistent drive
mapping: drive mappings
can be configured to use alternate credentials to connect to a shared resource.
§
Stored usernames
and passwords: windows can
store username and passwords for remote resources, these credentials can be
viewed in the credential manager control panel applet.
§
Mobile Devices: mobile devices can have stored
credentials for accessing remote resources such as email.
For the majority
of situations after identifying the source of the account lockout, identifying
and resolving the actually cause is a simple process of elimination.
Useful
tools
There are a
number of tools that can be used to assist in troubleshooting account lockouts,
especially in circumstances where the cause can’t easily be identified.
§
Account Lockout
Status: The Account Lockout Status tool is a
combination command-line and graphical tool that displays lockout information
about a particular user account. It collects information from every contactable
domain controller in the target user account’s domain.
§
Account Lockout
and Management Tools: ALTools.exe contains tools that assist
you in managing accounts and in troubleshooting account lockouts.
§
Process Monitor: Process Monitor
is an advanced monitoring tool for Windows that shows real-time file system,
Registry and process/thread activity.
§ Microsoft
Message Analyzer: Message
Analyzer enables you to capture, display, and analyze protocol messaging
traffic; and to trace and assess system events and other messages from Windows
components.
