Event ID 4771: Kerberos pre-authentication failed

Event 4771 belongs to the Audit Kerberos Authentication Service subcategory, and it only ever fires on a domain controller. That scoping matters immediately: workstations and member servers never generate this event, because they do not run the Key Distribution Center (KDC) that issues Kerberos tickets. If you are aggregating 4771 across your fleet and see it coming from a member server, check your log-source mapping before you trust the data.

The event covers exactly one moment in the Kerberos handshake: the initial AS-REQ, when a client asks the KDC for a Ticket Granting Ticket (TGT). It does not cover the second half of Kerberos authentication, the TGS-REQ for a service ticket, which is a different event entirely (4769) and a different failure surface. A 4771 tells you someone, or something, tried to get a TGT and the KDC said no.

The ServiceName field records the realm service the request targeted, almost always krbtgt/DOMAIN, since the TGT itself is a ticket for the krbtgt service, not for any application. TargetUserName and TargetSid identify the account attempting to authenticate, and IpAddress and IpPort record where the request came from. On a busy domain controller these two fields are the backbone of any 4771 detection: they tell you who tried, and from where.

PreAuthType is the field most analysts skip past, and it should not be skipped. A value of 2 means the client tried the standard encrypted-timestamp pre-authentication, the default for a password-based logon. A value of 15 means PKINIT, smart-card-based authentication, which changes your triage entirely: a 0x18 failure against a PreAuthType 15 request means a smart card or its PIN failed, not a typed password, and the two failure modes point at completely different root causes and remediation paths.

The Status field is where the real diagnostic value lives, and it is not a Windows-specific error code. It is an RFC 4120 Kerberos protocol error, the same failure-code table any Kerberos implementation uses, which is part of why 4771 reads cleanly even to analysts coming from a non-Windows Kerberos background. 0x18 (KDC_ERR_PREAUTH_FAILED) means the pre-authentication data did not validate, which in the PreAuthType 2 case almost always means a wrong password. An account name the KDC has never heard of (KDC_ERR_C_PRINCIPAL_UNKNOWN, 0x6) never reaches this event: the KDC rejects it in the AS-REQ and the failure is logged as a failed 4768, not a 4771. That is why 4771 volume understates account-name guessing. 0x17 (KDC_ERR_KEY_EXPIRED) fires when a password has expired and needs to be reset, routine noise in any environment with a password-expiry policy. 0x12 (KDC_ERR_CLIENT_REVOKED) means the account is disabled or locked, worth a second look only when the account is privileged or the attempts continue past a known offboarding date.

One evasion detail worth knowing: an account configured with "Do not require Kerberos preauthentication" never generates a 4771 for a guessing attempt against it, because the KDC skips the pre-authentication step entirely for that account and responds with an AS-REP an attacker can take offline and crack, the basis of AS-REP Roasting. If your 4771 coverage looks suspiciously clean for a given account, confirm that flag is not set rather than assuming the account is untouched.

4771 sits next to two events that give it context. A successful authentication for the same account shows up as a 4768 (TGT requested successfully) instead, on the same domain controller, around the same time, from the same IpAddress, which is your confirmation that a spray or brute-force attempt eventually landed. And a 4625 on the destination workstation, generated separately by the client-side logon path, often accompanies a Kerberos failure that fell back to NTLM, a second place to look when 4771 volume against a given account seems lower than expected.

The single most useful signal in 4771 triage is cardinality, not volume. A handful of 0x18 failures scattered through the day against a handful of accounts from recognizable corporate IP ranges is routine: users mistype passwords, cached credentials go stale after a change, and service accounts occasionally get restarted with an old secret. None of that needs an analyst's attention on its own.

Password spraying looks structurally different: many distinct TargetUserName values, all failing with 0x18, from one IpAddress, inside a tight window. The distinguishing shape is breadth, not speed. A spray tool deliberately spaces out attempts against each individual account to stay under a lockout threshold, so the volume per account stays low while the distinct-account count climbs. That is exactly why the detection queries in this page bucket by IpAddress and count distinct TargetUserName rather than counting raw event volume.

The inverse pattern, many attempts against one TargetUserName from one or more sources, is classic brute force or credential stuffing against a specific target, often a named executive or admin account an attacker has already identified as high value. Set the threshold lower for privileged accounts than for the general population: five 0x18 failures against krbtgt-adjacent or Tier-0 accounts warrants review well before the same count would for a standard user.

Account-name enumeration belongs to a different event. A burst of failed 4768 events with result code 0x6 against sequential or dictionary-pattern usernames (admin1, admin2, testuser, svc-backup) from one source is reconnaissance ahead of a targeted spray, and 4771 stays silent for names that do not exist. What 4771 adds is the next stage. Once the attacker has real usernames, the 0x18 failures land here. Watch for a run of 0x18 that ends in a successful 4768 for the same account and IpAddress, the moment a guess worked. An isolated 0x6 in 4768 is usually a mistyped username or a stale script referencing a decommissioned account, benign but worth a quick check against your account inventory if it recurs.

0x17 and 0x12 rarely warrant an alert by themselves. The one exception worth automating: 0x17, expired password, recurring from a service account rather than a human user, since service accounts are not supposed to be subject to interactive password-expiry policy, and a recurring 0x17 there usually means a credential rotation was missed, an operational risk more than a security one, but one that will eventually cause an outage if it is not fixed. Correlate any of these patterns against the destination account's normal authentication baseline, home office, typical hours, typical PreAuthType, before escalating; a single off-pattern field is common noise, but 0x18 breadth plus an unfamiliar source IP plus a privileged Target together is the combination that earns a page.