Tech Tips, News and Tribal Knowledge

Recently I experienced some unusual Kerberos authentication issues with one of our SharePoint farms. Users accessing the farm using the Kerberos protocol would receive repeated logon dialog boxes from the front-end server. The prompts would continue even though the user was entering the proper credentials. These repeated logon attempts wouldn’t lock out the user account which indicated the logon never got past the front-end server. This behavior affected only those users authenticating to the farm using Kerberos. Any users authenticating to the farm using the NTLM protocol had no issues logging in. In addition, the following KRB_AP_ERR_MODIFIED error appeared in the event logs:

Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 01/01/2008
Time: 12:59:00 PM
User: N/A
Computer: XXX
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server XXX$. The target name used was ldap/xxx.company.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (COMPANY.COM), and the client realm. Please contact your system administrator.

Using Kerbtray, I determined the user was receiving a valid Kerberos ticket from the front-end server and that ticket contained the proper service principal name (SPN). It appeared all DNS, forward and reverse, all delegations and all SPNs were correctly configured. The server was simply rejecting the user’s valid credentials. Following the clues from the event description, I began looking for duplicate or conflicting SPNs. I was unable to find any.

As other farms in our environment use the same basic configuration, I started to think this might be an issue with the secure channel, or domain account of the server. Since this was a new install, rebuilding the server wasn’t a big issue. Unfortunately the rebuild didn’t help. As soon as anyone tried to authenticate using Kerberos, they received the endless logon prompts. I was completely stumped until it occurred to me that what may be going on is exactly what the event indicated, but with a bit of a twist.

The theory I came up with was that the issue was not duplicate machine accounts, but duplicate keys. As the web application is an IIS virtual server and has a DNS name that is different from the server’s NETBIOS name, it was possible the server was sending the client the public key for the web application as configured in the SPN, but attempting to decrypt the packet using the private key associated with the server’s NETBIOS name.

To test the “multiple key” theory, I assigned two additional IP addresses to the server through the TCP/IP network settings. I then used the IIS manager to change the IP address for the SharePoint web application from “All Unassigned” to one of the newly added IPs. I repeated the process with the other new IP for the Central Administration site. All other web applications were left at the default “All Unassigned.”

After making the server changes and updating the DNS to reflect the directly assigned IP address, I rebooted the server. Once the server was back up, Kerberos authentication worked perfectly.

I’m not sure why it was necessary to statically assign an IP address to the web application as we have other farms that use the shared IP without issue. Perhaps it’s a hotfix, a .NET issue, or some obscure DNS anomaly. Whatever the case may be, we have reassigned all front-end servers with static IPs as a best practice and haven’t had a Kerberos issue since. If I ever find out the exact cause of this, I’ll post an update.