Kerberos Authentication problems – Service Principal Name (SPN) issues - Part 3

Rob here. Now we have seen what it looks like when there is no Service Principal Name defined, and when the Service Principal Name is not unique in the forest. We will now cover what things look like when the Service Principal Name is NOT added to the correct account.

We are still using the same setup as part 1 with all the same computer account names. So we will not go over the setup or cover how to take proper network traces. We will not go into much detail on most of the network trace data since this has already been covered.

When the user attempts to go to the site https://webapp.fabrikam.com/webapp they are being prompted for user name and password.

When they type in the user name of “FABRIKAM\Administrator” and the password, they again get prompted for user name and password.

After the 3^rd attempt to enter in the credentials and we see the below:

If you have Kerberos Event logging enabled (KB262177) we see the following event listed here.

So, we now know that the error we are getting back from the Kerberos Authentication attempt is KRB_AP_ERR_MODIFIED (some network analysis tools show this as KRB5KRB_AP_ERR_MODIFIED). Basically this is stating that the Account that is running the service (in this case the IIS Web Application Pool account) could not decrypt the Kerberos ticket that the KDC gave to the client. This can happen for several reasons, but the most common are listed below:

• There is an account with the same SPN within the forest (Keep in mind in a multi-domain forest you need to search all domains to include other domain trees in the forest). As shown in the previous blog posting the KDC will give an error back of KRB_S_PRINCIPAL_UNKNOWN, but there are instances where it will give a Kerberos ticket that the service cannot decrypt and thus get a KRB5KRB_AP_ERR_MODIFIED.
• The Service Principal Name is on the wrong Active Directory account (Computer or User).
• The Active Directory account that is running the service has updated / changed its password and you are experiencing the problem because of an Active Directory Replication Latency or Active Directory Replication problem.

So now let’s look at the network trace of this attempt.

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP Address of 10.10.200.105 (frames 3 & 4)

2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 7 -14).

3. The machine then gets a TGT from the domain controller (see the AS-REQ and AS-REP) (frames 15 & 16)

4. The machine then requests and gets a Service Ticket for http/webapp.fabrikam.com (frames 17 & 18). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

5. The machine then goes back to the web server and attempts to authenticate to the https://webapp.fabrikam.com/webapp site using the Kerberos ticket that it just got from the domain controller (frames 19-22). During the authentication the web server responds back with KRB5KRB_AP_ERR_MODIFIED (frames 23-24).

6. The machine then attempts to get a service ticket (TGS-REQ / TGS_REP) from the domain controller two more times in the trace, but each time the web server reports the same error of KRB5KRB_AP_ERR_MODIFIED (frames 15-18, 25-26, 34-37). The reason why you are seeing three different TGS-REQ / TGS_REP) requests to the domain controller is because you were prompted three times for user name and password when attempting to access the site before you got the 401.1 unauthorized error from the web server.

We need to do more investigation when you get the KRB5KRB_AP_ERR_MODIFIED. Keep in mind that this error really just means that the Service you are attempting to connect to could not decrypt the Kerberos ticket using its password Hash.

The first thing that we will test is to see if the Service Principal Name is registered to the correct account. If you remember from the previous blog the Web Application pool account that is running the website is Fabrikam\KerbSvc, as shown below:

So we will use the QuerySPN.vbs script again to find out what account(s) have the http/webapp or http/webapp.fabrikam.com SPN defined. Review KB321044 if these tools are new to you.

As you can see the SPN is on the Web Server computer account. Well, this will just not work; we will need to take it off of this account and add it to the FABRIKAM\KerbSvc account using SetSPN.

Now we see that we are able to access the website, and authenticating to the website using Kerberos Authentication.

NOTE: If we would have found that there were no duplicate SPN’s and that the only SPN registered in the Active Directory forest was correct we would have looked into a possible Active Directory Replication problem that might be causing the issue. You might be asking how could AD replication be causing the issue?

Let’s think about that. When a user, or Service Account, or computer password gets changed one domain controller in the environment accepts the password change. Through normal AD replication all domain controllers in the domain get the updated password. If you remember the Kerberos service ticket (the TGS) is encrypted with the service’s password hash. When the service decrypts the ticket it is going to use its current password hash to decrypt the ticket. So if the Kerberos service ticket was generated by a KDC (Domain Controller) that has not received the latest password for the service account then it will encrypt the ticket with the wrong password hash and thus the service will not be able to decrypt the ticket; you then get the KRB5KRB_AP_ERR_MODIFIED message.

Well, this is the last blog for Service Principal Name problems. I hope that you have enjoyed learning how to troubleshoot Kerberos authentication using network trace analysis to help find the cause of the failures.

- Robert "The SPN Doctor" Greene

Comments

• Anonymous
  June 11, 2008
  This week’s interesting collection of links! Kerberos Authentication problems – Service Principal Name