Kerberos Nuance

N:B Real IP’s and DNS names have been changed to protect the innocent


We are setting up a new Business Intelligence farm 2 WFE’s 1 APP Server and Physical behemoth of a DB server to replace the old farm that is a bit lack lustre in performance .  Luke Welch and I sat down to perform the Kerberos configuration, I have done this a million times normally it goes off without a hitch but run into issues.  Luke came up the suggestion so all credit to Luke for this one.

I am an ex-developer so things on one line are cool still in my head, so I like to do host entries one line for the one IP.  The old URL is bob.compay and we are configuring the new farm on bob2.company for testing purposes.  So the HOST entry looks like this.

192.168.1.140 bob.company bob2.company

After I turned Kerberos Logging on we noticed For some reason it did not work looking at the error log we spotted the following error

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server svc_bob. The target name used was HTTP/bob.company. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (COMPANY) is different from the client domain (COMPANY), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

That should read HTTP/bob2.company not bob.company.  Luke thought that the fancy one line HOST entry was causing the issue.  I pinged bob2.company

C:\Windows\system32>ping bob2.company

Pinging bob.company [192.168.1.140] with 32 bytes of data:

Reply from 192.168.1.140: bytes=32 time<1ms TTL=128

Notice the bob resolution in the ping!  So IE was requesting a Kerberos ticket for bob.company instead of bob2.company which the service account svc_bob is not allowed to do.  All we had to do was spit the HOST entry onto two lines and all was fine.