A reachable service can still have the wrong identity
Kerberos uses a service principal name, or SPN, to identify the service for which a client requests a ticket. A working DNS lookup and an open port do not prove that this identity belongs to the account running the service. This distinction matters after service-account changes, host renames or the introduction of a friendly DNS alias.
This guide follows one failed service authentication. It does not redesign the domain or recommend weakening Kerberos controls. For beginners, separate three names on the worksheet: the name the user entered, the SPN the client requested and the account that actually runs the server process. They can disagree even when they look similar.
Setup: collect a precise request before changing directory data
Record the affected client, service hostname, port, user context and time. Confirm the actual service logon account with the application owner. Check DNS results and clock synchronization, because an identity investigation can otherwise conceal a different authentication failure.
From an authorized diagnostic session, these read-oriented commands help build the evidence:
klist
setspn -Q HTTP/app.example.test
setspn -L EXAMPLE\svc-web
The HTTP SPN and account above are illustrative values, not universal settings. Substitute the service class requested by the real client. Searches may require delegated directory permissions; a forest-wide investigation also needs an agreed scope. Keep ticket reports and directory results in the incident record rather than posting them publicly.
Illustrative incident: an alias outlives an account change
In this fictional scenario, a team moves an internal application to a dedicated service account. Users connect through the old friendly hostname. The client requests a ticket for that alias, but its SPN is still associated with the former account. Resetting users' passwords does not reconcile these two service identities.
Build a small timeline of the account change, DNS alias use and first failed request. Compare one successful access path with the failing alias using the same user. A successful login through another hostname is useful evidence, but it is not proof that the alias has been repaired.
Troubleshooting: distinguish identity lookup from ticket decryption
| Observation | Evidence to preserve | Next decision |
|---|---|---|
| KDC cannot identify the requested service | Requested SPN and directory search | Is the exact name registered where required? |
| More than one account owns the identity | Duplicate-search result and account owners | Which account legitimately runs the service? |
| Service cannot decrypt a ticket | Server events and actual process identity | Does ticket ownership match the service account? |
| Alias fails while another name works | DNS answers and client request names | Does the client build a different SPN? |
Do not classify every Kerberos error as an SPN defect. Time skew, encryption compatibility and other trust issues need their own evidence. Likewise, a fallback to another authentication method can hide the original failure; test the intended authentication path explicitly.
Correct one mapping with an owner and rollback plan
Have the directory and application owners agree the intended SPN-to-account mapping. Export the existing assignments and review other services that use the account before removing or adding anything. Use the supported account-specific procedure and duplicate-aware registration option when a change is approved.
Avoid bulk resets of account SPNs or copying the same SPN to several accounts to make one test pass. If the problem is the name requested by the client, the appropriate correction may be application or DNS configuration instead. Allow for directory replication and the lifetime of existing client tickets when planning validation.
Verification, monitoring and SOP
Retest from the original client context and requested hostname. Capture fresh authentication evidence showing the intended service identity and a successful application operation. Test a second approved client path to ensure the change did not break an existing consumer.
For monitoring, group authentication failures by requested service identity and correlate spikes with account or DNS changes. An internal SLO can track successful authentication for eligible requests; an external SLA requires separately agreed exclusions and response commitments. The SOP should name the SPN owner, collection commands, replication checks, rollback mapping and the evidence required to close the incident.
See Clouvenix windows administration for a reviewed implementation and operational handover.
Technical reference
Microsoft SPN configuration, Microsoft Kerberos troubleshooting. Reviewed 19 October 2026; use documentation for the installed product and release.