A guide to https and Secure Sockets Layer in SharePoint 2013

Hi dear friends!


It has become something of a habit of mine, to jump over the tougher more difficult topics, the ones that I have spent a lot of energy avoiding before. Kerberos must be the worst of them all, and since I feel that I have Kerberos pretty much covered, I know everything and I can do anything…
This topic is something that I always avoided doing myself as well, if in production or in the lab, since certificates are difficult to understand and hard to come by for tests, I never got to try it much and thus it stayed a bit of a grey area for long.
But no more, by publishing this guide, I hope that I and you can all get over the fear of https/SSL together.
This guide is also available as a whitepaper to download Here
(Skip all the bullshit yada yada and jump straight to the steps.)

This guide was created far from the ultrafast fibreoptic gigabit internet Connections

One important thing to remember though, this guide is only meant to be used in test or lab, it is not recommended to use exactly this setup in production. If you are looking to setup https in production, then you should have a certificate issued by your own Certificate Authority or have one bought from a trusted certificate issuer such as Verisign for example. I don’t know all the downsides, but for one, you cannot revoke a self-signed cert.

My requirements for https in testing are these:
– They should look and behave the same as it would in production
– It should be a real DNS URL or a real URL added to the host file
– It should not cause any red warnings in the browser
– IIS and SharePoint must be configured the same way as if it were a real life scenario

How do we do this? Let me show you how I would do it…

First we need a proper environment, in my setup I have:
– A single SharePoint 2013 server on Windows Server 2012 running all roles but the DB.
– A SQL server 2008 R2 on Windows Server 2008 R2 (OS here is irrelevant)
– A Windows Server 2012 DNS server
– A Windows Server 2012 Domain Controller (Any DC will do…)
– A Windows 7 client with Internet Explorer 9. (Most common customer setup, works from the server as well with loopback check disabled)

I am also using a utility from the IIS 6.0 Resource kit, download that before we start from this link: Download IIS 6.0 Resource Kit

In order for https / SSL and SharePoint to work we need a few things, lets add it all up in a checklist:

– A Web Application with a root site already created
– A URL (FQDN preferred)
– A DNS entry to go with the URL
– A Self-signed Certificate (or from a trusted issuer)
– IIS Binding
– Certificate added to trusted authority on the client/server
– URL added to the local intranet zone in Internet Explorer for auto-logon

In my example, I will use the following:

Requirement In my test environment
– A URL (FQDN preferred) sharepoint2013.corp.balkestahl.se
– A DNS entry to go with the URL sharepoint2013.corp.balkestahl.se ->
– A Certificate (Self signed or from a trusted issuer) Certificate created using the IIS 6.0 RK utility SelfSSL.
– AAM Internal http and https, Public https only
– IIS Binding Bind my site to https and all IP using the created certificate

These are the steps we need to take (click on any link):

1. Create a new Web Application or use an existing one (use port 80 initially and not https/443 for this guide.)
2. DNS, create an A-Record
3. Create the certificate (or request, buy, get any way you choose the real deal)
4. Add IIS Binding with Host-Header (this has to be done manually)
5. AAM, Add the necessary Alternate Access Mappings
6. Add the certificate to the Trusted Certificate store on the client
7. Test functionality
8. T-Shooting
9. References and recognitions

Note: If there is something that I have missed in this guide, or that should be done differently, please let me know.
I will reply to any comment and feedback that you submit.

1. Web Application
This step can be skipped completely if you already have a working Web Application with http on port 80 with an existing Site Collection.
If you do not have that or don’t feel Confident that it will be adequate, follow these simple steps.

1.1 In Central Admin, go to Application Management, then Manage Web Applications, in the ribbon, click on new, fill in the form using your own values.

Note: The Name value is what the Web Application will be shown as in CA and in IIS.


1.2 Note that I have not chosen to use SSL here, this will be added at a later time. Leave these choices as default.


1.3 The http url for this web application. As we set this up initially on port 80 and using http only, this could be anything, I have chosen to use the same FQDN as my https address will use.


Leave all other settings as is, the default values will do just fine for this test. The default is in 2013 using claims as authentication provider and this will serve our goal well.
I will not show you step by step how to create a Site Collection in the Web Application, something that you must do in order for the browser to later access the URL. But the steps are something like this:

1.4 Create a new Site Collection: In Central Admin select Application Management

1.5 Under Site Collections section, click on Create Site Collection.

1.6 In the dropdown, select the proper Web Application.

1.7 Enter a Name, Address and Description.

1.8 If only for test, use the Team site template under the Collaboration tab.

1.9 Add yourself as a site Collection administrator, or the account that will test access from a client, or add both in the primary and secondary fields.

1.10 Click OK. Wait until it has been created. Done!

Back to main menu

2. DNS

2.1 On your Windows Server 2012 running the DNS service, start server manager, then click on Tools and select DNS:


2.2 Locate the forward lookup zone for your domain:


2.3 Right click the zone and select New Host (A or AAAA)…


2.4 Enter the name of your site, this together with the full domain path will form the FQDN, Fully Qualified Domain Name. In the IP address field you enter the IP address of the SharePoint web server:


2.5 Click on Add Host and then Done, when you see this and verify that the FQDN shown is correct, you are done with the DNS part.


Back to main menu

3. Create a certificate

In my test setup, I will create my own certificate but use a properly named one, this makes it feel more like the real thing. If you have not already done so, download and install the IIS 6.0 Resource kit that comes with the nifty little util called SelfSLL. This allows you to create a self-signed certificate that has a proper URL, a requirement if you want to avoid the red warning in the browser that a regular self-signed cert would give you. The RK can be downloaded here: Download IIS 6.0 Resource Kit

Content of the IIS 6.0 Resource Kit – the following tools are available in this package:

  • IIS 6.0 Migration Tool Version 1.0 Version 1.1 Now Available!
  • Apache to IIS 6.0 Migration Tool Version 1.0
  • CustomAuth Version 1.0
  • IISCertDeploy.vbs Version 1.0
  • IIS Host Helper Service Version 1.0
  • IISState Version 3.0
  • Log Parser Version 2.1 Version 2.2 Now Available!
  • Metabase Explorer Version 1.6
  • Permissions Verifier Version 1.0
  • RemapUrl Version 1.0
  • SelfSSL Version 1.0
  • TinyGet Version 5.2
  • Web Capacity Analysis Tool Version 5.2
  • WFetch Version 1.3

What we really want out of all this this time, is the small util called SelfSSL in bold. This little util allows you like I said before, to create a self-signed cert using an FQDN of choice. In my example, I want to use the URL: sharepoint2013.corp.balkestahl.se and have the cert created with the same URL. I’ll show you how step by step.
It’s really quite simple.

Note: You might consider even in a lab Environment, to install your own Certificate Authority and issue your own private Certificates, the following links will be of help when doing that:
Install the Certification Authority (Windows Server 2012)
Install a Root Certification Authority (Windows Server 2008 R2)
Active Directory Certificate Services Overview (Windows Server 2012) 

3.1 Run the tool from the start menu:


3.2 The command-line tool does not look much to the world:


Note: You need to be logged on with an account that is a member of the local administrators Group in order to use this tool.

It gives you some options and I’m not going to go into what can be done with this tool, I’ll just go with the default and create a certificate using the suggested settings with one exception, we need to use the proper site ID.
Every site in IIS gets an ID, this is in this case used to put the certificate in the correct place on the correct site.

3.3 Get the correct ID from IIS, open up the IIS Manager, in server manager, click on Tools and then on Internet Information Services Manager:


3.4 In Internet Information Services Manager, select your site:


3.5 On the right pane, near the bottom, click on Advanced Settings…:


3.6 In the next dialog, you will see a row called simply ID:


3.7 Select the number in the field and right click and copy:


3.8 Paste the ID after the /S: switch. You should also change the value for the /V: setting, this represents how many days the certificate will be valid, the default 7 is ok for me in a very temporary setup, but for longer test runs, make it 90 Days or so. If the certificate expires, you will get ugly warnings that the certificate has expired and that it is untrusted. Https wil still work but on probation…
Now you have all you need to proceed. Run the SelfSSL util and use the site ID but leave everything else default.
Answer yes to the question – Do you want to replace the SSL settings for site 724410038.

selfssl.exe /N:CN=SharePoint2013.corp.balkestahl.se /K:1024 /V:7 /S:724410038 /P:443


Note: One option that could be useful, if you add the /T to the command the certificate will be added to the local Machines trusted authority certificates list. This makes it trusted in the servers browser.

The certificate is now created and put into the personal store for this computer.
If you get an error here stating that the certificate could not be assigned to the site, then you most likely already have an instance of the same certificate name, locate any existence of the certificate and delete it. (See how later in the post under chapter 8. T-shooting)

Move on to Chapter 4 or go Back to main menu

4. IIS Binding

In order for the web server, IIS, to recognize any incoming traffic and locate the proper site to direct it to, IIS uses Host header bindings. This is done so that you can have more than one site on port 80 in the same web server. The default site has a blank Host header binding which will in affect make it claim all incoming requests as its own.
SharePoint stops the Default Web Site so that does not affect us now, but we need to take care of our own IIS Web Site that in reality is our SharePoint Web Application.

What we have to do, is make our IIS Web Site answer to all incoming traffic with a host header of https and the FQDN created in Chapter 2. DNS – sharepoint2013.corp.balkestahl.se

4.1 Start by opening up your IIS manager, in Server Manager, click on tools and the on Internet Information Services (IIS) Manager:


4.2 Locate your Web Site:


4.3 In the right hand pane, locate Bindings:


4.4 What you see here is a list of the existing Bindings for this site, Type, Host Name, Port and IP address. If you have created the certificate using the SelfSSL util and added the ID of the Web Site, then you will most likely see at least two rows here (see 4.5).

4.5 This is what you will have if the SelfSSL successfully added the cert to the site using its ID:
If this is what you have, select the second row with the https/443 and click on Edit, then scroll down to step 4.11 in this guide.


4.6 Assuming that it was not added, we have to add the cert to the site. Click on Add.


4.7 In this dialog, we must first select the proper protocol, https. Use the dropdown:


4.8 Once you have selected https as the protocol, you will find that a new field appears. This is where you select the certificate to use.


4.9 Select the certificate created in Chapter 3. Create a Certificate, in my environment, that is the sharepoint2013.corp.balkestahl.se certificate listed.

4.10 Once selected, you can click on View to verify that it really is the correct certificate and that everything looks to be in order, click on OK.


4.11 Next we add the Host Name that this Binding will be matched on, same as the certificate name, sharepoint2013.corp.balkestahl.se, click OK.


4.12 Now you should see two rows in the bindings list for this Web Site. One for the initial http/80 and one for https/443. This is goOoOod!


4.13 Now click on Close and Close the IIS manager.

Move on to Chapter 5 or go Back to main menu

5. Alternate Access Mappings – AAM

In order for SharePoint to know how to handle the incoming requests for this new URL, we need to add/configure Alternate Access Mappings, this basically tells SharePoint how to handle all URLs. AAMs Control if SharePoint should do a redirect or a translation of the incoming address. AAMs can be configured from Central Administration and using PowerShell, I will in this guide use only CA.

5.1 Open up your Central Administration site and click on Configure Alternate Access Mappings located under the System Settings category.
This will show you all Alternate Access Mappings for all of your Web Applications in the farm. In the top right dropdown, click on Change Alternate Access Mapping Collection and select the correct Web Application.
Now, it will look like this:


5.2 Next thing we want to do, is to alter the existing Public URL so that it uses https instead of http. Since all else is ok, add the s…


5.3 Ok on that will give you this view, note that both the Internal URL and the Public URL has changed. This site is now only accessible by the https protocol. (Not entirely true, but true enough)


5.4 I always like to be able to type in the default http URL in my browser, and if the site uses https, be redirected automatically. This is rather easy to do in SharePoint, simply add an Internal URL using http and add it to the Default zone which will direct us to the Public URL using https. It may sound difficult but trust me, it just works.

If you are interested in Learning more about Alternate Access Mappings and the inner workings, I have a free whitePaper published on the subject for 2010 Here and a basic post for 2013 Here.

Anyways, click on the Add Internal URLs link and simply add the same URL using http, make sure that the default zone is selected.

Note: The zones used in AAM has NO RELATION with the zones in Internet Explorer, they are named similar, but they have no connection whatsoever.


5.5 Now the list should look like this, note that you have http and https on the left (incoming traffic) and only https on the right (target):


You are now done configuring your Alternate Access Mappings! Let’s move on to testing, start with Chapter 6.
Back to main menu

6. Add the Certificate to the Trusted Authorities store.

If we do nothing else from here, we will be able to access the site using https, but it will not be pretty…in order to mimic https using a ‘real’ certificate we need to also add the certificate to the trusted store. This will make the browser trust the cert as authentic and it will stop throwing us the errors.

Note: If you are doing these tests on the server itself, you will need to disable the loopback check Before accessing the site, else it will fail. See Chapter 8. T-shooting for information on how to do this.

6.1 Try it first, open a browser, type in the address of the https URL and hit enter. You will first see this warning. Click on Continue to this website.


6.2 This will lead to a login prompt. This is to be expected at this Point, login using your credentials that you have made site Collection admin or that have access to the site Collection.


6.3 Access! Yeay! or…no…hang on?! that’s not the way I pictured it…we don’t have access and we have a red certificate error. This is not what we want our users to see…
Two things cause this:

6.3.1. The White ribbon telling us that this is a secured browser comes from that the server in this case, has IE ESC – Internet Explorer Enhanced Security Configuration enabled.
If you are using a client like Windows 7 or 8, you will not see this but should actually see the site content.
To fix this, follow the steps in this blog post: How to disable IE Enhanced Security in Windows Server 2012 (Opens up in a new window)

6.3.2. The red Certificate error is there because the certificate comes from an untrusted source. This is as it should be, and can be fixed.
To fix this, keep reading…


6.4 There are several ways to add the certificate to the trusted store, I will show you the easiest of them all. Click on the Certificate Error to the right of the red shield symbol. This will show this:


6.5 It is all true what it says, except that nobody is trying to fool us…Click on View Certificates to show this dialog:


6.6 You can probably guess what the next step is going to be? Click on Install Certificate…


6.7 We want the certificate to be in the Computers store, select Local Machine and click Next.


6.8 Select Place all Certificates in the following store and hit the Browse button.


6.9 Now, locate the ‘Trusted Root Certification Authorities’ and make sure it is selected, click OK.


6.10 Verify that this is what you see as well. Click on OK.


6.11 Success! Try again to browse to the site, you should probably close the browser and start a new browser window.


6.12 Now we’re talking! that’s more like it, no red errors, no banner preventing us from loading the content…all is good, Life is GOOD!

Note: On my own server, it simply took a while for the error to go away, the IE cache has a renewal cycle of 50 minutes, to force a renewal, press Ctrl F5. That should do it.

Back to main menu

7. Test functionality

Testing has really already been taken care of in Chapter 6, but if you did what I did and used the servers browser (not recommended in production) to test access, then you really should test from a client to get the proper feel for it.
Use the steps described in Chapter 6 on the client computer as well. The dialog may look a bit of, but it’s the same steps basically. Sample dialog:


You will get the Picture if you use the steps in Chapter 6. Once you see the image below in your browser, you are OK!

Back to main menu

8. T-shooting

T-shooting scenarios covered so far:
– 8.1 Delete redundant certificates
– 8.2 Configure Loopback check

8.1 Delete redundant certificates
If adding the cert fail and you want to delete every copy, do this:

8.1.1 Press the start button, type Certificates…


8.1.2 Select Manage computer certificates.


8.1.3 This will open up the ‘Certificates Manager’//MMC Certificates Snap in. Locate the Personal, Certificates folder. In the content, either delete them both, or, find out which is the newer and delete the old one.


8.1.4 In the Certificate Details, you will see the Valid from timestamp, this is from when the certificate was created.


8.1.5 When you know which one to keep, delete the other, right click delete.
Back to main menu

8.2 Configure Loopback check.

Note: Remember that the loopback check is a security feature that has been put there for a reason, it protects the server from a certain form of attacks. Disabling it will open up the server for such attacks. Read Spencer Harbars post at the link below for a deeper understanding of this concept.

Are you planning to do one of two things on your SharePoint server, then you need to configure this, configure, not necessarily disable it.
– If you have search on the server and the Content source Points to the server itself using an FQDN.
– If you want to use the servers browser to test functionality or to access CA using an FQDN. (This is us in this guide…)

Note: I strongly recommend against using any browser on any server! It is a security risk since use of the browser opens up new ways for unwanted code to enter the server. Always access the server from a client browser!
I use the servers browser in my lab to make it easier, but it is a contained lab environment and the accounts used do not have access to anything outside this particular lab environment. furthermore, the lab environment cannot be reached from outside nor can it access the Internet.
(Thanks Anders Janson, UAG/TMG/Security expert at Enfo Zipper for great feedback!)

Two links will tell you all you need to know:

8.2.1 DisableLoopbackCheck & SharePoint: What every admin and developer should know. (Spencer Harbar explains it all)

8.2.2 http://support.microsoft.com/kb/896861 (the best KB out there, it is old but still relevant)

Back to main menu

9. Resources and Recognitions

Don’t know who the author is, but this article gave me the last piece in the https puzzle.

How to Create a Self Signed Certificate in IIS 7

My thanks to the following individuals who have in different ways helped me in my ambitions to create these guides on difficult subjects for SharePoint:

Anders Janson (Enfo Zipper) Thanks Anders for very good and constructive feedback!
Hasain Alshakarti (TrueSec) Blog
Mattias Gutke (Enfo Zipper)
Anders Grönlund (Enfo Sweden)
Andrija Marcic (Microsoft)
Mattias Karlsson (Microsoft)
Herakles (Unknown)

Back to main menu




Twitter | Technet Profile | LinkedIn


Anonymous Authentication always on in SharePoint 2013

Hi friends.

Anonymous access is default on in SharePoint 2013, even if you select No?

First, remember, this is all just a reflection made by me and most likely, there is some obvious reason as to why this is, that simply just eludes me at this point. I know that SharePoint does not in itself allow Anonymous access, that has to be configured, but IIS allows it which seems to me like a bad idea.

I noticed this disturbing thing this morning when I created a Quick Web Application in a SharePoint 2013 test farm of mine running on Windows Server 2012. Thing was, I created a web application from the Central Administration GUI and selected all the quickest options, Default Everything but to use an existing Application Pool. This means that we select Windows Authentication, NTLM only and NO Anonymous access.

Let me explain…
On a SharePoint 2013 farm running on Windows Server 2012:
I created a normal Web Application using only the Central Administration GUI. I used port 2013 just to show where it is, then default on all security settings.

Like this:

I seelcted to use an existing Application pool to save time and Resources, but that is not relevant. Ok to create:

Next I checked what was actually done in IIS, from the preview I remebered having some questions on how this was performed…
In IIS 8.0 on Windows Server 2012 it looks like this:

Notice how 4 providers are enabled by SharePoint as default.
Anonymous Authentication
ASP.NET Impersonation
Forms Authentication
Windows Authentication

These are all enabled by default, Windows Authentication has only NTLM configured like we selected in CA. We also get a warning from having Forms Based authentication(redirect) and Windows Based(Challenge) enabled at the same time. IIS does not like this but I have managed to find out that this is ok, given certain circumstanses you need it to be this way.

If we do the same thing on a SHarePoint 2010 farm running on Windows Server 2008R2 and IIS 7.5:

We select to use NTLM and to not allow Anonymous, same as in 2013.

The settings in IIS:

And the list of providers look like this:

Like you can see, SharePoint 2010 only enables ASP.NET Impersonation and Windows Authentication.

If we put the two up side by side, it looks like this:


The question is, does this affect security in any way?
Is it still as secure?
Why not simply disable Anonymous Authentication?

If anyone has any good suggestions or explanations, please submit them as a comment and I will update this post to reflect the facts.


A really good link that explains the inner workings of claims based authentication in SharePoint, valid for 2010 and 2013 alike.
(Thnaks nojanaj for the tip)

Multiple Authentication Methods in SharePoint 2010




Twitter | Technet Profile | LinkedIn

Whitepaper: The final guide to Alternate Access Mappings

This 45 page Guide is now available as a Free PDF download from Microsoft Technet Gallery.
Download : The final guide to Alternate Access Mappings

A preview of the whitepaper:




Twitter | Technet Profile | LinkedIn

The first Kerberos guide for SharePoint 2013 technicians

Last update: June 5, 2013
Updated 2012-12-08 – New note added to Step 3. Delegation
Updated 2012-12-11 – New note added to Step 4. Authentication Provider
Updated 2012-12-25 – New link added to Skip all the talk and get straight down to business
Updated 2013-02-14 – New update added to Step 4. Authentication Provider – ignore step 4.18, 4.19 and 4.20.
Updated 2013-05-14 – New note added to step 5.6
Updated 2013-06-05 – Added some t-shooting links after step 5.11

This is obviously an extension to ‘The final Kerberos guide for SharePoint technicians‘ published previously. As I was making that post and collecting material and Pictures, verifying the functionality, I was beginning to wonder if such a guide would be applicable in the same way to SharePoint 2013 as it is to SharePoint 2010, after some quick research I found out that it is. Using the SharePoint 2013 preview installed on Windows Server 2008 R2 with a 2008 R2 Active Directory and SQL Server 2008 R2, the steps are the same (almost).


(Herakles and Kerberos)

I came upon a few ‘snags’ that took me a while to figure out, but part from that, all is similar to how it is in SharePoint 2010. So, good for me, I only have to update Everything, not re-learn the whole thing!
As help in the task of writing this post, I had nothing…its still pretty empty for SharePoint 2013 on the topic of Kerberos and authentication (a few references added at the bottom section of this post), no doubt that will change as we get closer to launch but today, it was a void waiting to be filled. So, take it as is, this is built solely upon the preview bits. Use the 2010: The Whitepaper (242 pages) as reference, most of it is still valid.
Ok, enough talk, lets get down to business:

‘The first Kerberos guide for SharePoint 2013 technicians’

This time, I will try and get back later and add a scenario involving Windows Server 2012 and SQL Server 2012. Not that the SQL server will make much or any difference here, but the server environment will. Perhaps I’ll even have a brand new AD to work with based on 2012.

Scenario 1 – Basic

Kerberos authentication to SharePoint 2013 site on default port 80 with a single SharePoint Web Server(Windows Server 2008 R2) from Windows 7/2008R2, IE 9. (using Basic delegation/Unconstrained delegation)

(This guide assumes that a normal NTLM authentication to the same Web Application with the same user has been verified, by adding this line I’m among other things taking AAM and site permissions out of the equation. These things have to work before attempting to use this guide)

Note: To perform some of these procedures, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory and you have to be a member of the Farm Administrators Group in SharePoint, or you must have been delegated the appropriate authorities. As a security best practice, consider using ‘Run as’ when applicable to perform these procedures.


Step Summary
1. Name Resolution An entry for the Web Applications URL must exist in either DNS or in the clients hosts file.
2. Service Principal Names HTTP SPN’s must be created for the Web Application URL(s) and its Application Pool service account.
3. Delegation The SharePoint Web Server must be ‘Trusted for delegation’ in Active Directory. (Note added 2012-12-08)
4. Authentication Provider The 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! Unless, see links at the end of step 5.)
References and Credits

If you do need assistance on configuring ALternate Access Mappings or https/SSL, use any of these links:
A guide to Alternate Access Mappings Basics in SharePoint 2013
A guide to https and Secure Sockets Layer in SharePoint 2013
The final guide to Alternate Access Mappings (Free Download)

Step 1

Name Resolution

There are two ways to do this, one excellent and one less excellent, the lesser of the two is really only ‘allowed’ for developing or testing purposes, but it exists and should be taken into consideration. Testing is also something that you will want to do here, and the less modifications you must do that requires a service down or a (Service Management) change order at an early stage, the better. Use Hosts for testing, then DNS in production.


Make sure that the URL of the Web Application has a A-Record in DNS, if not, you need to create it.

A server that is joined to an Active Directory Domain gets a A-record created automatically, but verify that it is there.

Create a A-Record in DNS using the following:

1.1 Open DNS Management in Administrative Tools on a DNS server.


1.2 Expand forward lookup zones container.


1.3 Right click on the zone (domain name) and click on new host (A or AAAA).


1.4 Type in the name of the record, this is the URL of the Web Application (minus the domain part in a FQDN) and type in the IP address of the SharePoint 2013 Web Server


1.5 Click on ‘Add Host’

1.6 Click on ‘Done’

1.7 You will see this verification dialog:


1.8 Verify that the record has been created in the right pane.


1.8 Just to be sure, do a flush of the DNS cache, to do this, type:
Ipconfig -flushdns (hit enter)


1.9 In a Command Prompt, ping the Web Application URL.


1.10 You are now done with step 1, Name Resolution. Move on to step 2. Service Principal Name(SPN).

Note: A known issue exists with some clients (IE7 and IE8 included) that causes kerberos authentication to fail with the use of DNS alias instead of an A-Record.

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:\Windows\System32\Drivers\etc\hosts. 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-Address<tab>hostname/FQDN <enter>

– Example: sharepoint2013

– Also add any FQDN’s needed, like in my example: sharepoint2013.corp.balkestahl.se

Note: Always end the last line with a Linefeed/Enter, else you may experience issues using the hosts file.


1.x3 Example of how the file could look above…Save the file using the same filename(hosts only, no extension)

You are now done with step 1, Name Resolution. Move on to step 2. Service Principal Name(SPN).
Back to main menu

Step 2

Service Principal Name(SPN)

Note: To perform these procedures, you must have membership in Domain Admins, Enterprise Admins, or you must have been delegated the appropriate authority. For information on delegating the permissions to modify SPNs, see Delegating Authority to Modify SPNs.
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’.

When creating or setting up your SPN’s, you need some basic information first, as you will be creating HTTP SPN’s you need a URL and a Service account name. If the SharePoint Web Application has both a NetBIOS name and an FQDN, then you need to create separate SPN’s for both.

2.1 Start by opening a Command Prompt ‘Running as administrator’ (See note at the start of this step 2)


2.2 Next, list all SPN already in Place for the Service Account, type:

setSPN -L domain\serviceaccount (hit enter) or without the domain name setSPN -L serviceaccount (hit enter)

Wait for it…


Most likely, you get back nothing. This is ok. If you do get some registered SPN’s back, just make sure that they are not the same as the ones you are about to add, if they aren’t they you can leave them be.

2.3 Next, we create our own SPN’s for the service account paired with the Web Application and SPN type, to create this SPN type:

Note: Do not configure service principal names with https even if the web application uses SSL

setspn -S HTTP/mywebappurl domain\serviceaccount (hit enter) Note: HTTP can be upper or lowercase, does not matter.


2.5 Now we also have to add an SPN for the FQDN, type:

setspn -S HTTP/mywebappurl.domain.com domain\serviceaccount (hit enter)


2.6 Listing the SPN’s now should list one additional SPN, type:

setspn -L domain\serviceaccount (hit enter)


If Everything has gone well and you had no previous SPN’s created from this service account, then the result from the command will be:


Note: You see in the Picture in addition to the 2013 SPN’s, my SPN’s created for the SharePoint 2010 server, that farm uses the same service account, corp\spwebapp and thus the SPN’s are still registered to it. Those two extra SPN’s do not in any way affect this service. Leave them be and we will be fine.

The necessary SPN’s have now been created successfully and the service will be able to request tickets in your name.

Note: Using the -S parameter with setspn when creating an SPN will check for duplicates before creating a new one, thus eliminating the risk of duplicate SPN’s, which would cause Kerberos to fail.

You are now done with step 2, Service Principal Name(SPN). Move on to step 3. Trust for delegation.
Back to main menu

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)

Change this setting in Active Directory using the following:

3.1 Open Active Directory Users and Computers.

3.2 In the console tree, click Computers. (Or the appropriate OU where your SharePoint Web Server resides)


3.3 Right-click the computer you want to be trusted for delegation, and click Properties


3.4 On the Delegation tab, click ‘Trust this computer for delegation to any service (Kerberos only)’.


3.5 Click OK.

You are now done with step 3. Trust for delegation. Move on to step 4. Authentication Provider.
Back to main menu

Step 4

Authentication Provider

(Added 2012-12-11) Update: In response to several comments, the steps 4.18, 4.19 and 4.20 can be ignored, these steps are not required and can be disregarded. IIS will show a red warning but this is what SharePoint does and it works even with FBA enabled. So, if it works with FBA enabled, leave it on.
See references section at the end of this post for a link to a really good explanation to how claims based authentication in SharePoint works.
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.

In order for the Web Application and SharePoint to use Kerberos instead of the default NTLM, we have to configure SharePoint to use just that. Unlike what many Think, there is no way to force SharePoint to use only Kerberos, what we have available is the option to use Kerberos if possible, else use NTLM. Don’t ask me why this is so, but this is what we have. However, if all of the Kerberos Components are configured correctly, this is what will be used for authentication at all times.

So…the last configuration Before testing it all out…configure SharePoint to use Kerberos using the following:

4.1 In the Central Administration, go to ‘Application Management’ – ‘Manage Web Applications’




4.2 Select the Web Application you want to configure, and click on Authentication providers in the top ribbon.


4.3 In the ‘Authentication Providers’ dialog, click on the authentication provider you want to alter, usually its default.


4.4 In the ‘Edit Authentication’ dialog, verify that ‘Claims Authentication Type’ is set to: ‘Enable Windows Authentication’ and ‘Integrated Windows authentication’ In the dropdown, select ‘Negotiate (Kerberos)’.


4.5 Scroll down the dialog to ‘Save’ / ‘Close’. Press Save and wait…you will not see any progress…


4.6 Sit here until you feel that you have waited long enough and that the save MUST be done.

4.7 Click on Cancel(?!)

You have now made the modifications needed in SharePoint for Kerberos authentication to function, now we have to verify that the Changes has been made to IIS by SharePoint.

To verify the IIS Web Site Authentication settings, follow these steps:

4.8 In Internet Information Services (IIS) Manager, locate the Web Application under ‘Sites’.


4.9 Select the Web Application and in the middle pane under the heading ‘IIS’, locate ‘Authentication’

4.10 Select the ‘Authentication’ Icon and in the right ‘Actions’ pane, clikc on ‘Open Feature’.


4.11 In the Authentication dialog, select Windows Authentication (usually at the bottom).


4.12 Click on ‘Providers’ in the right ‘Actions’ pane.


4.13 Verify that ‘Negotiate’ and ‘NTLM’ are the only ones listed and that they are listed in that order, ‘Negotiate’ at the top.


4.14 Click Cancel and then again in the right ‘Actions’ pane click on ‘Advanced Settings’.


4.15 Verify in the ‘Advanced Settings’ dialog that ‘Extended Protection’ is ‘Off’ and that ‘Enable Kernel-mode authentication’ is unchecked.

4.16 Click Cancel.

4.17 IIS will warn you that this is disabled, but SharePoint disables this setting because of a ‘feature’ in IE8 that may prevent them from connecting. Do not follow their advice this time…


4.18 (DISREGARD THIS STEP – See note at beginning of step 4. added 2012-12-11) I noticed here as well, after some trial and error, that SharePoint 2013 for some reason enabled ‘Forms Authentication’ for the my Web Application in IIS, when both are enabled, you will never be able to access the site.


4.19 (DISREGARD THIS STEP – See note at beginning of step 4. added 2012-12-11) I even got a Little error about it in the top-right pane:


4.20 (DISREGARD THIS STEP – See note at beginning of step 4. added 2012-12-11) Important! Disable the ‘Forms Authentication’ if it is enabled:


4.21 Exit Internet Information Services Manager.

You are now done with step 4. Authentication Provider. Move on to step 5. Verification of functionality.

Note: DO NOT make any Changes using the Internet Information Services Manager, if Changes need to be made, Always use the SharePoint Central Administration interface.
Another way to make changes to SharePoint is PowerShell, which is also a recommended way if you really know what you are doing.

Back to main menu

Step 5

Verification of functionality

Many Tools exist that can be used to verify that Kerberos authentication actually occurs, Tools such as NetMon(Network Monitor), WireShark, Fiddler, KerbTray and many more can be used for this step. I have however focused on two Tools that will be sufficient and that exists already in the Environment. I have chosen to focus on these two:

Klist (Client)

Security Log (Server)


(Klist is available on Windows server 2008 and later and on Windows 7 and later, for Windows Server 2003, see note at the end of this step)

Before anything, Close down all open Internet Explorers or other browser sessions you have open.

5.1 On the client, start a command prompt as administrator (Right click, ‘Run as administrator’).


5.2 Flush the DNS cache, type:
Ipconfig -flushdns (hit enter)


5.3 List all tickets on the system, type:
klist (hit enter)
Note: this does not affect any other functionality on the client or server

The tickets listed does not necessarily have anything to do with us at this point (SharePoint).

5.4 Now, we want to clean up this list so that we can see if a new ticket is granted to our user when logging on to SharePoint.

Clear the list, type:
klist purge (hit enter)
Note: this does not affect any other functionality on the client or server

In the prompt you will see:

Deleting all tickets:

Ticket(s) purged!


5.5 Try again listing all tickets, type:

klist (hit enter)


This time the list should be empty. (if not, then some service has managed to connect again during the time from that you purged until you ran Klist again)

5.6 With an empty Kerberos ticket list, open up a new Internet Explorer session and go to the URL of the Web Application.
Note: You cannot start a browser as a different user, if you do, the tickets will not be available to the klist command for the logged on user.

5.7 When authenticated and logged into the site, all loaded ok


5.8 Switch back to the command prompt and again, type:

klist (hit enter)

Now, with Kerberos working, you will see two tickets, the most important one is the second ticket(#1) that contains:

Client: username@domain.com

Server: HTTP/mywebappurl

KerbTicket Encryption Type:

And a few timestamps and similar stuff. This is good!


If you see this ticket, things are working! Now, all we have to do is verify that it looks good on the Web Server as well.

Close down the Command Prompt and move on to the next task in this guide, the security log.

Note: For Windows Server 2003, KLIST is available as a free download in the Windows Server 2003 Resource Kit Tools. To obtain the tools, visit the following Microsoft Web site: Download Klist here

Security Log

Note: Before checking for events in the eventlog, you may want to verify that your server is logging authentication success, else you will not see the event ID 4624 in the Security Log of your Web servers.
You will find the Group Policy at ‘Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy > [Audit logon events], make sure this is set to ‘Success’.
(Thanks to Alvar Kresh for sharing this important note)

Verify that the Web Server Authenticates the user using Kerberos using the following:

5.9 On the SharePoint Web Server, in Administrative Tools, open up Event Viewer.


5.10 Expand the ‘Windows Logs’ container and locate the ‘Security’ Log.


5.11 In the Security log, locate a recent event with the ID of 4624. This event should be a successfull logon, and hold the security ID and accountname of the user that accessed the SharePoint Web Application using Internet Explorer on the client, and it should also state:

Logon process: Kerberos

Authentication Package: Kerberos.


If you can verify that you do have this event, then you are done, Kerberos works!

You are now done with step 5. Verification of functionality, there are no more steps from here…

This means that if you have successfully completed all steps in this guide, you have managed to configure Kerberos for SharePoint 2013.

If Kerberos authentication fail with an error, then you may experience that authentication does not fall back to NTLM at all. It simply fails. There are a few reasons why this can happen and you may want to keep this in mind just in case.

Related links:
Problems with Kerberos authentication when a user belongs to many groups
“HTTP 400 – Bad Request (Request Header too long)” error in Internet Information Services (IIS)
Users who are members of more than 1,015 groups may fail logon authentication
Group Policy may not be applied to users belonging to many groups

Back to main menu

Thanks to, for technical and spiritual support!

Hasain Alshakarti Truesec

Mattias Gutke Enfo Zipper

Anders Grönlund Enfo Sweden

Markus MurrayTruesec



Plan for Kerberos authentication in SharePoint 2013

Plan authentication in SharePoint 2013

Plan for user authentication methods in SharePoint 2013

Setspn (Windows Server 2008, Windows Server 2008 R2)

Klist (Windows Server 2008 R2)

DNS Server Overview (Windows Server 2008)

Trust for delegation (Windows Server 2003 but this still goes)

How the Kerberos Version 5 Authentication Protocol Works

Kerberos Explained (old but still good)

Microsoft Kerberos

Multiple Authentication Methods in SharePoint 2010
(A really good link that explains the inner workings of claims based authentication in SharePoint, valid for 2010 and 2013 alike.)

Kérberos (lat. Cérberus)




Twitter | Technet Profile | LinkedIn