SharePoint 2013 and Kerberos

Kerberos protocol supports an authentication method that uses tickets that a trusted source provides. 

 The Kerberos protocol defines how users interact with a network service to gain access to network resources, it provides a fast and a secure method for users and service accounts on a multi-server farm.

It saves users time when moving from one hop to another and removing the need to re authenticate with each hop.

In this article I have collected some information about Kerberos from several resources and based on my personal experience

The reasons why you should consider Kerberos authentication are as follows:

• The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication of clients and servers.
• The Kerberos protocol allows for delegation of client credentials.
• Of the available secure authentication methods, Kerberos requires the least amount of network traffic to AD DS domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers.
• The Kerberos protocol is an open protocol that is supported by many platforms and vendors.

The reasons why Kerberos authentication might not be appropriate are as follows:

• In contrast to other authentication methods, Kerberos authentication requires additional infrastructure and environment configuration to function correctly. In many cases, domain administrator permission is required to configure Kerberos authentication which can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.
• Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain controller. In a Windows and SharePoint deployment, the KDC is an AD DS domain controller. While this is a common network configuration on an organization intranet, Internet-facing deployments are typically not configured in this manner.

What is the Service Principal Name?

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. 

Configurations for Kerberos for specific site/web application will be done on 4 parts:

DNS: to add A record to the site.

-Open DNS and navigate to the forward lookup zone and right click on the zone and Click on new host (A or AAA).

-Type the Name of the web application without putting the domain and enter the IP to the server address (if you have load balancer so that will be  the VIP), click add host then click done.

Active Directory (Trust for Delegation): you need to be member of Domain admins or the Enterprise Admins in Active directory.

-Open Active Directory Users and Computers.

-Navigate in the tree where your SharePoint servers exists.

-Right click on the server name and click on properties, on the delegation tab

Click ‘Trust this computer for delegation to any service (Kerberos only)'  then click Ok.

(repeat this step for all SharePoint servers)

Set SPN from Commands using command window: you need to be member of Domain admins or the Enterprise Admins in Active directory.

-Open command prompt as admin.

-Create SPN for the service account which is the application pool account for the Web Application where the site is hosted using this command:

setspn -S HTTP/siteURL domain\serviceaccount

Other helpful command:

setSPN -L domain\serviceaccount  (to list all SPNs for this account).

SharePoint:

 -In the Central Administration, go to Application Management then press Manage Web Applications.

-Select the Web Application you want to configure, and click on Authentication providers in the top ribbon.

-In the Authentication Providers pop up window, click on the authentication provider you want to change.

-Make sure to select Integrated windows authentication and Negotiate (Kerberos).

-Press Ok and then Save.

By this Kerberos is configured to test that it works:

• From the client machine command prompt you can flush DNS (ipconfig /flushdns).

• Clean tickets lists use this command (klist purge). 

• Navigate to the SharePoint site.

• Then from the command prompt type klist and press enter you now be able to see the ticket information.

References:

http://technet.microsoft.com/en-us/library/ee806870(v=office.15).aspx

http://technet.microsoft.com/en-us/library/bb742516.aspx

http://blog.blksthl.com/2012/09/26/the-first-kerberos-guide-for-sharepoint-2013-technicians/

http://blog.blksthl.com/2012/09/26/the-first-kerberos-guide-for-sharepoint-2013-technicians/

http://en.wikipedia.org/wiki/Kerberos_(protocol)