Tech Tips, News and Tribal Knowledge

In Eric Eaton’s post, How do I make our SharePoint site stop asking me to login? – Part II, he discusses several issues that prevent pass-through authentication from SharePoint to Active Directory. While browser settings are a common source of authentication problems, in this post, I’d like to discuss an interesting credential issue related to Kerberos ticket expirations.

Recently we experienced a rash of authentication issues when some users accessed a custom SharePoint web part that retrieves data from a MOSS farm hosted at a remote site. Although the target farm is in the same Active Directory (AD) domain as the source farm, this type of credential passing between IIS servers will introduce the “double-hop“ issue if the default Windows authentication method is set to NTLM. When a user accesses an IIS server in farm “A” and that server needs to pass the users credentials to an IIS server in farm “B,” authentication will fail unless the mechanism used is Kerberos. It doesn’t matter that both farms are in the same AD domain, only Kerberos will successfully avoid the “double-hop” issue.

In order for Kerberos to successfully pass credentials between IIS servers in different farms, both farms must be configured for negotiated authentication and have direct access to the same key distribution server (KDC). This means, both farms must either be in the same domain, or have a trust between domains. Kerberos doesn’t operate across un-trusted domains.

Knowing these requirements, we configured each MOSS farm for negotiated authentication and after solving several issues configuring Service Principal Names (SPNs) that I will discuss in a future post, we finally got our new custom web part working. After a couple of weeks, however, the help desk began to receive reports from several users that the web part was failing with authentication errors. Not finding anything wrong with the user’s profile or server permissions, the help desk issued its standard “reboot and try again” remedy when encountering unknown gremlins. This always seemed to fix the problem, at least temporarily. Unfortunately, after about a week, the support calls returned and it was usually the same users. That’s when I was put on the case.

Knowing this was an authentication issue and the authentication method was Kerberos, I grabbed my trusty kerbtray.exe and headed over to the user’s PC. It didn’t take long to figure out what was going on. Just looking at the Kerbtray icon in the system tray told me all I needed to know, “Kerberos – no credentials.”

“Do you logoff your PC when you leave the office?” I asked. “No” came the reply. “Do you ever logoff your PC?” I followed. “Well, only when it locks up or crashes” answered the now puzzled user. Finally, sounding somewhat like an irritated cop, I quipped “Well, there’s your problem, you’ve let all your Kerberos tickets expire.”

In some environments where applications are configured solely for Kerberos authentication, this may be a common problem. Contrary to what the Windows dialog box indicates when you issue the Ctl+Alt+Del, Windows doesn’t really have a log on / log off routine in the classic sense like say, a Unix shell. Instead you are granted access to resources until you either invalidate that access, or in the case of Kerberos, your tickets expire. This is what was happening to our users who were perpetually “logged in.”

With Kerberos authentication, when a user requests data from a remote server, that user’s PC will send a request for a session key to the local domain’s key distribution center (KDC). The KDC prepares two copies of the session key that both client and server will use for the authentication process. The client’s session key is encrypted with the client’s long-term key and the server’s session key is encrypted with the server’s long-term key. The long term key is derived from the user’s password.

The KDC then encrypts the client’s session key with the key it shares with the KDC. It also encrypts the server’s copy of the session key, along with the authentication data for the client with the key the KDC shares with the server. This packet then becomes the session ticket. Both the client’s session key and the server’s session ticket are then forwarded to the client PC.

When the client is ready to communicate with the server, the client decrypts its copy of the session key and uses it to encrypt an authenticator packet. The authenticator, along with the session ticket is forwarded to the target server. The authenticator and the session ticket now become the client’s credentials for access to the server. The server decrypts the session ticket, extracts its session key and decrypts the authenticator. If the authenticator decryption is successful, the server will allow access to the requested resource. If mutual authentication is required, the server will use the session key to encrypt a timestamp which it returns to the client. If the client is able to decrypt the timestamp and the time is within the configured limits, the client will know it is communicating with the proper server. For a more detailed explanation of the workings of Kerberos, see: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dscd_aun_yfet.mspx?mfr=true

Why did this problem only manifest itself with the custom SharePoint web part? Because all the other applications the user was using, such as Exchange, SharePoint, Windows file and print services, all fell back to the default NTLM authentication, which doesn’t expire until the user logs off the session. Only the application, which in this case was a web part, would fail when the Kerberos ticket expired. Interestingly, this NTLM fallback will occur even when the initial authentication was Kerberos.

In our environment, the tickets are valid for 10 hours and will automatically renew for 7 days. If the user doesn’t re-authenticate within the 7 day period, the tickets will no longer automatically renew and will expire and access to the Kerberos enabled service will fail.

The moral of the story is when depending on Kerberos for an application that has no NTLM fallback, make sure your users logout and login at least once per week. Actually, they should logout or lock their PCs whenever they leave them unattended. That’s just good security practice.