Introduction

A service migration can move an application tier or backend hostname while classic Kerberos constrained delegation still targets the old service principal name. Front-end authentication appears healthy, but delegated access to the backend fails, one server can impersonate users to the new service while another still requests tickets for the previous SPN, or access breaks only after the old backend is retired because SPN registration, allowed delegation targets, and service account settings often move unevenly.

Treat this as a classic constrained-delegation path problem instead of a generic Kerberos outage. Start by checking which SPN the front-end service actually requests during delegation, because migrations often validate direct sign-in first while hop-to-hop service authentication continues depending on the earlier backend identity. If your environment uses resource-based constrained delegation instead, troubleshoot the backend object's trust settings separately instead of assuming this article's account-level allowlist model applies unchanged.

Symptoms

  • Classic Kerberos constrained delegation still targets the old service SPN after migration
  • Users can authenticate to the front-end service, but delegated backend access fails
  • One application node uses the new service while another still requests tickets for the previous SPN
  • Access fails only after the old backend hostname or service account is removed
  • The new service is healthy, but delegated Kerberos traffic never reaches it correctly
  • The issue started after moving IIS, SQL Server, HTTP services, or other Kerberos-backed application tiers

Common Causes

  • Classic constrained delegation still allows only the old backend SPN on the front-end service or computer account
  • The new backend SPN was registered, but the front-end account's allowed delegation targets were never updated
  • Stale or duplicate SPN registration leaves the old service identity resolvable or mapped incorrectly, which causes Kerberos lookup and authentication errors after migration
  • One app pool, node, or service account was updated while another still uses the previous delegation target
  • Golden images, Group Policy, or automation keep restoring the old service account or hostname mapping
  • Validation confirmed the new backend accepted direct Kerberos auth but did not verify which SPN delegated requests actually targeted

> Note: This article is scoped to classic constrained delegation. If you use resource-based constrained delegation, the backend computer or service account trust settings are the primary place to investigate.

Step-by-Step Fix

  1. Capture one affected delegated request and record the front-end service account, target SPN, and backend host it actually uses, because the live delegation target determines where Kerberos impersonation is attempted.
  2. Compare that active delegation path with the intended post-migration service design, because one stale SPN entry can keep whole application flows tied to the retired backend identity.
  3. Review the front-end service or computer account's classic constrained delegation allowlist, the application's backend target or hostname mapping, backend SPN registration, and related service account settings for references to the old service, because Kerberos hop authentication depends on both application targeting and delegation configuration together.
  4. Check each front-end node, app pool, and service account separately if behavior differs, because migrations often fix one delegation path while another still targets the previous SPN.
  5. Update the authoritative backend SPN, the application's backend target or hostname mapping, and the front-end account's allowed delegation target list so the service requests the intended SPN and is also permitted to delegate to it, because bringing the new backend online alone does not retarget classic constrained delegation.
  6. Run a controlled end-to-end transaction and confirm the intended service SPN receives the delegated Kerberos access, because a successful front-end login does not prove the right backend identity handled the second hop.
  7. Verify the old SPN and backend no longer receive delegated requests from migrated services, because split authentication paths can remain hidden while both targets stay resolvable.
  8. Review duplicate SPNs, delegation-related account settings and flags, and time or domain trust issues if delegation still fails, because the destination can be correct while directory trust or ticketing still blocks the new path.
  9. Document which team owns SPN registration, front-end delegation allowlists, service accounts, and migration validation so future Kerberos cutovers verify the actual delegated target before retiring the previous service identity.