Both NTLM and Kerberos are forms of Integrated Windows Authentication. NTLM uses a challenge-response protocal to authenticatet the client to the server. It begins when the client attempts to connect to a secure application. The server sends a challenge to the client, and the client responds with a hashed value that the server can use to validate the user and password. All of this is seamless to the end user who simply sees the requested web page open in the browser. NTLM is simple, works well, and developers have often been able to ignore authentication concerns because it was essentially transparent. As security concerns have grown, however, the need for a more secure authentication provider has become increasingly obvious. This is where Kerberos comes in to the picture.
Kerberos is a ticket-based authentication protocol. When a client wants to access a secure application, it requests a ticket from the key distribution center (KDC), which is the server running Active Directory. The KDC then creates a ticket based on the user credentials stored in Active Directory. The ticket is then sent back to the client, which can only use the ticket if it has the correct password. Once the user is authenticated, the ticket is cached locally where it remains until it expires.
Kerberos has several advantages over NTLM that SharePoint developers should care about. First, Kerberos has much better performance than NTLM. Because Kerberos caches credentials, servers can respond more quickly than under NTLM. Kerberos is also more secure than NTLM because the client can essentially authenticate the server as well as have the server authenticate the client. The biggest reason for developers to care about Kerberos, however, is delegation.
Take a step back and consider the process of connecting to a WSS team site using NTLM authentication. We know that NTLM will successfully authenticate a user that has a Windows account and grant access to the team site, which will then appear in the browser. While most of the page content will appear correctly, what if a web part on that page displays information from a line-of-business system with its own separate database? The web part itself must also authenticate against this other database. What credentials does it use? In many cases, we want the web part to use the same credentials as the current user. In other words, we want the web part to impersonate the current user.
SharePoint sites are set up so that web parts will initially impersonate the user accessing them. The user credentials may subsequently be passed to any system residing on the same server as SharePoint or on a different server that requires only a single additional authentication. If the data source requires a second authentication—like when you access a web service, which subsequently accesses a database—the impersonation will fail. This is typically referred to as the “double-hop” issue.
Kerberos, on the other hand, supports impersonation across machines. This type of extended impersonation is known as delegation. If the end user were authenticating to the team site using Kerberos, the web part would successfully authenticate to the line-of-business database and information would appear in the page.
It’s important to point out that Kerberos requires some additional configuration that can only be accomplished if you have rights to Active Directory. Additionally, there are other ways to solve the double-hop issue. Many developers, for example, utilize a SQL Server standard security account buried in a connection string that a web part uses to access the database. The MOSS SSO service can also be used to gain access to any system in the enterprise. The bottom line, however, is that Kerberos is superior to NTLM in several ways and you should utilize it where you can. In the exercise in this chapter, “Creating a Development Environment,” I detail the steps necessary to set up and configure Kerberos.