| Previous | Next |
| STATUS_SMARTCARD_SUBSYSTEM_FAILURE | STATUS_HOST_DOWN |
STATUS_NO_KERB_KEY
A service can exist and have an SPN while still lacking usable Kerberos key material
STATUS_NO_KERB_KEY points at the target server’s Kerberos credentials. Kerberos service tickets are protected for the target service, and Windows derives usable service keys from the account and supported encryption types. A registered SPN alone is therefore not sufficient: the account that owns the SPN must have key material compatible with the KDC, client policy, and requested encryption path.
Inventory the target SPN, owning account, account type and supported encryption configuration. Microsoft documents environments where accounts or legacy devices lack AES keys until credentials are updated, and modern Kerberos hardening can expose dependencies on RC4. Compare the encryption type of a working service ticket with the failing target instead of treating every Kerberos error as an SPN typo.
Avoid broadly enabling legacy encryption as the first fix. If the service account was migrated, restored, renamed, or changed from user to managed-service-account operation, verify that its credentials and SPN ownership are current. Password or key rotation should follow the service’s supported procedure so all nodes using the account receive consistent key material.
What to inspect
- The target SPN and the directory account that currently owns it, including duplicate-SPN checks.
- Supported encryption types and available key material for the target account, KDC, and service hosts.
- Recent service-account password rotation, migration, restore, or cluster-node changes that could leave hosts with inconsistent credentials.
References
- Microsoft: Kerberos authentication overview
- Microsoft: Detect and remediate RC4 usage in Kerberos
- Microsoft Open Specifications: Kerberos Protocol Extensions
- RFC 4120: Kerberos V5
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.