0x17: Kerberos Failure KDC_ERR_KEY_EXPIRED — Expired Password

What it means

Failure code 0x17, KDC_ERR_KEY_EXPIRED, appears in Microsoft’s table for event 4771 as “Password has expired—change password to reset”, with the possible cause given as “The user’s password has expired.” The KDC located the principal and refused to issue a ticket because the long-term key derived from that account’s password is past its expiry date. The account is not deleted, not disabled and not locked — it simply cannot obtain tickets until the password is changed.

Microsoft’s documentation for both 4768 and 4771 states that “This event generates only on domain controllers”, so collect these events from every DC, not from member servers. The fields that drive triage are Account Name (TargetUserName), Client Address (IpAddress) — which Microsoft describes as the “IP address of the computer from which the TGT request was received” and which arrives as an IPv6 address, as ::ffff:IPv4_address, or as ::1 for localhost — plus ServiceName (normally krbtgt/DOMAIN), IpPort, and the DC name in Computer. Strip the ::ffff: prefix before matching the address against your IPv4 inventory.

One caution: 0x17 describes the state of the account’s key, not the outcome of checking what the client sent. Do not report it as confirmation that the requester knew the current password. If you need that judgement, look at what else the same account and client address produced — a run of 0x18 means someone was guessing.

Is it an attack?

Pattern	Reading
A handful of 0x17 for one user, then a 4768 with Result Code 0x0 from the same workstation	Normal expiry; the user changed the password and carried on
0x17 for one service or task account at a fixed interval from one or two internal hosts	A password policy expired a service credential; the service is broken, not attacked
0x17 across many accounts at the same time of day	Scheduled expiry hitting a batch of users with the same password age
0x17 for a leaver, dormant or retired service account, from an unfamiliar or external address	Someone still holds that credential — treat as an intrusion lead
0x17 mixed with bursts of 0x18 or 0x6 from one source	List-driven guessing that happened to touch an expired account
0x17 followed by 0x12 for the same account	The account also became disabled, locked or expired — check the AD object

Because the traffic goes to the KDC, it may never produce a 4625 on a member server. Pair the DC view with endpoint detections such as the Windows 4625 password-spray rule. On the NTLM and interactive side, the equivalent condition surfaces as Sub Status 0xC0000071 (STATUS_PASSWORD_EXPIRED) in event 4625.

How to investigate

Start with which accounts and which sources are producing the code:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID in (4768, 4771) and Status =~ "0x17"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Events = count(), Sources = dcount(ClientIp),
            SourceList = make_set(ClientIp, 20),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by TargetUserName, TargetDomainName, Computer
| order by Events desc

A single account with many events from one address over days is a stored credential; many accounts with one or two events each is routine expiry.

Next, separate expiry from guessing by checking whether the same sources also failed pre-authentication or asked for names that do not exist:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID in (4768, 4771) and Status in~ ("0x17", "0x18", "0x6")
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize KeyExpired = countif(Status =~ "0x17"),
            PreAuthFailed = countif(Status =~ "0x18"),
            NoSuchUser = countif(Status =~ "0x6"),
            Accounts = dcount(TargetUserName)
    by ClientIp, Computer
| where KeyExpired > 0
| order by Accounts desc, PreAuthFailed desc

Finally, confirm whether the account recovered — a TGT success from the same address after the last 0x17 means the password was changed and the credential works again:

let expired = SecurityEvent
    | where TimeGenerated > ago(7d) and EventID in (4768, 4771) and Status =~ "0x17"
    | extend ClientIp = replace_string(IpAddress, "::ffff:", "")
    | summarize ExpiredCount = count(), LastExpired = max(TimeGenerated) by TargetUserName, ClientIp;
SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4768 and Status =~ "0x0"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| join kind=inner expired on TargetUserName, ClientIp
| where TimeGenerated > LastExpired
| project TimeGenerated, Computer, TargetUserName, ClientIp, IpPort, ServiceName, ExpiredCount

If the source is a known internal host and the cadence is regular, find the service, task or saved credential on that machine and rotate it properly. If the account is one that should no longer authenticate, or the address is unfamiliar, keep it in the incident: identify the requesting process and review any service tickets (event 4769) from the same address. Exported Security logs can be grouped by account and client address in the free browser log analyzer.