Configuring SharePoint 2013 Central Administration with Kerberos authentication

When you install your first SharePoint 2013 (or 2010) server the first thing that the Configuration Wizard asks you is the authentication method of the SharePoint Central Administration Web Site. It offers you two options to choose from, NTLM and Kerberos. The experienced administrator in you says that kerberos one of course because it’s the more secure and modern one, right? The wizard warns you that there might be more configuration to do, but you continue anyway. The wizard completes successfully and you head on to the Central Administration Web Site, but it won’t open claiming that you don’t have permissions to it. What’s that all about, you ask? Well, that’s the topic of this post so read on…


Once you’ve finished with installing all the prerequisites and binaries the SharePoint Products Configuration Wizard starts. At some point you’ll get to a page titled “Configure SharePoint Central Administration Web Application“, you can find a screenshot below. First you have to specify a port number for the Central Administration Web Site. You can go with the wizard’s randomly generated one or specify your own.SharePoint 2013 Central Administration Kerberos Choice

In Configure Security Settings you choose between NTLM or Negotiate (Kerberos). If you choose NTLM, everything will work just fine. If you wanna go with Kerberos, once you click next, the Wizard warns you saying: “You have chosen to continue using Kerberos with Integrated Windows authentication  Manual configuration steps by a domain administrator will be required to create a Service Principal Name (SPN) in the Active Directory (AD). Do you want to use Kerberos authentication?“. Check out the screenshot below. Clicking Yes the Wizard continues, No will take you back to the previous screen.

SharePoint 2013 Central Adminsitration Kerberos Warning

The problem

The Configuration Wizard finishes without warnings or errors. Time to start the Central Administration Web Site. You click on the shortcut the wizard created and the page won’t open. What to do?

The problem lies with missing Service Principal Names (SPNs) in Active Directory. I’ve blogged about SPNs before, see Publising WSUS eiht a different URL using SSL. Basically, SPNs are records in Active Directory that describe which account is providing which service. For example, I want to access a Web Site that is secured with Kerberos Authentication. When I type in the URL this is what happens:

  1. The system will lookup who “owns” an SPN for that URL.
  2. If not found, fail.
  3. If found, it creates the necessary Kerberos tickets and the authentication proceeds.

Kerberos also requires the site to have a valid SSL certificate and that the site is used over HTTPS. In addition, the Central Administration site needs to be in the Local Intranet Sites Zone.

The Solution

You get Kerberos functioning by configuring three things:

  1. Configure SSL for the Central Administration Web Site
  2. Add the site to the Local Intranet Zone in Internet Explorer
  3. Create Service Principal Names (SPNs)

Configuring the Central Administration Site to use SSL

Kerberos requires that the site is viewed over SSL (HTTPS), configuring this is not the topic of this post. So just do it. 🙂

Add the Central Administration Web Site to the Local Intranet Zone in Internet Explorer

For Kerberos to function, you need to add the Central Administration Web Site to the Local Intranet Sites Zone in Internet Explorer. You can do this either manually or via Group Policy. This also is not in the scope of this article, so just go ahead and do it. 🙂

Creating Service Principal Names (SPN)

Here are the steps to configure SPNs for the Central Administration Web Site.

SPNs are configured with a tool called setspn.exe. With this tool you can create, search and delete SPNs in Active Directory. You will need proper permissions to modify the actual accounts in question.

What you need to do is create SPNs for the URLs of the Central Administration Web Site for the Active Directory Account that runs the site. The account that runs the site is the SharePoint Farm’s Farm Account. You configured this in the Configuration Wizard, remember?

You can get to the information and properties of the Central Administration Web Site with these PowerShell commands. The first one gets the Central Administration Web Site. The second one displays the basic properties. All the rest can be found in the $cawebapp object.

$cawebapp = Get-SPWebApplication -IncludeCentralAdministration | `
where {$_.DisplayName -like "SharePoint Central Administration v4"}


Here’s an example how to configure SPN for the URL for the account domain\spfarm. You can configure this for both the long (FQDN) and the short name of the site.

setpspn -s http/sp1 domain\spfarm
setpspn -s http/ domain\spfarm

That’s all there is to it. Now your system knows what to do to provide Kerberos Authentication for your SharePoint Central Administration Web Site.

But wait, there’s more. I believe that at some point, you’d want to change the address of the Central Administration Web Site to something else than the actual server name running the site, right? Well, then all this breaks again. In that case, things need to be configured inside SharePoint also. I’ll get back to that later…

Leave a Reply

Your email address will not be published. Required fields are marked *

Please, do the math and help fight spam * Time limit is exhausted. Please reload the CAPTCHA.