Tag: Event Viewer

The Event Viewer is a built-in Microsoft Windows application used to view and analyse event logs on a Windows system. It records significant system events, such as system errors, warnings, informational events, and security-related events. These events are categorized into different logs such as Application, Security, Setup, System, and custom logs.

When an account is locked out due to multiple failed login attempts, an event with Event ID 4740 (account lockout events) is logged in the Security log. This event provides information about the locked-out account, the source of the lockout (e.g., the username responsible for the lockout and the source IP address), and additional details about the lockout event.

Remote Event Viewer Account Lockout Script

This PowerShell script leverages the Get-WinEvent cmdlet to retrieve events from the Security log on a remote server, filters for events with Event ID 4740, and extracts relevant information such as event time, account name, locked by, source IP, and reason from each event to help administrators investigate and troubleshoot account lockout issues remotely.

Make sure to replace "REMOTE_SERVER_NAME" with the name of your remote server and "USERNAME" with the username you want to search for.

# Define the remote server name
$remoteServer = "REMOTE_SERVER_NAME"

# Define the username to search for
$username = "USERNAME"

# Define the Event ID for Account Lockout
$eventID = 4740

# Connect to the remote server and filter events based on username
$events = Get-WinEvent -ComputerName $remoteServer -FilterHashtable @{LogName='Security'; ID=$eventID; Data=$username} -ErrorAction SilentlyContinue

if ($events) {
    foreach ($event in $events) {
        $eventXML = [xml]$event.ToXml()
        $eventTime = $event.TimeCreated
        $accountName = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
        $lockedBy = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text'
        $sourceIP = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select-Object -ExpandProperty '#text'

        Write-Host "Event Time: $eventTime"
        Write-Host "Account Name: $accountName"
        Write-Host "Locked By: $lockedBy"
        Write-Host "Source IP: $sourceIP"
        Write-Host "Reason: $($event.Message)"
        Write-Host "---------------------------------------------"
    }
} else {
    Write-Host "No account lockout events found for $username on $remoteServer."
}

When running a script remotely, several considerations need to be taken into account to ensure it functions correctly

1. Permissions: Ensure that the user account running the script has the necessary permissions to access the remote server and read the event logs. It should have appropriate permissions both on the remote server and in the network environment.
2. Firewall Settings: Check the firewall settings on both the local and remote machines to allow PowerShell remoting and the necessary network traffic for remote access. Windows Firewall rules or any other firewall software should permit the required traffic.
3. WinRM Configuration: Windows Remote Management (WinRM) must be enabled and properly configured on both the local and remote machines to allow PowerShell remoting. This includes ensuring that WinRM service is running and that the appropriate listeners are configured.
4. Network Connectivity: Ensure that there is proper network connectivity between the local and remote machines. Check for any network issues such as connectivity problems, routing issues, or DNS resolution problems that could prevent the script from connecting to the remote server.
5. Authentication: Verify that the authentication mechanism used for remote access (e.g., Kerberos, NTLM, or CredSSP) is properly configured and supported in your environment. Ensure that the user running the script has valid credentials for accessing the remote server.
6. Remoting Configuration: Ensure that PowerShell remoting is enabled on the remote server. You can enable it manually using the Enable-PSRemoting cmdlet or via Group Policy if applicable.
7. Execution Policy: Verify that the PowerShell execution policy on both the local and remote machines allows running scripts. If necessary, adjust the execution policy using the Set-ExecutionPolicy cmdlet.

Export Results to Notepad

You can write the results of the script to a text file using the following code:

# Define the remote server name
$remoteServer = "REMOTE_SERVER_NAME"

# Define the username to search for
$username = "USERNAME"

# Define the Event ID for Account Lockout
$eventID = 4740

# Connect to the remote server and filter events based on username
$events = Get-WinEvent -ComputerName $remoteServer -FilterHashtable @{LogName='Security'; ID=$eventID; Data=$username} -ErrorAction SilentlyContinue

if ($events) {
    # Output file path
    $outputFile = "C:\Path\To\Results.txt"
     
    foreach ($event in $events) {
        $eventXML = [xml]$event.ToXml()
        $eventTime = $event.TimeCreated
        $accountName = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
        $lockedBy = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text'
        $sourceIP = $eventXML.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'} | Select-Object -ExpandProperty '#text'
 
        # Construct output string
        $output = @"
Event Time: $eventTime
Account Name: $accountName
Locked By: $lockedBy
Source IP: $sourceIP
Reason: $($event.Message)
---------------------------------------------
"@
 
        # Append output to text file
        Add-content -Path $outputFile -Value $output
    }
} else {
    Write-Host "No account lockout events found for $username on $remoteServer."
}

By leveraging PowerShell’s capabilities, this script offers a flexible and efficient solution for investigating account lockout events across Windows environments, empowering administrators to maintain the security and integrity of their systems.