Whenever you create a new SharePoint website, one of the questions SharePoint asks you is to select an authentication mechanism. Should it be NTLM or should it be Kerberos? The first time I installed SharePoint, I picked Kerberos, because it sounded like a tropical fruit, only to be prompted that this will need more work! Given that I’m the laziest person you know, I changed my selection to NTLM, and went with the less naggy version instead!

Well, did I make the right choice!? To truly understand what choice I should have made, it makes sense to first understand the basics of what NTLM and Kerberos are.

What Is NTLM?

NTLM stands for NT Lan Manager. It is a Microsoft Authentication protocol implemented at the Application level of a computer network. This protocol is implemented as a challenge-response sequence. A challenge response sequence can be simple-the server presents a challenge or a question, and the client provides an answer, or a response! The right answer lets you in.

The problem with such protocols is that a malicious listener can eavesdrop and capture the response, and thus replay it back to the server whenever any access is requested. The server then has no way of verifying who the real client was. Thus to make challenge response more secure, various techniques have been invented over the years. For instance, you could have multiple responses, and multiple challenges between a server and a client. Or you could have the response being valid only for a certain duration of time. Yet another mechanism could be to use a one-way hash algorithm, which you can encrypt easily, but not decrypt easily. Thus, only encrypted versions of the password are sent over the wire.

NTLM uses some of these mechanisms and comes in two flavors. NTLM v1 and NTLM v2.

NTLM v1

NTLM v1 involves the server sending an 8-byte random number. The client performs a computation using a one-way algorithm, involving a secret known to only the client and the server, i.e., the password, and the 8-byte random number. This computed hash is then sent to the server. Since the computation algorithm, the password, and the 8-byte random number are all available on the server, the identity of the client is thus established.

NTLM v2

NTLMv1 has a huge shortcoming. The 8-byte randomly generated sequence is prone to a dictionary attack. Thus, NTLM v2 is a strengthened protocol built using similar mechanisms. In addition to NTLM v1, an MD4 hashed 8-byte client challenge is appended to the 8-byte server challenge. Thus, it is backwards compatible with NTLM v1, because the least 8-byte half of the hash result can be utilized for NTLM v1 clients, and is immune to dictionary attacks.

Now NTLM v2 sounds like a pretty secure protocol, and in fact, if you read the innards of this protocol, it sounds like the work of Coke-can glassed scientists, yet it has a few significant problems. Now before I shoot NTLM, let’s first understand what Kerberos is.

What Is Kerberos?

Much to my chagrin, it turned out not to be a tropical fruit! Instead, Kerberos is an open standard, not invented by Microsoft, but instead devised by the engineers at MIT and adopted by more than just Windows.

There are three players in Kerberos: the Key Distribution Center (KDC), a client, and a service server. In my example scenario, the KDC would be a domain controller, and the service server is a SharePoint Web Front End. The client, of course, is you and your computer.

When you logon to a Kerberos-enabled Windows 2000 or better network in the morning, you provide a username and password along with a domain to establish your identity to the computer network. By doing so, you would request a Ticket Grant Ticket (TGT) from the authenticating server, which is the KDC or the domain controller.

Later in the day, when you try accessing a resource on the network, you would present the TGT, an authenticator (client ID plus timestamp) and Server Principal Name (SPN) of the target server. This creates an access token for the client user.

Using this ticket, you may access various resources on the given server. In addition, using the TGT, you can create other session tickets on the network, all this while not passing your password, and allowing the server to pass your identity to another server-something NTLM couldn’t do!

Note that this is a vastly simplified representation of Kerberos; there is much else that happens behind the scenes.

Kerberos vs. NTLM

Okay so now that you understand the basics of both Kerberos and NTLM, you can make a fair comparison of both. You should consider these various points when choosing between NTLM and Kerberos.

  1. NTLM v1 is unsecure-don’t use it.
  2. NTLM v2 security is comparable to Kerberos, except ..
  3. ..Except, NTLM v2 cannot allow a server to pass the client’s identity to another server on the same network.
  4. Kerberos requires the client and accessed resources to be on the same domain. This makes it unsuitable for Internet-based scenarios, or with browsers such as Safari or Firefox.
  5. Pairing smartcards or Windows CardSpace with Kerberos will let you use Kerberos-based authentication over the Internet. In this case, your client certificate is mapped to an AD identity that never leaves the domain. However, the certificate can be accepted over the Internet.
  6. Kerberos is susceptible to a single point of failure. If the KDC goes down, nobody can authenticate.
  7. Kerberos is more secure than NTLM v2 in one regard-tickets can be revoked.

So, given the above information, which authentication mechanism should you use for your SharePoint installation? Well, clearly Kerberos is more chatty, unsuitable for the Internet, but allows multi-machine hop, and is more secure. So in situations where the identity of the user logged into the browser matters while accessing a back-end BDC store, or a back-end database exposed by an Excel sheet running under Excel Services, where the client authenticates to the back-end database using their identity, Kerberos is the way to go! There are some other scenarios, such as the RSS WebPart insisting on making an HTTP call under the user’s identity, something that won’t work unless you use Kerberos. But Kerberos needs additional setup, and won’t work with every browser.

Wouldn’t it be nice if there was a choice such as, "Don’t bother me, figure the best answer out!?".

Lucky for you, there is such an option, and it is called Negotiate. Under Negotiate, a browser first sends an anonymous request as usual to IIS. IIS then responds by telling the browser which authentication protocols the server supports. You should download the IIS Resource toolkit and verify this yourself. Simply hit the server with the AuthDiag tool with an anonymous request, and the server, if configured properly, will respond with Negotiate, and the various authentication mechanisms it accepts. If the server supports both Kerberos, and NTLM and your browser is IE6 or better, your browser will automatically send the Kerberos ticket to establish identity and access on the server. Firefox and Safari, on the other hand, will continue to use NTLM. This way, you get the best of both worlds.

You can also easily find the authentication any IIS website supports by running a simple command under C:\InetPub\Adminscripts on your computer. 

cscript adsutil.vbs get w3svc/WebSite/
root/NTAuthenticationProviders

And in order to change the authentication supported, you can use the same command and replace "get" with "set".

Lucky for you, when you set SharePoint to use Kerberos, it sets it to Negotiate. Thus, if you are willing to go through the additional headache of setting up Kerberos, you should!

Additional Resources

The instructions for setting up Kerberos are simple, yet diagnosing it and setting it up can be frustrating to say the least. I would like to leave you with a few resources in setting up Kerberos that I have found extremely useful.

  1. Configure Kerberos Authentication on SharePoint - http://technet.microsoft.com/en-us/library/cc263449.aspx.
  2. Setspn.exe download in the Windows Resource Toolkit: http://support.microsoft.com/?kbid=832769.
  3. The IIS 6.0 Resource Kit Tools http://support.microsoft.com/kb/840671.
  4. The IIS Diagnostics Toolkit, which includes the fantastic AuthDiag tool, which can, at a click of a button, verify your Kerberos setup or any associated errors. Available at http://www.microsoft.com/downloads/details.aspx?familyid=9BFA49BC-376B-4A54-95AA-73C9156706E7&;displaylang=en.

Until next time, happy SharePointing.