Kerberos Event ID 4 KRB_AP_ERR_MODIFIED: a duplicate SPN in the directory

Fix it now

The client got a service ticket and the server could not decrypt it. Microsoft’s own text says why: the password used to encrypt the ticket is not the one on the target server, commonly because the service principal name is registered on the wrong account, or because two realms hold identically named machine accounts.

setspn -Q HTTP/app.contoso.com
setspn -X -F -P
klist purge
klist purge -li 0x3e7

1. Read the event first. It names the server it was talking to and the target name it asked for – that pair is what you feed to setspn -Q.
2. setspn -Q <SPN> returns the account that holds the name. Compare it with the account the service actually runs as: if a service runs as a custom account and the name is on the computer account, that is the fault.
3. Move the registration rather than adding another: setspn -D <SPN> <wrong account>, then setspn -S <SPN> <correct account>. The -S switch checks for duplicates before it adds.
4. Purge tickets on the client and retry. Tickets are cached, so a correct directory and a stale cache look identical from the user’s chair.

Service principal names must be unique in the forest, and across trusted forests in a multi-forest environment. The exception is a service that uses the computer account and the HOST SPN.

If access works after a purge and retry, you are finished. The next section covers the cases where setspn finds nothing wrong.

Why it happens

A Kerberos service ticket is encrypted with the key of the account that owns the service principal name the client asked for. The client cannot read it; it just hands it over. The server decrypts it with its own key, and if the two accounts are not the same account, the decryption fails and the server returns KRB_AP_ERR_MODIFIED. The client writes Event ID 4, source Kerberos, into its System log, and the user sees access denied.

Microsoft’s published text names two causes in one sentence: the password used to encrypt the ticket differs from the one on the target server, and this is commonly due to identically named machine accounts in the target realm and the client realm. The second half is the one people skip. Two computers called APP01 in two domains produce this error with no duplicate SPN anywhere.

The domain controller has its own view of the same problem. KDC Event ID 11 says the KDC encountered duplicate names while processing a Kerberos authentication request, names the duplicate, and warns that it may cause authentication failures or downgrades to NTLM. That last part explains the intermittent version of this fault: some clients fall back to NTLM and work, others do not, and the difference looks like magic until you read the event.

Full reference

The codes attached to this failure, and what they are not

KRB_AP_ERR_MODIFIED is the name in the client’s event text. 0x1F is the value Microsoft’s audit failure-code tables publish as KRB_AP_ERR_BAD_INTEGRITY. They describe the same condition – a field that would not decrypt – but they are separate entries, so do not go looking for “0x1F KRB_AP_ERR_MODIFIED” in the audit tables.

Setspn switches worth knowing

Clearing tickets properly

A ticket is cached for its lifetime, so a corrected directory does not take effect until the cache turns over. klist purge clears the current user’s tickets. The computer’s own tickets live in a different logon session, and klist purge -li 0x3e7 clears those – which is the one people forget when the failing identity is a machine account rather than a user. Both are documented switches; the order is purge first, then the logon identifier.

Two neighbouring Kerberos errors that look similar

• KDC_ERR_S_PRINCIPAL_UNKNOWN: the requested SPN is not associated with any account. That is a missing registration, not a wrong one.
• KDC_ERR_PRINCIPAL_NOT_UNIQUE: the requested SPN is associated with more than one account. That is the duplicate case, seen from the KDC side.
• A clock difference produces KRB_AP_ERR_SKEW, not this event. If both the SPN and the account check out, compare the clocks before going further.
• An encryption type mismatch produces a KDC event about a missing suitable key, and it names the target account rather than reporting a decryption failure on the client.

When the service sits behind a load-balanced name

A shared or virtual name is where duplicate registrations are created deliberately and then forgotten. If several nodes each register the cluster name against their own computer account, every client that reaches a different node than the one that issued the ticket sees this error. The supported pattern is one account owning the shared name – a group managed service account or the cluster identity – with the nodes running the service under it, rather than the same name registered on every node.

Every code this article covers

Confirm the fix worked

1. setspn -Q <SPN> returns exactly one account, and it is the account the service runs as.
2. setspn -X -F reports no duplicate for that name.
3. No new KDC Event ID 11 naming that name on any domain controller.
4. After klist purge, a client reaches the service without a credential prompt.
5. No new Kerberos Event ID 4 on the client for that target name.

Questions people ask about this