SharePoint Kerberos authentication

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
• Use Azure Storage for backup - Thu, Feb 23 2023
• Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023

Authentication refers to the process of validating a user's credentials against a trusted account store. The salient question from the perspective of your SharePoint Server 2013 Web application is, "Is this user who he 'says' he is?"

In SharePoint 2013, the default Web application authentication type is claims-based authentication. Claims-based authentication enables Windows and SharePoint to federate user identity across multiple vendors' systems; in other words, we aren't limited to the Active Directory Domain Services (AD DS) LDAP credentials used in classic-mode authentication.

NOTE: A Curious Note About PowerShell

Strangely, the New-SPWebApplication PowerShell cmdlet defaults to classic-mode authentication instead of claims-based authentication. You actually need to invoke the claims authentication provider manually in order to allow the new Web application to make use of claims-based auth.

Within claims-based authentication, we can take advantage of Windows authentication, Forms-Based authentication, or trusted identity provider-based authentication. In this blog post we're concerned with Windows authentication because we assume that all our SharePoint users derive from AD DS domain user accounts.

Integrated Windows authentication is cool with SharePoint Server 2013 because as long as a user is logged onto a domain member computer with their domain credentials, they aren't prompted to re-authenticate when they connect to a SharePoint Web application.

The two options for Integrated Windows authentication in SharePoint 2013 are as follows:

• NTLM: This is the default protocol because it requires no special configuration. However, NTLM is slow compared to Kerberos and does not support the delegation of user credentials across servers.
• Kerberos: This protocol is fast, secure, and can be configured for delegation. However, its use requires special configuration both in Active Directory and in SharePoint.

You can set an authentication provider in SharePoint by connecting to Central Administration, navigating to Application Management > Manage web applications, selecting your target Web application and then clicking Authentication Providers in the ribbon. In the Authentication Providers dialog, click your desired authentication zone. I show you the Edit Authentication dialog box.

Simply enabling Kerberos for your SharePoint Web application is not enough to do the job.

You no doubt observed that the Kerberos option isn't called Kerberos, but Negotiate (Kerberos). What's the difference? Well, as it happens, this setting instructs SharePoint to begin authentication by using Kerberos. If Kerberos fails for whatever reason (likely your own incomplete configuration, I'm sad to say), then SharePoint will fall back to trusty NTLM.

You can check which authentication protocol is used by opening Event Viewer, navigating to Windows Logs > Security Log, and filtering on Event ID 4286. Check out Figure 2, where we can see that the user pfinnegan is authenticated by using NTLM (the interface says Negotiate, but later you'll see that this field switches to Kerberos once we have the protocol properly configured).

Because I know that Kerberos is not properly configured, I can see here that my user authenticates with NTLM.

First, the preliminaries

Kerberos authentication requires that your servers have host (A) records created for them in DNS. If you created a CNAME record for your Web Front End (WFE) load-balanced host name, then please recreate the record as an A record.

Also, make sure you are aware of your service account identities. Specifically, we need the service account(s) that you have associated with target SharePoint Web applications as well as your back-end SQL Servers. These need to be domain accounts, by the way.

Second, let's create some SPNs

The service principal name (SPN) issue is probably what scares off the most Windows and SharePoint administrators. Basically, an SPN simply attaches a specified service account to a, well, network service running on your network that will use Kerberos authentication and delegated credential passing.

We need to create SPNs on our SharePoint servers and our SQL servers. Fire up an administrative Cmd.exe session on each SharePoint server and run the following commands:

setspn -S HTTP/mem2 nuggetsphere\spservice

Let me add some notes to the preceding statements:

• The setspn command is used to view and manage SPNs on the local box.
• The -S switch verifies that you don't already have an SPN created for that service.
• The protocol (HTTP or MSSQLSvc for our purposes) can be uppercase, lowercase, or mixed case--it does not matter.
• Substitute mem2 for the host name of your SharePoint server.
• The nuggetsphere\spservice bit corresponds to my service account named spservice that exists on my test AD DS domain nuggetsphere.local.

I show you some actual setspn output in the screenshot below.

Configuring SPNs for key service accounts and network services

We actually need to create one more SPN for each SharePoint server, this time defining the server's FQDN:

setspn -S HTTP/mem2.nuggetsphere.local nuggetsphere\spservice

Are you feeling better about the SPN thing now? Good. Now pop open an elevated command prompt on your SQL Server computers and define an SPN there as well:

setspn -S MSSQLSvc/dcsql2 nuggetsphere\sqlservice

Third, configure your servers for delegation

Besides its security and performance, constrained delegation is one of the best features of Kerberos. For instance, let's imagine that you deploy a Web part to your SharePoint Web application that pipelines data from an Oracle 11g database on your network.

Moreover, you need to pass the connected user's Active Directory credentials between SharePoint and your Oracle server. This is a good example of delegation because in this case, the SharePoint server authenticates to the Oracle server not with its own service account identity, but rather that of the connecting user. Isn't that cool?

However, we need to configure each of our infrastructure servers for Kerberos delegation.

Connect to one of your domain controllers, open up Active Directory Users and Computers, and locate one of your servers. Next, right-click the server and select Properties from the shortcut menu.

Finally, switch to the Delegation tab. Constrained delegation technically refers to our administrative control over which protocols and services can or cannot be delegated. For a test environment like ours, I suggest you allow all delegation by selecting Trust this computer for delegation to any service (Kerberos only) and then clicking OK to confirm the change.

Configuring a SharePoint server for Kerberos delegation

Fourth, configure your SharePoint web app for Kerberos

Now connect to Central Administration in your SharePoint farm and enable Negotiate (Kerberos) for your target Web application(s) as described previously in this article.

After that, fire up the Internet Information Services (IIS) console on each SharePoint server and select your target Web application(s). Navigate to Authentication in the IIS configuration section, select the Windows Authentication entry, and click Providers.

We need to ensure that IIS is set up properly for Kerberos as well.

We need to ensure that the resultant Providers dialog box shows Negotiate above NTLM in the Enabled Providers list.

If that is so, then you are done. Otherwise, use the Move Up and Move Down buttons to make the change. Finally, click Advanced Settings in the IIS console Actions list and verify that Extended Protection is set to Off and that Enable Kernel-mode authentication is unchecked.

Fifth and finally, let's test!

From another domain-joined computer, open an elevated command prompt and reset your DNS resolver cache and Kerberos ticket cache by running the following commands:

ipconfig /flushdns
klist purge

Now pop open a browser and navigate to your target SharePoint 2013 Web application. Meanwhile, open Event Viewer on your SharePoint server and run the previously described filter on the Windows Security log. You want to see Kerberos listed for both the Logon Process and Authentication Package fields, as shown below.

We can see here that my domain user mjackon was authenticated by using Kerberos.

For your future studying pleasure, I will leave you with some hand-picked resources that can fill in additional details for you.

• The First Kerberos Guide for SharePoint 2013 Technicians
• Configuring Kerberos for SharePoint Farms - A Generic Gotchas List
• Using Kerberos for SharePoitn Authentication