Here is a step-by-step guide on how to configure the transparent SSO (Single Sign-On) Kerberos domain user authentication on the IIS website running Windows Server 2012 R2.
Start IIS Manager on your Web server, select the necessary website and go to the Authentication section. As you can see, only Anonymous Authentication is enabled by default. Disable it and enable Windows Authentication (First of all IIS always tries to perform anonymous authentication).
Open the list of providers, available for Windows authentication (Providers). By default, two providers are available: Negotiate and NTLM. Negotiate is a container that uses Kerberos as the first authentication method, and if the authentication fails, NTLM is used. It is required that Negotiate comes first in the list of providers.
The next step includes the registration of Service Principal Name (SPN) entries for the name of the website, which will be accessed by the users. If the IIS website has to be available only by the name of the server, on which it is located (http://server-name or http://server-name.adatum.loc), you don’t need to create additional SPN entries (SPN entries already exist in the server account in AD). If the website address differs from the host name or if you are building a webfarm with load balancing, you will have to connect additional SPN entries to a server or user account.
Suppose, we have a farm of IIS servers. In this case, it’s better to create a separate AD account and bind SPN entries to it. The target Application Pool of our website will be started from this account.
Create a domain account iis_service. Make sure that SPN entries are not assigned for this object (servicePrincipalName attribute is empty).
Suppose, that the website has to respond at http://webportal and http://webportal.adatum.loc. We have to specify these addresses in the SPN attribute of the service account.
Setspn /s HTTP/webportal adatum\iis_service
Setspn /s HTTP/webportal.adatum.loc adatum\iis_service
Thus, we allow this account to decrypt Kerberos tickets, when users access these addresses, and authenticate sessions.
You can check SPN settings of the account like this:
setspn /l iis_service
The next step is the configuration of IIS Application Pool to launch it from the account created earlier.
Select the Application Pool of your website (in our example, it is DefaultAppPool).
Open the Advanced Settings and go to the Identity.
Change it from ApplicationPoolIdentity to adatum\iis_service.
Then go to your website in IIS Manager and select Configuration Editor.
In the dropdown menu select system.webServer > security > authentication > windowsAuthentication
Change useAppPoolCredentials to True.
Thus we allow IIS to use the domain account to decrypt Kerberos tickets from the clients.
Reset IIS using this command:
The same has to be configured on all web farm servers.
Let’s test Kerberos authentication. To do it, open http://webportal.adatum.loc in the client’s browser.
You can make sure that Kerberos authentication is used on your website by means of monitoring HTTP traffic using Fiddler (we mentioned this tool earlier). Start Fiddler and open the target website in the browser. In the left part of the window, find the line of website access. Go to the Inspectors tab in the right part of the window. The line “Authorization Header (Negotiate) appears to contain a Kerberos ticket” shows that Kerberos has been used to authenticate on the IIS website.
You can make sure that Kerberos authentication is used on your website by means of monitoring HTTP traffic using Fiddler (we mentioned this tool earlier).
Start Fiddler and open the target website in the browser. In the left part of the window, find the line of website access. Go to the Inspectors tab in the right part of the window. The line “Authorization Header (Negotiate) appears to contain a Kerberos ticket” shows that Kerberos has been used to authenticate on the IIS website.