| Previous | Next |
| STATUS_UNFINISHED_CONTEXT_DELETED | STATUS_OBJECTID_NOT_FOUND |
STATUS_NO_TGT_REPLY
User-to-user Kerberos needs a server TGT path that ordinary service-ticket authentication does not
STATUS_NO_TGT_REPLY belongs to Kerberos user-to-user authentication. RFC 4120 defines the ENC-TKT-IN-SKEY option: the KDC encrypts a ticket using the session key from a second ticket supplied in the TGS request. This mechanism lets a service use credentials based on its TGT instead of relying only on a long-term service key.
The Windows status indicates that negotiation selected or required this user-to-user path, but the server did not return the TGT information expected by the client. That is different from STATUS_NO_LOGON_SERVERS, where a domain logon service is unavailable, and from STATUS_KDC_INVALID_REQUEST, where the KDC rejects the constructed request itself.
Inspect the negotiation tokens and selected security package at a structural level, then trace whether the peer advertises a user-to-user requirement and supplies the required follow-up material. Do not solve this by forcing NTLM fallback. A working comparison should use the same target service and authentication mode so the presence or absence of the user-to-user exchange is visible.
What to inspect
- The selected SSPI package and whether Kerberos user-to-user authentication was requested or required by the server.
- The sequence of negotiation messages and whether the server returned the expected TGT-related reply before context establishment continued.
- Differences in SPN, account type, service credentials, and negotiation flags between a working and failing peer.
References
- RFC 4120: Kerberos V5
- Microsoft Open Specifications: Kerberos Protocol Extensions
- Microsoft: AcceptSecurityContext sequencing
- Microsoft: Kerberos authentication overview
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.