ANAVEM
Languagefr
Windows security monitoring dashboard displaying Event ID 4944 account lockout events in a SOC environment
Event ID 4944InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4944 – Microsoft-Windows-Security-Auditing: An account was locked out

Event ID 4944 indicates that a user account has been locked out due to exceeding the maximum number of failed logon attempts within the configured lockout threshold period.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 4944Microsoft-Windows-Security-Auditing 5 methods 12 min
Event Reference

What This Event Means

Event ID 4944 represents a fundamental Windows security mechanism that automatically locks user accounts when they exceed the configured failed logon attempt threshold. This event is generated by the Local Security Authority (LSA) subsystem and logged through the Microsoft-Windows-Security-Auditing provider, making it a reliable indicator of both security incidents and operational issues.

The event contains critical forensic information including the target account name, caller computer name, caller process ID, and the specific authentication package used during the failed attempts. This data proves invaluable when distinguishing between legitimate user errors and malicious authentication attempts. The timing correlation with preceding Event ID 4625 entries helps administrators reconstruct the complete authentication failure sequence.

From a security perspective, Event ID 4944 serves as an early warning system for brute-force attacks, credential stuffing attempts, and compromised account scenarios. However, it also indicates operational issues such as service accounts with expired passwords, cached credential mismatches, or users struggling with password complexity requirements. The event's appearance in high-security environments often triggers automated incident response workflows and security team notifications.

Modern Windows implementations in 2026 have enhanced this event with additional context data, including more detailed source attribution and integration with Windows Defender for Endpoint detection capabilities. This evolution makes Event ID 4944 a cornerstone event for comprehensive security monitoring strategies.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • User exceeding the maximum failed logon attempts configured in Group Policy account lockout settings
  • Brute-force password attacks targeting specific user accounts from external or internal sources
  • Service accounts with expired or changed passwords attempting automated authentication
  • Cached credentials conflicts where stored credentials no longer match current account passwords
  • Applications or scripts using hardcoded credentials that have been changed or expired
  • Network authentication issues causing legitimate logon attempts to appear as failures
  • Time synchronization problems between domain controllers and client systems affecting Kerberos authentication
  • Malware or compromised systems attempting to authenticate with stolen or guessed credentials
  • Users forgetting passwords after policy-enforced password changes or complexity updates
Resolution Methods

Troubleshooting Steps

01

Check Account Lockout Status and Unlock

First, verify the current lockout status and unlock the account if necessary:

# Check account lockout status
Get-ADUser -Identity "username" -Properties LockedOut, AccountLockoutTime, BadLogonCount

# Unlock the account
Unlock-ADAccount -Identity "username"

# Verify unlock was successful
Get-ADUser -Identity "username" -Properties LockedOut

Navigate to Event ViewerWindows LogsSecurity and filter for Event ID 4944 to see the lockout details. Check the event properties for the source computer name and timestamp to identify where the failed attempts originated.

For local accounts on standalone systems:

# Check local account status
Get-LocalUser -Name "username" | Select-Object Name, Enabled, AccountExpires, PasswordExpired

# Enable locked local account
Enable-LocalUser -Name "username"
Pro tip: Always check the BadLogonCount property to understand how many failed attempts triggered the lockout.
02

Analyze Failed Logon Patterns with PowerShell

Investigate the failed logon attempts that led to the account lockout:

# Get recent failed logon events (4625) for the locked account
$Events = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4625
    StartTime=(Get-Date).AddHours(-24)
} | Where-Object {$_.Message -like "*username*"}

# Display detailed information
$Events | ForEach-Object {
    $Event = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        SourceIP = $Event.Event.EventData.Data[19].'#text'
        WorkstationName = $Event.Event.EventData.Data[13].'#text'
        FailureReason = $Event.Event.EventData.Data[8].'#text'
        LogonType = $Event.Event.EventData.Data[10].'#text'
    }
} | Format-Table -AutoSize

Check for patterns in source IPs and workstation names to identify potential attack sources:

# Group failed attempts by source IP
$Events | Group-Object {([xml]$_.ToXml()).Event.EventData.Data[19].'#text'} | 
Sort-Object Count -Descending | Select-Object Name, Count
Warning: Multiple lockouts from different source IPs may indicate a distributed attack or compromised credentials.
03

Review Account Lockout Policy Configuration

Examine the current account lockout policy settings that triggered the lockout:

# Check domain account lockout policy
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutDuration, LockoutObservationWindow, LockoutThreshold

# For fine-grained password policies
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, LockoutDuration, LockoutThreshold, LockoutObservationWindow

Access Group Policy Management Console and navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAccount PoliciesAccount Lockout Policy to review:

  • Account lockout threshold (number of failed attempts)
  • Account lockout duration (how long accounts stay locked)
  • Reset account lockout counter after (observation window)

Check local security policy on standalone systems:

# Export current security policy
secedit /export /cfg C:\temp\secpol.cfg

# Review lockout settings in the exported file
Select-String -Path "C:\temp\secpol.cfg" -Pattern "LockoutBadCount|LockoutDuration|ResetLockoutCount"
Pro tip: Consider implementing fine-grained password policies for different user groups to balance security and usability.
04

Implement Automated Monitoring and Alerting

Set up proactive monitoring for account lockout events to catch issues early:

# Create a scheduled task to monitor lockout events
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-File C:\Scripts\LockoutMonitor.ps1"
$Trigger = New-ScheduledTaskTrigger -AtStartup
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName "AccountLockoutMonitor" -Action $Action -Trigger $Trigger -Settings $Settings

Create the monitoring script (C:\Scripts\LockoutMonitor.ps1):

# Monitor for Event ID 4944 and send alerts
$LastCheck = (Get-Date).AddMinutes(-5)
$LockoutEvents = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4944
    StartTime=$LastCheck
}

if ($LockoutEvents) {
    foreach ($Event in $LockoutEvents) {
        $EventXML = [xml]$Event.ToXml()
        $LockedAccount = $EventXML.Event.EventData.Data[0].'#text'
        $SourceWorkstation = $EventXML.Event.EventData.Data[4].'#text'
        
        # Send email alert or log to SIEM
        Write-EventLog -LogName Application -Source "LockoutMonitor" -EventId 1001 -Message "Account $LockedAccount locked from $SourceWorkstation"
    }
}

Configure Windows Event Forwarding to centralize lockout events:

winrm quickconfig
wecutil qc
Pro tip: Integrate with SIEM solutions like Microsoft Sentinel for advanced correlation and automated response capabilities.
05

Advanced Forensic Analysis and Remediation

Perform comprehensive analysis for security incidents or persistent lockout issues:

# Advanced event correlation script
$StartTime = (Get-Date).AddDays(-7)
$TargetAccount = "username"

# Collect comprehensive authentication events
$AuthEvents = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624,4625,4944,4740
    StartTime=$StartTime
} | Where-Object {$_.Message -like "*$TargetAccount*"}

# Create timeline analysis
$Timeline = $AuthEvents | ForEach-Object {
    $EventXML = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        EventID = $_.Id
        EventType = switch($_.Id) {
            4624 { "Successful Logon" }
            4625 { "Failed Logon" }
            4944 { "Account Locked" }
            4740 { "Account Locked (Legacy)" }
        }
        SourceIP = if($EventXML.Event.EventData.Data[19]) { $EventXML.Event.EventData.Data[19].'#text' } else { "N/A" }
        WorkstationName = if($EventXML.Event.EventData.Data[13]) { $EventXML.Event.EventData.Data[13].'#text' } else { "N/A" }
    }
} | Sort-Object TimeCreated

$Timeline | Export-Csv -Path "C:\temp\AuthTimeline_$TargetAccount.csv" -NoTypeInformation

Check for indicators of compromise:

# Analyze authentication patterns for anomalies
$SourceIPs = $Timeline | Where-Object {$_.SourceIP -ne "N/A"} | Group-Object SourceIP | Sort-Object Count -Descending
$UnusualHours = $Timeline | Where-Object {$_.TimeCreated.Hour -lt 6 -or $_.TimeCreated.Hour -gt 22}
$MultipleWorkstations = $Timeline | Group-Object WorkstationName | Where-Object {$_.Count -gt 10}

Implement additional security measures if compromise is suspected:

# Force password reset for compromised account
Set-ADAccountPassword -Identity $TargetAccount -Reset -NewPassword (ConvertTo-SecureString "TempPassword123!" -AsPlainText -Force)
Set-ADUser -Identity $TargetAccount -ChangePasswordAtLogon $true

# Revoke all active sessions
Get-ADUser -Identity $TargetAccount | Set-ADAccountControl -AccountNotDelegated $true
Warning: Always coordinate with security teams before implementing remediation measures that could impact ongoing investigations.

Overview

Event ID 4944 fires when Windows locks out a user account after exceeding the maximum allowed failed authentication attempts. This security event appears in the Security log and serves as a critical indicator for both legitimate lockout scenarios and potential brute-force attacks. The event captures essential details including the target account name, source workstation, and the security identifier (SID) of the locked account.

This event works in conjunction with Group Policy settings that define account lockout thresholds, duration, and reset counters. When investigating Event ID 4944, you'll typically see it preceded by multiple Event ID 4625 (failed logon) entries from the same source. The lockout mechanism protects against password guessing attacks but can also impact legitimate users who mistype passwords or have cached credentials conflicts.

Understanding this event is crucial for security monitoring, user support, and identifying potential security threats. System administrators use Event ID 4944 to track authentication patterns, configure automated alerts, and implement appropriate security responses based on the lockout frequency and source patterns.

Frequently Asked Questions

What does Event ID 4944 mean and when does it appear?+
Event ID 4944 indicates that a user account has been automatically locked out by Windows after exceeding the maximum number of failed logon attempts configured in the account lockout policy. This event appears in the Security log immediately when the lockout threshold is reached, serving as both a security protection mechanism and an indicator of potential brute-force attacks or legitimate user authentication issues.
How can I distinguish between legitimate lockouts and security attacks using Event ID 4944?+
Analyze the pattern of preceding Event ID 4625 (failed logon) events to distinguish between legitimate and malicious lockouts. Legitimate lockouts typically show failed attempts from a single workstation during business hours, often with common typos or credential caching issues. Security attacks usually exhibit rapid-fire attempts from multiple IP addresses, unusual timing patterns (off-hours), or attempts from geographically diverse locations. Check the source workstation names and IP addresses in the event details for additional context.
What should I check first when investigating an Event ID 4944 lockout?+
Start by examining the event details to identify the locked account name, source workstation, and timestamp. Then review the preceding 15-30 minutes of Event ID 4625 entries to understand the failed logon pattern. Check if the source IP or workstation name matches expected user locations and verify the account lockout policy settings to understand why the lockout occurred. Use PowerShell commands like Get-ADUser to check the current account status and BadLogonCount property.
How do I prevent frequent legitimate user lockouts while maintaining security?+
Balance security and usability by adjusting account lockout policy settings based on your environment's needs. Consider increasing the lockout threshold from 3 to 5 attempts, extending the observation window to 30-60 minutes, and reducing lockout duration to 15-30 minutes for automatic unlock. Implement user education about password policies, deploy password managers, and consider fine-grained password policies for different user groups. Monitor lockout patterns to identify common causes like cached credential conflicts or service account issues.
Can Event ID 4944 be used for automated security response and how?+
Yes, Event ID 4944 is excellent for automated security monitoring and response. Create PowerShell scripts or use SIEM solutions to monitor for multiple lockout events from the same source IP, unusual timing patterns, or high-value account lockouts. Implement automated responses such as IP blocking, security team notifications, or enhanced monitoring for affected accounts. Use Windows Event Forwarding to centralize lockout events from multiple systems and correlate with other security events for comprehensive threat detection.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...