Integrated Windows authentication: NTLM or Kerberos?

Recently, I have been studied the topic "Kerberos: Why do I need it?"


Here is a quick explanation (from Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products)what is Integrated Windows Authentication and relation to NTLM and Kerberos:

Integrated Windows authentication enables Windows clients to seamlessly authenticate with SharePoint Server without having to manually provide credentials (user name/password). Users accessing SharePoint Server from Internet Explorer will authenticate by using the credentials that the Internet Explorer process is running under — by default the credentials that the user used to log on to the desktop. Services or applications that access SharePoint Server in Windows integrated mode attempt to authenticate by using the credentials of the running thread, which, by default, is the identity of the process.

NTLM

NT LAN Manager (NTLM) is the default protocol type when Integrated Windows authentication is selected. This protocol takes advantage of a three-part challenge-response sequence to authenticate clients. For more information about NTLM, see Microsoft NTLM (http://go.microsoft.com/fwlink/?LinkId=196643).

Pros:

·         It is easy to configure and typically requires no additional infrastructure/environment configuration to function

·         It works when the client is not part of the domain, or is not in a domain trusted by the domain that SharePoint Server resides in

Cons:

·         It requires SharePoint Server to contact the domain controller every time that a client authentication response needs validation, increasing traffic to the domain controllers.

·         It does not allow delegation of client credentials to back-end systems, otherwise known as the double-hop rule. It is a proprietary protocol.

·         It is a proprietary protocol.

·         It does not support server authentication.

·         It is considered less secure than Kerberos authentication

Kerberos protocol

The Kerberos protocol is a more secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid Service Principal Name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals. For more information about the Kerberos protocol, see How the Kerberos Version 5 Authentication Protocol Works (http://go.microsoft.com/fwlink/?LinkId=196644) and Microsoft Kerberos. (http://go.microsoft.com/fwlink/?LinkId=196645)

Pros:

·         Most secure Integrated Windows authentication protocol

·         Allows delegation of client credentials

·         Supports mutual authentication of clients and servers

·         Produces less traffic to domain controllers

·         Open protocol supported by many platforms and vendors

Cons:

·         Requires additional configuration of infrastructure and environment to function correctly

·         Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows)

Long story short, I have decided that I am willing to spare time and configure Kerberos if I see the farm desperately needs following:

 1. Boost performance

 2. SSRS reports needs to pass a user credentials to external source like this one:

3. BDC uses Web services that needs to pass a user token to the external source

4. Any other type delegation (which is not present in my specific scenario but it might be in your case)