Configuring Kerberos for SharePoint farms - a generic gotchas list
Recently, I worked on a Kerberos configuration issue with a customer; these are my notes from the visit.
You’ll see some common themes with Kerbie Goes Bananas, and it puts much of that into practice. Speaking of, I must redo Kerbie with SetSPN -S (shameface)
1. DNS should use an A record to refer to the load balancing IP, not a CNAME
This configuration step avoids an Internet Explorer behaviour whereby IE resolves a CNAME into an A record, and requests a ticket by building an SPN for the A record, instead of the CNAME.
More information is available at https://support.microsoft.com/kb/938305 . In most cases, adjusting the behaviour of Internet Explorer across all machines is harder than adjusting the DNS entry involved.
2. SPNs must be registered against the Application Pool Account
Note: use the Windows 2008 (or later) version of SetSPN to identify problems such as duplicates when updating SPNs. Any existing document using SETSPN -A should be updated to use SETSPN -S.
Only two SPNs are required for Kerberos to function against a farm – the FQDN, and the short hostname.
These must be applied to the account used by the Application Pool receiving the user request, which practically means that in most cases, only one account is usable per hostname (pair).
SPNs to be registered are:
HTTP/farm
HTTP/farm.example.com
Against the user identity of the Application Pool the user is connecting to – say, DOMAIN\SPAccount. This must be a domain account when used in a Farm scenario.
Note that no port number is used for the default port, and that these SPNs are also used for TLS/SSL.
SETSPN -S HTTP/farm DOMAIN\SPAccount
SETSPN -S HTTP/farm.example.com DOMAIN\SPAccount
If the individual hostname is to be used occasionally (e.g. for troubleshooting), http/machinename and http/machineFQDN should be registered against that account as well.
This should result in a list of SPNs as shown:
setspn -l DOMAIN\SPAccount
Registered ServicePrincipalNames for CN=SharePoint App Pool Account,OU=Service Accounts,DC=example,DC=com:
HTTP/farm
HTTP/farm.example.com
3. The App Pool Account must be used for authentication
In a web farm scenario, a domain account must be used as the application pool identity. Once a suitable domain account is configured as the application pool identity (DOMAIN\SPAccount in this example), Kernel-Mode Authentication must be disabled, or the configuration’s useAppPoolCredentials property must be set to true (both may be used).
If this step is not performed, the app pool will not be able to decrypt the Kerberos ticket supplied by the client.
To disable Kernel-mode Authentication
Open InetMgr (IIS Manager), browse to Authentication for the site, click Windows Authentication and open Advanced Settings (Actions pane on the right), and untick “Use Kernel-mode Authentication”.
Reference: https://technet.microsoft.com/en-us/library/cc754628(WS.10).aspx
To set useAppPoolCredentials to true:
Open a CMD window as Administrator, then:
CD %windir%\system32\inetsrv
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true
Note: one line (wrapped), with no space after any dash (-) character.
Reference: https://technet.microsoft.com/en-us/library/dd759186.aspx
4. Performance – Kerberos and NTLM
Use of Kerberos should significantly reduce traffic between WFEs and Domain Controllers.
Every NTLM-authenticated connection requires the server to make a connection to a DC to complete authentication. The number of connections available to a DC simultaneously is governed by MaxConcurrentApi registry value.
Kerberos allows the client to authenticate to a DC once for the website, and to continue to use the ticket for the ticket lifetime (10 hours by default), across multiple connections, without necessarily needing to interact with the DC again.
References
MaxConcurrentApi
https://support.microsoft.com/kb/326040 (original article)
https://support.microsoft.com/kb/975363 (now supports 150)
Kerberos vs NTLM authentication with ISA Server (same concepts apply with Sharepoint or any Web app)
https://technet.microsoft.com/en-us/library/bb984870.aspx
And a third-party performance comparison of Kerb and NTLM authentication with kernel-mode authentication and without was found here (not overall site performance, just basic RPS).