Event 4771 — Kerberos Pre-Authentication Failed

Introduction

Someone opens Event Viewer on a domain controller, filters the Security log to Failure Audit, and finds thousands of Event ID 4771 entries from the last hour alone. A SIEM rule built around “Kerberos pre-authentication failed” has been firing all week. The reflex is to treat every one of them as a login attack in progress, but that reflex burns out an on-call rotation fast, because a healthy domain generates 4771 events constantly as part of ordinary Kerberos chatter.

The event by itself does not tell you whether you are looking at an expired password, a locked-out service account retrying every five minutes forever, a genuine password-spray attempt, or a completely normal part of the Kerberos handshake that happens to log as a “failure.” The Failure Code field is what turns the flood into something you can triage, and that is the field most admins never open the event far enough to read.

What You’re Seeing

On the domain controller’s Security log, a typical 4771 renders with these fields — this one from a straightforward bad-password attempt:

# Security log on the DC, Event ID 4771, Task Category: Kerberos Authentication Service
A Kerberos authentication ticket (TGT) request failed.

Account Information:
    Security ID:        CORP\jdoe
    Account Name:        jdoe

Service Information:
    Service Name:        krbtgt/CORP.EXAMPLE.COM

Network Information:
    Client Address:        ::ffff:10.10.4.52
    Client Port:        49224

Additional Information:
    Ticket Options:        0x40810010
    Failure Code:        0x18
    Pre-Authentication Type:    2

A large share of the flood, though, looks like this instead — same event ID, different failure code, and this one is not actually reporting a problem:

# Same DC, same event ID, different Failure Code
Additional Information:
    Ticket Options:        0x40810010
    Failure Code:        0x19
    Pre-Authentication Type:    0

What It Actually Means

Think of pre-authentication as a bouncer checking ID before letting you queue for the ticket window. A plain Kerberos AS-REQ with no proof of identity would let anyone request a TGT for any account and start guessing the password offline against the reply. Pre-authentication closes that off: the client must first encrypt a timestamp with a key derived from the user’s password and send that along with the request. Only if the KDC can decrypt it correctly, proving the client already knows the password, does it hand over a TGT. Event 4771 is the KDC logging every time that check fails, for any of about forty distinct reasons defined in RFC 4120.

Most of the fields are straightforward: Account Name is who was trying to authenticate, Service Name is always some form of krbtgt/<REALM> because a TGT request is always addressed to the ticket-granting service itself, and Client Address/Client Port identify where the request came from — genuinely useful for spotting a source that shouldn’t be making these requests at all. The field that actually explains the failure is Failure Code, a hexadecimal value the DC copies straight out of the Kerberos protocol error it sent back to the client.

Pre-Authentication Type is worth a glance too: 2 means the client sent a normal encrypted-timestamp proof (standard password logon), 0 means the client sent no pre-authentication data at all, and 15/16/17 indicate a smart card / certificate-based exchange. A Pre-Authentication Type of 0 paired with Failure Code 0x19 is the signature of the normal two-round-trip negotiation described next — not an attack signature.

How to Diagnose

Work from the log outward. Almost everything you need to triage a 4771 flood is visible without leaving PowerShell.

# 1. Pull recent 4771 events from the Security log and see what you're actually dealing with
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4771 } -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message

# 2. Group by Failure Code to separate noise (0x19) from real problems (0x18, 0x12, 0x25...)
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4771 } -MaxEvents 500 |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        [pscustomobject]@{
            Time    = $_.TimeCreated
            Account = ($xml.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
            Client  = ($xml.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
            Status  = ($xml.Event.EventData.Data | Where-Object Name -eq 'Status').'#text'
        }
    } | Group-Object Status | Sort-Object Count -Descending

# 3. Check whether the account is disabled, locked out, or has an expired password
Get-ADUser -Identity jdoe -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, BadLogonCount |
    Select-Object Name, Enabled, LockedOut, PasswordExpired, PasswordLastSet, BadLogonCount

# 4. List every currently locked-out account in one pass, rather than checking one at a time
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut

# 5. Confirm a KDC is reachable at all - useful if failures cluster around a specific site
nltest /dsgetdc:corp.example.com /force /kdc

# 6. If Failure Code is 0x25 (clock skew), confirm the offset before chasing anything else
w32tm /stripchart /computer:DC01.corp.example.com /samples:3 /dataonly

Common Causes

Working Through a Fix

Start by separating the flood into buckets by Failure Code before you touch a single account — the script in step 2 of the diagnosis section does this in one pass. In most environments the majority of volume turns out to be 0x19 noise plus a handful of accounts repeatedly hitting 0x18 from a device nobody has re-pointed at a new password.

# Find which accounts are generating the most 0x18 (bad password) events right now
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4771 } -MaxEvents 1000 |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        $status = ($xml.Event.EventData.Data | Where-Object Name -eq 'Status').'#text'
        if ($status -eq '0x18') {
            [pscustomobject]@{
                Account = ($xml.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
                Client  = ($xml.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
            }
        }
    } | Group-Object Account, Client | Sort-Object Count -Descending | Select-Object -First 10

# Once you've identified the account, confirm current state before resetting anything
Get-ADUser -Identity jdoe -Properties LockedOut, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet

For a stale-credential case — by far the most common source of a sustained 0x18 flood — the fix is finding whatever is still submitting the old password, not the account itself. A phone with cached Wi-Fi or ActiveSync credentials, a mapped drive with saved credentials in Windows Credential Manager, a scheduled task running under a service account whose password rotated, and an old RDP or VPN session are the usual suspects, in roughly that order of frequency.

If the flood turns out to be a genuine password-spray or brute-force pattern — many distinct accounts, one Failure Code, one source address, tight timing — treat it as a security event rather than a helpdesk ticket: block the source at the firewall or conditional access layer, force resets on any account that shows a corresponding successful 4768 (meaning the guess eventually worked), and confirm your account lockout policy actually triggered where it should have.

How to Prevent It

Confirm Kerberos Authentication Service auditing is actually enabled with auditpol /get /subcategory:"Kerberos Authentication Service" — this is the audit subcategory 4771 belongs to, and it needs to be set to record failure events (the default in a modern baseline) or you get silence instead of signal. From there, tune your SIEM or log pipeline to exclude Failure Code 0x19 from volume-based alert thresholds specifically, since counting it alongside genuine failures is what makes “thousands of 4771s an hour” look alarming when most of it is protocol handshake noise.

For the codes that do matter, alert on patterns rather than single events: many accounts failing with the same code from one Client Address in a short window, or one high-value account failing repeatedly from an address it has never authenticated from before. Both are exactly the kind of thing Microsoft’s own monitoring recommendations for this event call out — tracking Client Address against an allow-list per account, and watching for Client Port values under 1024, which suggest an outbound connection from a service rather than a normal client. Pair this with the Kerberos authentication fundamentals if the pre-authentication step itself still feels opaque — this event only makes sense once you know what that step is checking for in the first place.

Quick Reference

Final Thoughts

Event 4771 looks like an incident feed at a glance, and treating every occurrence as one will exhaust anyone monitoring it within a week. It is really a TGT request log with a status code attached, and that status code is doing almost all of the useful work — the difference between a stale phone, an expired password, routine protocol chatter, and an actual attacker guessing passwords is entirely in the Failure Code field.

Read the field before reacting to the volume. Filter out 0x19, watch 0x18 and 0x6 for patterns rather than counts, and let 0x25 send you straight to the clock rather than the directory.