Event ID 4771: Kerberos Pre-Auth Failed — What the Failure Code Means

What it records

Event 4771 belongs to the Audit Kerberos Authentication Service subcategory, and Microsoft’s description of it is short: “This event generates every time the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). This problem can occur when a domain controller doesn’t have a certificate installed for smart card authentication (for example, with a “Domain Controller” or “Domain Controller Authentication” template), the user’s password has expired, or the wrong password was provided.”

Two scoping rules matter for collection. “This event generates only on domain controllers” — so the host in Computer is the DC that handled the request, not the machine the user was sitting at; that machine appears in Client Address. And the event “is not generated if “Do not require Kerberos preauthentication” option is set for the account”, so accounts with pre-authentication disabled are invisible here.

Everything else in the event supports one question: why did the KDC refuse? Security ID and the account name identify who was being authenticated (computer accounts end with $), Service Name confirms the request went to krbtgt, Client Address and Client Port give the source, Authentication Type records which pre-authentication type was used, and Failure Code carries the hexadecimal reason, taken from the error codes defined in RFC 4120.

When it matters

Read the Failure Code first. These are the ones you will meet most often, with Microsoft’s descriptions:

Code	Code name	Microsoft’s description
0x6	KDC_ERR_C_PRINCIPAL_UNKNOWN	Client not found in Kerberos database
0x10	KDC_ERR_PADATA_TYPE_NOSUPP	KDC has no support for PADATA type (pre-authentication data)
0x12	KDC_ERR_CLIENT_REVOKED	Clients credentials have been revoked
0x17	KDC_ERR_KEY_EXPIRED	Password has expired—change password to reset
0x18	KDC_ERR_PREAUTH_FAILED	Pre-authentication information was invalid
0x25	KRB_AP_ERR_SKEW	Clock skew too great

For 0x18 Microsoft gives the possible cause as “The wrong password was provided”, which makes it the Kerberos equivalent of the matching status in 4625 and 4776 — 0xC000006A. A run of 0x18 for one account from one Client Address is the brute-force shape; one Client Address producing 0x18 across many different accounts is the spraying shape, and a lockout (0xC0000234, event 4740) often follows. 0x17 and 0x12 describe the state of the account rather than a guess, and usually explain a user who cannot work rather than an attacker. For 0x10, Microsoft’s documented causes are smart card logon where “the proper certificate cannot be located”, the wrong CA being queried or unreachable, or a domain controller without a Domain Controller / Domain Controller Authentication certificate.

Microsoft’s monitoring recommendations key all of this on Security ID: watch it for high-value accounts such as domain administrators, service accounts and domain controller accounts; watch it for non-active, disabled or guest accounts “that should never be used”; watch it against an allow list; and use it with other fields to spot anomalies such as “use of an account outside of working hours”.

How to investigate

Start by ranking sources — how many distinct accounts did each client fail against?

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4771
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count(), Accounts = dcount(TargetUserName),
            AccountList = make_set(TargetUserName, 20), Codes = make_set(Status, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by ClientIp, Computer
| order by Accounts desc, Failures desc

Then isolate the wrong-password code and look at it per account, which is the brute-force view:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4771 and Status =~ "0x18"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count(), Sources = dcount(ClientIp), SourceList = make_set(ClientIp, 10),
            LastSeen = max(TimeGenerated)
    by TargetUserName, TargetSid
| where Failures > 5
| order by Failures desc

The question that changes severity is whether any of those pairs then succeeded, so join the failures to successful logons from the same source:

let preauth = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4771 and Status =~ "0x18"
    | extend ClientIp = replace_string(IpAddress, "::ffff:", "")
    | summarize FailCount = count(), LastFail = max(TimeGenerated) by TargetUserName, ClientIp;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4624
| join kind=inner preauth on TargetUserName, $left.IpAddress == $right.ClientIp
| where TimeGenerated > LastFail
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonType, FailCount, LastFail
| order by TimeGenerated asc

From there, pivot on the account and the client host: 4768 and 4769 for the rest of its Kerberos activity on the DC, 4776 for NTLM validation attempts for the same name, 4740 for a lockout, and 4723 or 4724 for a password change or reset that would explain a sudden wave of 0x18 from a service or scheduled task holding an old password. Ticket Options and the pre-authentication type live inside the event XML rather than in the SecurityEvent columns, so collect the raw event when you need them. If the failures group by source across many accounts, the Windows 4625 password-spray rule covers the same grouping on the member-server side. Without a SIEM, export the DC Security log as XML from Event Viewer and load it into the free browser log analyzer.