Description of Common Kerberos-Related Errors in Windows 2000 (230476)

SUMMARY

Windows 2000 provides support for MIT Kerberos version 5 authentication, as defined in IETF Request For Comment (RFC) 1510. The Kerberos protocol is composed of three sub-protocols. The sub-protocol through which the client pre-sends the ticket for admission to a service is called the Application (AP) Exchange. The sub-protocol through which the KDC distributes a service session key and a ticket for the service is called the Ticket-Granting Service (TGS) Exchange. The sub-protocol through which the client pre-sends the ticket for admission to a service is called the Client/Server (CS) Exchange.

This article describes common Kerberos version 5-related errors, and includes causes that may be associated with the errors. Note that these errors are associated with Kerberos specifically, not network connectivity.

MORE INFORMATION

Common Kerberos version 5-related errors in Hexadecimal:

0x6 (KRB_ERR_C_PRINCIPAL_UNKNOWN) "Client not found in Kerberos database"

The KDC could not translate the client principal name from the KDC request into an account in the Active Directory. Generally, verifying whether the client account exists and has propagated to the domain controller that generated the error. Checking Active Directory replication may provide an indication of why the error occurred. It can also be a problem where the name specified is not a recognized User principal name present on the userPrincipalName attribute of the account.

0x7 (KRB_ERR_S_PRINCIPAL_UNKNOWN) "Server not found in Kerberos database"

The KDC could not translate the server principal name from the KDC request into an account in the Active Directory. Generally, verifying whether the server account exists and has propagated to the domain controller that generated the error. Checking Active Directory replication may provides an indication of why the error occurred. Also if the server is not at least Windows 2000, there will not be any service principal names registered because that server is not capable of authenticating with Kerberos. In this case, this error can be ignored because the client will then switch to NTLM for authentication.

0x9 (KDC_ERR_NULL_KEY) "The client or server has a null key"

Keys should never be null (blank). Even null passwords generate keys because the password is concatenated with other elements to form the key. If a client sees this error, the administrator should reset the password on the account.

0xE (KDC_ERR_ETYPE_NOTSUPP) "KDC has no support for the encryption type"

The client tried to use an encryption type that the KDC does not support, for any of the following reasons:

The client's account does not have a key of the appropriate encryption type.
The KDC (cross-realm trust) account does not have a key of the appropriate encryption type.
The requested server account does not have a key of the appropriate encryption type.
The type may not be recognized at all, for example, if a new type is introduced. This happens most frequently with MIT compatibility, where an account may not yet have an MIT compatible key. Generally, a password change must occur for the MIT-compatible key to be available.

0x18 (KDC_ERR_PREAUTH_FAILED) "Pre-authentication information was invalid"

This indicates failure to obtain ticket, possibly due to the client providing the wrong password.

0x19 (KDC_ERR_PREAUTH_REQUIRED) "Additional pre-authentication"

The client did not send pre-authorization, or did not send the appropriate type of pre-authorization, to receive a ticket. The client will retry with the appropriate kind of pre-authorization (the KDC returns the pre-authentication type in the error). Many Kerberos implementations will start off without preauthenticated data and only add it in a subsequent request when it sees this error. In this case, this error can safely be ignored.

0x25 (KRB_AP_ERR_SKEW) "Clock skew too great"

There is time discrepancy between client and server or client and KDC.

0x26 (KRB_AP_ERR_BADADDR) ""Incorrect net address"

Session tickets include the addresses from which they are valid. This error can occur if the address of the computer sending the ticket is different from the valid address in the ticket. A possible cause of this could be an Internet Protocol (IP) address change. Another possible cause is when a ticket is passed through a proxy server or NAT. The client is unaware of the address scheme used by the proxy server, so unless the program caused the client to request a proxy server ticket with the proxy server's source address, the ticket could be invalid.

0x29 (KRB_AP_ERR_MODIFIED) "Message stream modified"

This indicates that the server was unable to decrypt the ticket sent by a client meaning that the server does not know the secret key used to encrypt the ticket, or the client got the ticket from a KDC that did not know the server's key. This can be tested by determining if the server can obtain a ticket to itself, or if anybody else can locate the server. The secure channel used by NTLM is also an indicator of the validity of the password on local machine accounts.

0x3C (KRB_ERR_GENERIC) "Generic Error"

A generic error that may be a memory allocation failure. The event logs may be useful if this error occurs.