With Kerberos protocols, there is support for an authentication method using tickets that have been trusted as source providers. Kerberos tickets allow the network of credentials for a user that is associated with a given client computer to be authenticated. The Kerberos protocol defines how these users will interact with a network service to gain access to the various network resources.
The Kerberos Key Distribution Center (KDC) will issue a Ticket Granting Ticket (TGT) for a client computer. This is done on behalf of a given user. With Windows, the client computer is a member of an AD DS domain. The TGT is proof that the domain controller has authenticated the credentials of a given user.
Prior to establishing a network connection to a network service, the client computer must show TGT to the KDC and the request for a service ticket must occur. The previously issued TGT will confirm that the client computer has been authenticated. The KDC will issue a service ticket to the client computer.
The client computer will then submit the service ticket to the network service. The service ticket has to contain an accepted Service Principal Name (SPN) which is able to identify the service. To be able to enable Kerberos authentication, the client and server computers have to have a trusted connection to the KDC. The client and server computers also have to be able to successfully access AD DS.
There are many reasons why you should consider Kerberos authentication. They include:
- Kerberos protocol is the strongest of all Integrated Windows authentication protocols.
- It supports advanced security features including Advanced Encryption Standards (AES), encryption, and mutual authentication of clients and servers.
- It is designed for the delegation of client credentials.
- Kerberos requires the least amount of network traffic to AD DS domain controllers of the currently available secure authentication methods.
- It can reduce page latency in certain scenarios.
- It can increase the number of pages for front end web servers in certain scenarios.
- Kerberos is able to reduce the loan on domain controllers.
- This open protocol is supported by a variety of vendors and platforms.
Kerberos authentication isn’t always right though in the following scenarios:
- This authentication can require plenty of additional configuring to the infrastructure and environment. The domain administrator permission will be required for such configuration to be completed. This can be difficult to set up and hard to manage. If Kerberos isn’t configured correctly then the request to authenticate websites will fail.
- This authentication will require client computer connectivity to KDC and to AD DS domain controller. With Windows, SharePoint deployment relies on the KDC as the AD DS domain controller. This is a common network configuration for an organization in regards to their intranet. However, it isn’t usually the configuration for an internet facing deployment.
The authentication of Kerberos supports the delegation of client identity. This results in a service that can both impersonate and authenticate the identity of the client. With impersonation, it is possible for a service to pass the authenticated identity to other network services on behalf of the client. With claims based authentication, it can also be used to delegate client credentials. However, this also means the back end application will have to be claims aware.
With SharePoint 2013, Kerberos delegation will result in a front end service to authenticate the client and their identity to a back end system. The back end system is then able to perform with its own authentication. When a client uses Kerberos for front end service, then the delegation can be used to pass the identity of the client to a back end system. The Kerberos protocol is able to support 2 types of delegation:
- Basic Kerberos delegation (unconstrained)
- Kerberos constrained delegation
Basic Kerberos delegation can actually cross domain boundaries, but it has to be within the same forest. Kerberos constrained delegation isn’t able to cross domain or forest boundaries. Based on the service applications that belong to the SharePoint 2013 deployment, the implementation of Kerberos authentication with SharePoint 2013 can require the use of Kerberos constrained delegation.
In order to successfully deploy Kerberos authentication with any of the below mentioned service application, SharePoint Server 2013 and all of the external data sources have to reside in the same Windows domain:
- Excel Services
- Performance Point Services
- InfoPath Forms Services
- Visio Services
In order to deploy Kerberos authentication with any of the below service applications or products, SharePoint Server 2013 has to use either basic Kerberos Delegation or Kerberos Constrained Delegation:
- Business Data Connectivity Service
- Access Services
- SQL Server Reporting Services (SSRS)
- Project Server 2013 Preview
Any services that are enabled for Kerberos authentication can be delegated for identity multiple times. The identity will travel from service to service, and that delegation method can also change from basic Kerberos to Kerberos constrained but it isn’t possible to do it in the reverse order.
The delegation method can’t be changed from Kerberos constrained to basic Kerberos. With this in mind, it is very important to plan what you want your back end service to be and if it will require basic Kerberos delegation or not. Such information will play a role in the overall planning and design of the domain boundaries.
With Kerberos enabled service, you can use protocol transition to convert to a non-Kerberos identity into one that can be delegated to other Kerberos enabled services. This is an ability that can be used to delegate a non-Kerberos identity from a front end service to on that offers a back end service.
The protocol transition requires Kerberos constrained delegation. The protocol transition identities aren’t able to cross domain boundaries. The use of claims based authentication can be used as an alternate to Kerberos delegation. With claims based authentication, it is possible to pass it back and forth between the different services, but only if the following criteria are in place:
- Trust relationship between the services
- All services must be claims aware
SharePoint 2013 is able to support claims based authentication. This is built on the Windows Identity Foundation (WIF). This is a set of the .NET Framework classes used to implement claims based identity. This type of authentication requires standards including WS Federation and WS Trust.
When creating a SharePoint 2013 web application, the use of the Central Administration is necessary and you have to select 1 or more claims based authentication types. When you create SharePoint 2013 web applications from New-SP Web Application Windows PowerShell cmdlet, you get to specify either claims authentication or the types or class mode authentication.
All of the supported authentication types are available for web application and you can decide how to best use them for server to server authentication and app authentication. The following are service applications in the SharePoint Service 2013 that require translation of the claims based credentials to Windows credentials. This is a process done through the Claims to Windows Token Service (C2WTS). They include:
- Excel Services
- Performance Point Services
- Info Path Forms Services
- Visio Services
Any of the service applications that require C2WTS have to use Kerberos constrained delegation. This is due to the fact that C2WTS requires protocol transition that is only supported by Kerberos constrained delegation. The service applications in the above mentioned list allow the C2WTS to translate the claims within the farm to Windows credentials for outgoing authentication.
It is very important to realize that these service applications can use the C2WTS if they have incoming authentication from either Windows claims or Windows classic mode. Service applications that are going to be accessed through web applications or that use SAML or forms based authentication claims aren’t able to use C2WTS. They can’t be translated to Windows credentials.
When using Windows claims mode for user authentication, the web application needs to be configured to use only Kerberos authentication. It shouldn’t be set up to fall back to NTLM as that will prevent the authentication protocol from working.