Kerberos errors in network captures

Hi guys, Joji Oshima here again. When troubleshooting Kerberos authentication issues, a network capture is one of the best pieces of data to collect. When you review the capture, you may see various Kerberos errors but you may not know what they mean or if they are real problems. In this post, I’m going to go over many of the common Kerberos errors seen in these traces, explain what they mean, and what to do about it when you see it.

I designed this post for IT professionals who have experience reviewing network captures. If you are unfamiliar with Kerberos Authentication, I recommend reading Kerberos for the Busy Admin by Rob Greene.

What is the best way to get the network capture?

If you are looking for Kerberos related problems, it is important to see the ticketing process over the wire. Follow the steps below to see the requests and possible returned failures. I typically prefer Network Monitor to Wireshark for captures as it gathers the process name, but you can use either one.

1. To reduce the possibility of caching data, do one of the following:

• Close/Reopen client application
• Logoff/Logon client workstation
• Reboot client workstation

2. Start the network capture

3. Clear DNS cache using:

ipconfig /flushdns

4. Clear NetBIOS cache using:

nbtstat –RR

5. Clear user Kerberos tickets using:

klist purge

6. Clear system / computer Kerberos tickets using (Vista or higher only):

Klist –li 0x3e7 purge

7. Reproduce the authentication failure with the application in question

8. Stop the network capture

Now that you have the capture, you can filter the traffic using the string ‘Kerberosv5’ if you are using Network Monitor. If you are using Wireshark, you can filter using the string ‘Kerberos’.

To be more thorough, load the Authentication Traffic filter that shows packets containing Kerberos tickets as well. You can do this by clicking the Load Filter button, choose Standard Filters, and then click Authentication Traffic.

You need to click the Apply button before the filter is actually loaded.

If there is a lot of traffic, remove the lines for NLMP to reduce some of the noise. Remember to click the Apply button again to make the changes effective.

Important: Depending on the application, the topology, and the domain structure, it may be beneficial to take simultaneous network captures from various points including the client, middle-tier server(s), and back-end server(s).

KDC_ERR_S_PRINCIPAL_UNKNOWN

When a domain controller returns KDC_ERR_S_PRINCIPAL_UNKNOWN, it means the client sent a ticket request for a specific Service Principal Name (SPN) and was unable to locate a single Active Directory object via an LDAP query with that service principal name defined on it.

There are two major causes of this error. The first is the SPN is not registered to any principal. In that case, you should identify which principal will be decrypting the ticket, and register the SPN to that account. The other major cause for this is the SPN was registered to more than one principal in the same Active Directory domain. In this scenario, the domain controller does not know which principal to use, so it returns the same error. Determine which principal is appropriate, and remove the SPN from the other(s). You can read more about this error here.

Extra details to keep in mind:

The HOST SPN (host/server.domain.com) works for multiple services like HTTP & RPCSS. If you would like to see the default Host to SPN mappings use LDP or ADSI Edit and navigate to: cn=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=[Your Domain Component]. Then look at the sPNMappings attribute.

KDC_ERR_C_PRINCIPAL_UNKNOWN

Similar to KDC_ERR_S_PRINCIPAL_UNKNOWN, KDC_ERR_C_PRINCIPAL_UNKNOWN means the domain controller does not know which client principal it should use to encrypt the ticket. The difference here is that instead of a missing or duplicate SPN, there is a missing or duplicate User Principal Name (UPN).

To resolve this, determine if the requestor has the correct UPN. If so, then determine if there is a principal with a matching UPN. If there is a match, look for a duplicate UPN.
You may be scratching your head on the duplicate UPN part because if you try to add/modify a principal that has a duplicate UPN in Active Directory Users & Computers (ADUC), it will block you from doing this. Active Directory does not actually enforce the uniqueness of User Principal Names, but it leaves that up to the application. ADUC checks for duplicates, but other utilities like adsiedit.msc and ktpass.exe do not.

KDC_ERR_ETYPE_NOTSUPP

Here, the client has requested a ticket from the domain controller with a specific algorithm of which the domain controller does not have a hash. In the request, the client will list all the algorithms it supports. The domain controller will pick the highest one that it supports and returns the ticket encrypted with that algorithm. If there are no matches, the domain controller returns KDC_ERR_ETYPE_NOTSUPP.

One common cause of this is older devices that are requesting DES encrypted tickets. By default, DES encryption is disabled in Windows 7 and Windows Server 2008 R2. Ideally, you should update those devices or Kerberos clients to support the newer encryption algorithms. If they cannot be upgraded or replaced, then you can enable DES through group policy. For a good way to find these devices, I recommend reading Hunting down DES in order to securely deploy Kerberos by Ned Pyle.

Another common cause of this is when a device requests an AES encrypted tickets before you raise the functional level of the domain to 2008 or higher. This does not typically occur on Windows clients as they request the legacy algorithms in addition to AES. This scenario is more likely to occur on Unix/Linux systems where an administrator specifies a single algorithm in the krb5.conf file. In this case, raise the functional level of the domain or configure the client to utilize another algorithm, like RC4-HMAC.

If the client is requesting an algorithm that the domain controller should support, but is still returning the error, try resetting the password on the account and wait for replication to converge. Resetting the password regenerates the hashes stored in the directory.

Note: Domain controllers do not store the password of the user. Instead, they store various hashes of the password using various algorithms.

KDC_ERR_PREAUTH_REQUIRED

If you see this error in the trace, it does not indicate there is a problem at all. The client requested a ticket but did not include the pre-authentication data with it. You will typically see the same request sent again with the data and the domain controller issuing the ticket. Windows uses this technique to determine the supported encryption types.

KDC_ERR_PREAUTH_FAILED

KDC_ERR_PREAUTH_FAILED indicates the pre-authentication data sent with the ticket is not valid. It usually means the user does not exist or the password supplied is invalid.

KRB_AP_ERR_SKEW

To avoid packet replay attacks, Kerberos tickets include an authenticator with the ticket. This authenticator is based on a timestamp so an attacker cannot reuse them. Getting KRB_AP_ERR_SKEW typically means there is a time synchronization issue in your domain, and the time difference is greater than the default 5 minutes. If this is a common problem, start looking for time drifts across the infrastructure.

KRB_AP_ERR_REPEAT

This is another mechanism created to reject replay attacks. The server caches information from recently received tickets. If the server name, client name, time, and microsecond fields from the Authenticator match recently seen entries in the cache, it will return KRB_AP_ERR_REPEAT. You can read more about this in RFC-1510. One potential cause for this is a misconfigured network device in between the client and server that could send the same packet(s) repeatedly.

KRB_AP_ERR_MODIFIED

If a service returns KRB_AP_ERR_MODIFIED, it indicates that the service was unable to decrypt the ticket that it was given. The name of the error suggests that an attacker may have modified the ticket in order to gain access to a system. While this is possible, the most common reason is when the Service Principal Name (SPN) is registered to the wrong account. If Service A gets a ticket encrypted with Service B’s password, Service A cannot decrypt it using its password. There is no way for the service to know why it cannot decrypt the ticket, so it returns this error. To resolve this issue, determine which account is actually running the service and move the SPN to that account. If the service is running as Local System, Local Service, or Network Service, set the SPN on the computer account.

Another possible cause is a duplicate SPN in two different domains in the forest. If it appears the SPN is registered to the correct account, search the entire forest for a duplicate SPN. For example: Say there is a service in Domain A that uses the SPN http/service.contoso.com and the same SPN exists in Domain B. If a user from Domain B tries to access the service in Domain A, it will fail with this error. The reason for this is the client in Domain B will first try to contact a domain controller in Domain B for that SPN. That domain controller will return a ticket for the account in Domain B.

An interesting issue we see revolves around IIS7 and Kernel Mode Authentication. Typically, you should register the SPN to the account that is running the application pool. Kernel Mode Authentication speeds up authentication requests and performs the decryption in the context of the computer account. In the case of load balanced web servers, you cannot have multiple nodes using the computer different contexts to decrypt the ticket. Either disable Kernel Mode Authentication or use the useAppPoolCredentials in the applicationhost.config file of the web server. For more information, review:

• configure IIS to use the application pool’s identity
• Troubleshoot Kerberos In WCF

KDC_ERR_BADOPTION

If the domain controller returns KDC_ERR_BADOPTION, it means that one of the KrbFlags set in the KdcOptions is not allowed. You can see a sample of the options in the figure below.

The most common scenario is a request for a delegated ticket (unconstrained or constrained delegation). You will typically see this on the middle-tier server trying to access a back-end server. There are several reasons for rejection:

1. The service account is not trusted for delegation

2. The service account is not trusted for delegation to the SPN requested

3. The user’s account is marked as sensitive

4. The request was for a constrained delegation ticket to itself (constrained delegation is designed to allow a middle tier service to request a ticket to a back end service on behalf on another user, not on behalf of itself).

KDC_ERR_WRONG_REALM

This error may occur when a client requests a TGT from a domain controller for a domain to which the client does not belong. This error refers the client to the correct domain and does not indicate a problem. You can read more about it here.

KDC_ERR_TGT_REVOKED

Getting a KDC_ERR_TGT_REVOKED error means that the TGT presented to the domain controller in order to get a service ticket is not valid. These errors are common when the client is in a site with a Read Only Domain Controller (RODC) and is attempting to access a resource in another site. Seeing this error does not necessarily mean there is a problem. Read more about the ticketing process with RODCs here.

Conclusion

Troubleshooting authentication issues is not always cut and dry. I hope you now understand the meanings behind common Kerberos errors what you can do about them. If you want to dive a bit deeper into this, I recommend reading the RFCs associated with Kerberos.

Kerberos RFC
https://www.ietf.org/rfc/rfc1510.txt
https://www.ietf.org/rfc/rfc4120.txt

I’ve also linked to a more comprehensive list of Kerberos errors you may encounter.

Kerberos and LDAP Error Messages
https://technet.microsoft.com/en-us/library/bb463166.aspx

Until next time,

Joji “three-headed puppy” Oshima

Comments

• Anonymous
  July 27, 2012
  What?  No appearance of the authentication Yeti?

• Anonymous
  July 27, 2012
  He is now the Office 365 Yeti.

• Anonymous
  July 28, 2012
  For the SPN issues - there is another great source of troubleshooting information here: blogs.technet.com/.../the-411-on-the-kdc-11-events.aspx

• Anonymous
  July 29, 2012
  very nice article.

• Anonymous
  July 30, 2012
  The comment has been removed

• Anonymous
  December 07, 2014
    This post contains the references and methodology I use when troubleshooting SQL Kerberos issues