Please remember any work done in this blog post should be done in an isolated TEST environment, please do not try this in production until you are confident and ready.
So you have a SharePoint site and you want to enable Kerberos Authentication. Well, you are in luck as that is what this blog post is about. Kerberos Authentication can be confusing if you do not deal with configuring it regularly and it does take some minor work, but not too much.
Kerberos Authentication is easy as 1-2-3.
- Register the Service Principal Name (SPN) for the Service Account(s)
- Configure Delegation for the SharePoint Web Front-End Computer Object(s)
- Configure SharePoint to use Kerberos Authentication
It’s that simple!
OK. Let’s take a closer look …
Register the Service Principal Name (SPN) for the service account(s)
NOTE: You must be a Domain Admin or equivalent to do this step – see this article on TechNet about Setspn.
NOTE: If you have more than one Service Account that you want to register for Kerberos Authentication I recommend performing all three steps from start-to-finish, for only one Service Account at a time, as it is easier to troubleshoot.
For web-based applications we must manually register the SPN. Applications like SQL Server will automatically register the SPN (if configured correctly and if your organization policies permit it). Registering a SPN for a web site is quick and painless. “But how?” you say. Let’s assume our organization is contoso.com and we would like to add Kerberos Authentication to SharePoint – the URL for SharePoint currently is:
https://sharepoint.contoso.com (this might be http depending on your deployment)
We will need to know what the Application Pool Service Account is. To do that, all we need to do is take a look in IIS to get this information.
NOTE: If you have multiple Web Applications for SharePoint and you wish to enable Kerberos Authentication for each website then each Web Application must be configured for Delegation. For example, if you have:
- https://sharepoint.contoso.com for your Portal site
- https://mysites.contoso.com for MySites
Then each Web Application would need the SPNs registered for them.
In this example the Service Account is CONTOSO\SP_PortalAppPool.
So now we have enough information to Register the SPN. Open up an elevated command prompt and type this command to check to see if any SPNs have been registered to this Service Account:
SetSPN -L CONTOSO\SP_PortalAppPool
If you have not configured Kerberos Authentication then you should get back something like this:
If there are items listed then check with your Administrator on what they are used for before proceeding. However, if you are registering multiple Web Applications then you will see your prior additions.
We can now register the SPN for both the Domain Name (DN) and Fully Qualified Domain Name (FQDN).
In the same command prompt type the following commands:
SetSPN -S http/sharepoint CONTOSO\SP_PortalAppPool
and
SetSPN -S http/sharepoint.contoso.com CONTOSO\SP_PortalAppPool
NOTE: Notice that after the “–S” it is http even though the URL is https – this is correct.
NOTE: If you are registering another Web Application like MySites then the two above statements would be:
SetSPN -S http/mysites.contoso.com CONTOSO\SP_PortalAppPool
SetSPN -S http/mysites.contoso.com CONTOSO\SP_PortalAppPool
After running these commands you will get something back similar to:
Now let’s check to see that they are registered.
In the same command prompt type the following command again:
SetSPN -L CONTOSO\SP_PortalAppPool
We should now see the registrations for both the DN and the FQDN:
Phew!! There is step one done, finished!
Configure Delegation for the SharePoint Web Front-End Computer Object(s)
Now that we have granted permission for the Service Account, we need to enable Delegation for each SharePoint Web Front-End (WFE) server. In this example we have only one WFE.
Launch Active Directory Users and Computers. Locate the Computer Object for your WFE, double-click on it to open the properties up, and click on the Delegation tab:
Most likely the Computer Object is not currently trusted for delegation and the top radio button is selected. If there is something else configured then check with your Administrator before preceding. For most organizations we can select the middle radio button – Trust this computer for delegation to any service (Kerberos only). Click on OK and Step 2 is finished, even if you have multiple Web Applications. But alas, some organizations need to have Constrained Delegation. Fortunately, this is simple as well.
First, select the Trust this computer for delegation to specified services only radio button. Use Kerberos only will already be selected. Check the box for Expanded – this will list DN and FQDN when we add them.
Next, click on Add…. This brings up the Add Services dialog.
We need to select the Service Account to list the Available services. To do this click on Users or Computers…. This will bring up the Select Users or Computers dialog.
Remember we are configuring the Service Account CONTOSO\SP_PortalAppPool so type that in and click OK.
This will list all the Service Types configured for Delegation for this Service Account.
Note: Only the FQDN are listed.
Select http and then click OK.
We see that both the DN and the FQDN are added since we have Expanded checked. Click OK to update the object.
Phew!! Step two is done, finished! Well, unless there is more than one WFE or multiple Web Applications. If so, perform the same procedure for each WFE or Add an additional Service to this object.
From an AD point of view we are done, Delegation has been configured – YAY!! The only problem is IIS for SharePoint knows nothing of this … so on to the last step.
Configure SharePoint to use Kerberos Authentication
Launch Central Administration. Click on Application Management then Manage web applications.
You will get something like this. I am choosing to configure SharePoint Central Administration v4 to illustrate some minor bumps along the way.
Click on SharePoint Central Administration v4 then click on Authentication Providers in the Ribbon.
This will bring up the Authentication Providers popup.
Click on Default, if you have different Zones then you will need to update each Zone. This will display the Authentication Provider – Default Zone popup.
In IIS Authentication Setting select the Negotiate (Kerberos) radio button. This will display an information popup about Kerberos.
Click OK to continue.
Scroll down to the bottom of the popup and click Save.
NOTE: Clicking Save will do a few things. IIS will be changed and the Application Pool will be recycled, so connections will be interrupted. Since we are modifying Central Administration we will get the following screen; this is normal:
Why did this happen. IIS has been changed from NTLM Authentication to Kerberos Authentication and as a result our credentials do not work in this browsing session anymore. The fix is simple: close all Internet Explorer windows. Check in Task Manager to make sure all iexplorer.exe processes are ended. Open Central Administration again and voila! we have connected via Kerberos Authentication. Congratulations! You did it!!
WHOA!! Wait! How do we know? Let’s take a look below in Troubleshooting.
Troubleshooting / Issues
There are some items that I am not going to cover but are relevant for troubleshooting.
First, your DNS record(s) MUST be A records, they cannot be CNAME records. Also, I am assuming your browser is Internet Explorer and is already configured to allow Automatic logons in either the Intranet Zone or Trusted Zone.
Second, be aware that any work done in this post will reset IIS Application Pools and users will lose connectivity.
Lastly, Klist is your friend! This command line tool will display all the Kerberos tickets that have been issued to your user.
To check if Kerberos Authentication is working, follow these simple steps.
Open a command window.
To purge Kerberos tickets issued to your currently logged in user, enter this command in the command window:
Klist purge
In Internet Explorer browse to the site you want to test. In our above example I browsed to Central Administration.
To list all the tickets issued to your user, enter this command in the command window:
Klist
See the item bound in a red box? You will have something similar if Kerberos is working.
If you are still having issues, take a look at the Kerberos Survival Guide up on TechNet.
There is also a SharePoint 2010 Kerberos Word document from Microsoft Downloads that is still used to explain Kerberos for SharePoint, I suggest reading it.