Authentication in Sharepoint - Kerberos/Negotiate vs NTLM

SharePoint supports a variety of authentication mechanism. “Support” may be a loose term as SharePoint does not really authenticates any asset directly, rather it relies upon IIS and what IIS can support using the provider framework within ASP.NET 2.0. Most of these methods are end user facing.

When a user visits a SharePoint site how the web site will get the users credential validated? In this scenario, browser (e.g., IE, Fire Fox, Chrome, etc) is the client. Here you have a wide variety of selection to choose from.

To fulfill the end user’s for a resource (e.g., link to a file) on a SharePoint site, SharePoint becomes the client (on end user’s behalf) and request ADO.NET to get the file from database. Now .NET runtime installed on Server becomes the client and submits a request to SQL Server to get the requested content from its data-store. The process unwinds and end-user eventually gets what he requested.

Is the user actually entitled to see and get the content is determined by the process of authorization that SharePoint keeps a full control of. Here again it uses the ASP.NET (role) provider framework model to determine the user’s eligibility. Validating a user is “Authentication” that SharePoint outsourced to IIS and determining the user’s eligibility is “Authorization” that SharePoint decide to keep in-house.

When it comes to inner working of SharePoint servers and services running on same server or across different servers it always requires you to choose Integrated Authentication as its plumbing is built into the foundation of Windows Server.
For integrated authentication, there are two methods (protocols) that are available and supported in a SharePoint implementation are NTLM and Kerberos.

NTLM is a lightweight and efficient protocol with its foundation into early networking products that Microsoft built before NT (LAN Manager!! – ring any bell?).

Kerberos is industry de facto with its roots into UNIX based systems.

There have been enough discussions and great write up at various Microsoft & Community Sites discussing the reasoning for one or the other and my intent is not to start that debate again. With time and maturity of product and the increased awareness in community weight is shifting more towards Kerberos than NTLM and there are good reasons for it. A SharePoint implementation might be happier with Kerberos but as a SharePoint practitioner you need to have a holistic view of a customer’s environment where NTLM might be better for simple usage and its low maintenance overheads. For a client project where post implementation support is limited or difficult, I would think twice before deciding for Kerberos. For example, a simple change in a service account context may result in errors or broken functionality. People might not know what the cause is but they will see a product (SharePoint) that stopped working giving a bad repo to product and/or the implementers.
Kerberos vs. NTLM

Those who have networking background from old Novell and NT time may recall IPX vs IPX/SPX ODI or IPXODI, NetBEUI vs. TCP/IP. IPX and NetBEUI were simple to implement non-routable protocols that just worked in small LAN environments where networking begins and ended with simple File & Print Sharing or may be some dumb terminals. Those, who in early days, implemented TCP/IP might recall the overhead of configuring the TCP/IP protocol stack on computers, and running in duplicate IP issues, or maintaining a list of available IP addresses. Configuring was not that straight forward either – install, set & load the vendor provided drivers, configure the IP address, mask, gateway and DNS at the least and it machine is moved to different network go and reconfigure it. Though TCP/IP was much better protocol and de facto in Unix environments but for many implementation it was not worth going through the configuration and maintenance overhead unless interoperability or internetworking is needed. Over the passage of time, story got lot better and now SOHO devices, (like broadband devices for home networking) come with self managed TCP/IP stacks and built-in DHCP servers.


If the SharePoint implementation that you working on is a typical, single farm, simple AD domain with few servers in the farm, and have no other application that requires to know (authenticate) who the end user is you will be just fine with NTLM.


If you have a complex large farm or farms, large number of users on the farm and in AD and integrates with other applications like SSRS you can achieve better results with Kerberos.

Kerberos solves multi hop application domain authentication challenges without requesting user to authenticate again NTLM is chatty, means it talks a lot with your domain controller to check if user credentials have the appropriate permissions (role) to access the resource. Whereas, Kerberos protocol is less chatty but has larger overhead as at authentication time it reads all the groups/roles that user has and use that cached information. The performance characteristics of Kerberos has a lower point of diminishing return if your Directory Service (AD) has lot of users and groups and user is member of many group. How many is too many? I don’t have any matrix or performance test results but in my experience and based on what I know (or I think I know) many users might mean many tens of thousands of users and many groups means few thousand AD groups and many groups for user means few hundred groups that your typical user is member of.



Decision support documentation for Kerberos that we see in SharePoint and many other places like TechNet, informs you to make sure Kerberos is supported in your environment. When you ask IT System Engineer if they support Kerberos many if not most will answer in No – we don’t use Kerberos. In reality Kerberos is extensively used by Windows OS and network Services that windows provides. Windows self-managed these Kerberos registration and deregistration without you ever knowing about. Network objects that you see in AD, like servers and workstations and services running under Local System accounts they all have Kerberos SPN (Service Principal Name) registered with AD. The proper term for what I have been Kerberos registration and deregistration is SPN (de)registration. SPN – Service Principal Name. Where it gets reregistered is KDC – Key Distribution Center; a service that runs on Domain Controller. Once an asset (object like a server host or a service like a web or LDAP Server) a token is issued that that holder carries for the duration. Here it kind of resembles to a DNS record’s TTL (Time to Live) or a commuter train ride pass good for a day. Directory Objects (like hosts and registered services) that windows networking manage maintain these tokens and they get expired and renewed with you ever knowing about it.
The SPN that do not get registered automatically is for configuration setting that you chose to implement as part of your design like SPN registration for a name given to a web server like intranet.example.com or mysite.example.com or the SQL server instance running under a domain user account (opposed to Local System). So the system administrators needs to know how to (un)register a SPN for such user created instance and the implications of duplicate entries or how to go about identifying the problem and resolving it.
Think about SPN like an IP address or email address. It has to be unique on the network or internetwork. Two people cannot have same email address but a person can have more than one email address, or two computers cannot have same IP address but a given computer can have more than one IP address (some wise sys admin might say I have a server that has dual port NICs and both ports have same IP address. This is called teaming, outside world still sees it as a single IP address and it’s the vendor’s provided driver or firmware that is managing them for either redundancy or for increased capacity)
Not everything is Kosher or Halal. So when you implement the Kerberos you still have low level OS components that require NTLM and you cannot block the NTLM traffic and expect things to work as normal. One thing that is going to run into problems is search components and the file or IPC shares that you have for inter-service communications or when index files get copied to query servers.
Unlike duplicate IP address issues, one nice thing about integrated authentication using Kerberos is it will fall back to NTLM if it cannot figure out Kerberos. By figuring out I mean, if Kerberos is not properly configured.
The story has gotten lot better with SharePoint v3 (i.e., WSS v3 and MOSS 2007). When the product was released Web Application Servers were supported on Kerberos and now with Infrastructure Update release (post SP1) SSP, SharePoint Web Services sites are also supported to run with Kerberos. Not to forget about SQL the muscle behind the SharePoint that can be configured to run with Kerberos.

Reference: http://www.agileconcepts.com/Blogs/AQ/


 Reference:

http://www.sharepointpitstop.com/2012/04/sharepoint-authentication-kerberos-ntlm.html

Configuring SharePoint 2010 with Kerberos Authentication

http://www.sharepointassist.com/2011/02/21/configuring-sharepoint-2010-with-kerberos-authentication/

Step by Step Kerberos Authentication for SharePoint 2010

Introduction

Kerberos authentication, created at MIT and named after Hades’ three-headed guard dog Cerberus (according to Wikipedia), has been around for decades.  The latest version 5, implemented currently by Active Directory, was released in 1993.  The protocol is designed to provide rapid, secure authentication to users on a multi-system network, or “farm” as we like to call them.

Advantages over Traditional Windows Authentication

The main advantage of Kerberos over NTLM or forms-based authentication is the ability for a user’s identity to securely traverse multiple servers without requiring a re-key of the user’s credentials.  This concept is referred to as single sign-on: login once to access everything.

A secondary advantage is speed.  Authenticating connections with Kerberos tokens is considerably faster than other methods.

Platform Uniformity

Another advantage is platform uniformity.  Any application, that you wrote, or Microsoft wrote, or anyone wrote, which uses Windows Authentication can automatically use Kerberos.  It’s built in to Windows and Active Directory.  It doesn’t require custom code like a forms-based or claims-aware provider.  Enabling it is as simple as telling the web.config to use it.

Necessity

Many farm scenarios do not warrant Kerberos authentication.  How can you tell if yours does?  There is a simple test: the double-hop.  Draw a quick diagram of your farm topology.  If you have any servers which are more than two degrees of separation away from your client, you will need Kerberos authentication only if you need to delegate access to those resources.  The figure below shows the double-hop scenario.

Figure 1: The Double-Hop

Each connection, or “hop,” must be authenticated.  Thus, the SharePoint server must establish a secure, authenticated connection to SQL in order to return data for the user.  If the data connections above need to impersonate the user, the connections must use delegation.  Kerberos authentication allows SharePoint and SQL Server to implement delegation.

Real-World Examples

The most common example of Kerberos in practice involves Reporting Services.  A user browses to a SharePoint document library to run a Report with data in a SQL Server database.  SharePoint and SQL Server both implement Kerberos authentication to allow the user to view the Report using the user’s own credentials.  No login prompts, no proxy accounts, no stored credentials.

Setup

Setting up Kerberos authentication for SharePoint and SQL Server takes only a few minutes.  Follow the steps below to get it running in your farm.  We will assume that SharePoint requires classic mode authentication for the Web Application.  (Obviously, you will need to change CONTOSO to your Domain name and use your actual service accounts.)

1. Configure SQL Server

Configuring SQL Server to use Kerberos is easy.  Create a Service Principal Name for your SQL Server by running the setspn.exe utility from the command-line.  NOTE: you will need to be a Domain Administrator to do this:

Figure 2: setspn.exe Syntax

Service Principal Names

You will need to become familiar with Service Principal Names to setup Kerberos.  They are composed of the following pieces:

Service			Principal
Service Class	Endpoint	Port	Domain	User
MSSQLSvc	DB-SRV-01	1433	CONTOSO	SqlServer
This is the unique class name of the service. It differs between different types of services.	This is the DNS address where the service is accessed. In this case, it’s the server name, but it can also be the fully-qualified domain name like: db-srv-01.contoso.local - or an alias like - database.contoso.local	The port is needed if it is not a standard port for the Service Class.	This is the NetBIOS domain name of the Active Directory where the service account resides.	This is the login name for the service account itself.

As far as I know, the Service Class is case-sensitive.

For good measure, Microsoft recommends creating multiple Service Principal Names.  The reason why: the client application creates the Service Principal Name when it sends it to the server.  If the client application choses to include the port number, or not include the port number, you should be ready.  The solution: create all of the following SPNs for SQL Server:

·         MSSQLSvc/DB-SRV-01 CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01:1433 CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01.contoso.local CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01.contoso.local:1433 CONTOSO\SqlServer

Note the variation in the Endpoint and Port.  We do this to ensure that we cover all the possible combinations that a client application could throw at SQL Server.  This is the best practice.

2. Create a Web Application

Create a new Web Application in SharePoint 2010 to use with Kerberos authentication.  Pick Classic Mode Authentication and make sure NTLM is used.  This Web Application will be created as the Default Zone.  We want to put this on a non-standard port and use NTLM authentication to ensure that we can always access it from the SharePoint server itself.

Note: you must use a Domain Account for the application pool identity.

Figure 3: New Web Application

3. Extend the Web Application to use Kerberos Authentication

Extend the Web Application you just created.  Set the Zone to Intranet and put the site on Port 80.  Use the host header intranet.contoso.local:

Figure 4: Web Application Extension

When you click OK you will get a warning about Kerberos.  Don’t worry: the Service Principal Name can be created before or after the Web Application Extension.

6. Create the DNS Record

Your server needs a static IP address and a DNS record to be accessed by users.  When Kerberos is involved, you must be sure that you create an A (for address) record and not a CNAME (canonical name, or alias) record for the SharePoint Web Application Extension:

Figure 5: New DNS Record

Enter the IP address of the SharePoint server and hostname of the Web Application Extension into the box and click Add Host to save the new DNS record.  The automatically generated FQDN should read intranet.contoso.local.

4. Create a Service Principal Name

Just like we did for SQL Server, create a Service Principal Name for the SharePoint Web Application Extension:

Figure 6: SharePoint SPN

The SharePoint Service Principal Name breakdown is as follows:

Service			Principal
Service Class	Endpoint	Port	Domain	User
HTTP	intranet.contoso.local		CONTOSO	SP_WebApp
HTTP works for http and https connections.	This is the DNS address where SharePoint is accessed. In this case, it’s the URL of the Web Application Extension	80 is a standard port, therefore we don’t need to include it.	This is the NetBIOS domain name of the Active Directory where the service account resides.	This is the login name for the SharePoint Application Pool account.

5. Enable Constrained Delegation

If this were SharePoint 2007, we’d be done.  But SharePoint 2010 requires Constrained Delegation.  In order to enable constrained delegation you have to connect to the Domain Controller and enable Delegation on the account used to host the SharePoint Web Application Pool.

Remote Desktop into the Domain Controller, open Active Directory Users and Computers, then locate the SharePoint Web Application Pool account.  Double-click on the account and locate the Delegation tab:

Figure 7: Delegation

Pick Trust this user for delegation to any service and click OK.  SharePoint will now authenticate clients using Kerberos authentication to http://intranet.contoso.local

Workarounds

A common work-around to the Real-World Scenario above, when Kerberos authentication is not involved, is a proxy account: hard-code the Report Server credentials into the Report itself.  When the user accesses the Report, SharePoint connects to SQL using the stored credentials.  This is also what the Secure Store service does.  This is also a form a delegation, but does not pass the user’s actual credentials to the data store: it uses a proxy account.  Thus, all users get the same rights on the data store and the password is saved in clear-text in the Report’s connection string.  If this doesn’t meet your requirements, you need to call in Kerberos to handle the connection.

Looking Ahead

Even though Kerberos is not always needed, or possible like with extranets, the introduction of External Content Types in SharePoint 2010 as a reporting tool will greatly increase the need for it.  The increased maturity and new features in PerformancePoint, PowerPivot, and Reporting Services in SharePoint mode, if your data is not on the SharePoint server itself you will need to use delegation.  The best choice which provides the lowest maintenance overhead, the highest level of security, and the lowest processor overhead, is Kerberos authentication.  Try it out in a VM farm on your local computer.  It’s a great tool to have in your SharePoint architect’s toolbox.

Reference:

http://www.thesharepointblog.net/Lists/Posts/Post.aspx?List=815f255a-d0ef-4258-be2a-28487dc9975c&ID=43