Enabling Kerberos on SharePoint

I’ve seen a few guides on enabling Kerberos on SharePoint which are fairly poorly thought out, structured, or include unnecessary steps. Enabling your SharePoint Web Applications to use Kerberos is extremely simple and only requites two steps: Setting the SPN (Service Principal Name) on a Domain User account and enabling Kerberos on the Web Application.

First, identify the Domain User account used to drive the IIS Application Pool that is or will be assigned to your Web Application. In addition, you’ll need the fully qualified domain name (you’re not still using hostnames in 2017, right?) that your SharePoint Web Application will use.

Setting the SPN, by default, requires Domain Admin rights in Active Directory. This can be done from any computer and doesn’t require you to be logged into a Domain Controller.

In this example, we’re assigning an SPN to a user using the HTTP service (note we use ‘HTTP’ regardless if using http:// or https:// to access SharePoint). This service will be for the FQDN ‘sharepoint.example.com’ and our IIS Application Pool is driven by the webAppAccount user in the domain named CORP.

Once set (and perhaps waiting for Active Directory replication depending on the Active Directory environment), we need to then set the Web Application itself to use Kerberos. Note that this will cause a service interruption.

Navigate to Central Administration -> Manage Web Applications. Highlight the Web Application you wish to enable Kerberos, then click the Authentication button in the ribbon. Click on the zone (probably ‘Default’). Scroll down to the Claims Authentication Types and select “Negotiate (Kerberos)”. Click Save. Clicking save on this dialog will cause the Web Application to reprovision on all SharePoint servers where the Foundation Web service is started.

Alternatively, this can be done via PowerShell to enable Kerberos.

Once this process is complete, the Web Application will be set to use Kerberos.

A couple of notes on Kerberos: It won’t be used in a scenario where the client cannot contact a Domain Controller; the client must be able to contact a DC in order to acquire a Kerberos ticket; for example, if the client is accessing SharePoint over the public Internet. You should never adjust Authentication methods or settings via IIS. SharePoint handles everything you need with regards to authentication on your Web Applications for you.

This guidance applies to SharePoint 2010 through 2016 in both Windows Classic and Windows Claims modes. The general guidance also applies to SharePoint 2007, but the method of setting Kerberos on the Web Application differs in Central Administration.

9 Comments

  1. Very good information. Clear and precise. ThanksTrevor.

  2. Thanks for sharing the information.
    In this case do we need to add one more SPN for host name only or not any more?

    e.g in addition to the one mentioned above

    setspn -U -S HTTP/sharepoint CORP\webAppAccount

    Thanks.

  3. Thank you for the guide Trevor. With the notes of Kerberos, my understanding is that with trusted or federation AD, kerberos won’t not work? Saying that the client joined to domain controller (DC) A needs to access to SharePoint joined to DC B.

    • If you use SAML, it’s more or less irrelevant (though you still need Windows Auth on a zone, so in my personal opinion, you should still set it for that zone as Search will leverage it; your IdP should also be leveraging Kerberos). As far as cross-forest, Kerberos authentication is still used; it is Kerberos Constrained Delegation that requires Windows Server 2012 for your DCs, but again the configuration I present here is not using KCD.

  4. Trevor, how does this apply to host-named site collections? Our web application has a number of host-named site collections (12). Do we need to create an SPN for each host named collection?

  5. For sites running on non-standard ports, do we need to add that to the SPN?

Leave a Reply