Account Lockout Policies and Troubleshooting

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.

Password Policies

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

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

Account Lockout Policies

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

Enable Logs on domain controllers

 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

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

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.

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

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.

@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

Troubleshooting Account Lockout

    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.

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.