TL;DR — Quick Summary

Learn enable kerberos authentication on a sharepoint 2013 server. How to: Enable Kerberos Authentication on a SharePoint 2013 Server So.

Note: This article was originally published in 2013. Some steps, commands, or software versions may have changed. Check the current Authentication documentation for the latest information.

Prerequisites

Before you begin, make sure you have:

  • SharePoint Server 2013 or later
  • Farm administrator or site collection admin access
  • PowerShell with SharePoint snap-in

How to: Enable Kerberos Authentication on a SharePoint 2013 Server

So… As I was installing SharePoint 2013 it asked me if I wanted NTLM or Kerberos authentication, and indicated that Kerberos was the way to go. Little caveat: You might need to do some additional configuration. After doing some research it seems their definition of “little” and mine is a “little” different. Regardless, it seems like an elaborated process so I found a site that has done a great job providing step by step instructions and I would recommend:

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

Below is a copy of the content. I do this as it often happens, sites go down and the information is lost. You should try to visit the link above first as the information there probably gets frequently updated but if for some reason the link becomes broken below is the content found there as of the date this post was first published:

 

Checklist: StepSummary
1. Name ResolutionAn entry for the Web Applications URL must exist in either DNS or in the clients hosts file.
2. Service Principal NamesHTTP SPN’s must be created for the Web Application URL(s) and its Application Pool service account.
3. DelegationThe SharePoint Web Server must be ‘Trusted for delegation’ in Active Directory. (Note added 2012-12-08)
4. Authentication ProviderThe Web Applications Authentication provider must be set toAuthentication type: WindowsIIS Authentication setting: Integrated Windows authentication/Negotiate(Kerberos)
5. Verification of functionality(IMPORTANT!)Klist.exe on client must have a HTTP ticket for URL and User accountSecurity log on SharePoint Web Server must have event ID 4624 with user and kerberos. (If Kerberos fails NTLM authentication will be used!)
(https://blog.blksthl.com/2012/09/26/the-first-kerberos-guide-for-sharepoint-2013-technicians/#step6)

Hosts(not recommended method) 1.x1 Locate the hosts file on your client or server if this is what you are using as client. It is located in the following path: C:WindowsSystem32Driversetchosts. Use Notepad to open it(open notepad using right click and ‘Run as Administrator’ and you will be allowed to save the changes) 1.x2 At the bottom of the file, add a row with the following: IP-Addresshostname/FQDN - Example: 192.168.1.104 sharepoint2013 - Also add any FQDN’s needed, like in my example: 192.168.1.104 sharepoint2013.corp.balkestahl.se Note: Always end the last line with a Linefeed/Enter, else you may experience issues using the hosts file.

Note: To use setspn, you must run the setspn command from an elevated command prompt. To open an elevated command prompt, click Start, right-click Command Prompt, and then click ‘Run as administrator’.

You are now done with step 2 , Service Principal Name(SPN). Move on to step 3. Trust for delegation. - Step 3 Trust for delegation Note: To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.

By default, no server is trusted for delegation, meaning that a service on a server in the Active Directory, cannot act on a user’s behalf, basically this means that a service if trusted for delegation, can impersonate a user and request a Kerberos ticket in the users name. (added 2012-12-08) Note: Step 3 can be skipped if you only want to authenticate your users. Delegation is only needed if you are planning to access external or ‘second hand’ datasources, such as an RSS feed, Reporting Services or any other service external to the SharePoint server, that would require the users authentication to be delegated. Configuring delegation together with Kerberos will allow for ‘double hop’ scenarios. (Thanks Spencer Harbar for pointing this out)

Note: To perform this procedure, you must be a member of the SharePoint Farm Administrators group, or you must have been delegated the appropriate authority.

Note: If you are creating a new Web Application at this Point, simply select ‘Classic Mode Authentication’ as authentication and ‘Negotiate(Kerberos)’ as Authentication provider in the Security Configuration dialog during Web Application creation.