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. |
Checklist:
| 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.
DNS
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:
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. |
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:
HTTP/mywebappurl
HTTP/mywebappurl.domain.com
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. |
–
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
(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://support.microsoft.com/kb/327825
“HTTP 400 – Bad Request (Request Header too long)” error in Internet Information Services (IIS)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;2020943
Users who are members of more than 1,015 groups may fail logon authentication
http://support.microsoft.com/kb/328889/
Group Policy may not be applied to users belonging to many groups
http://support.microsoft.com/kb/263693/
CONGRATULATIONS!
Back to main menu
–
Thanks to, for technical and spiritual support!
Hasain Alshakarti – Truesec
Mattias Gutke – Enfo Zipper
Anders Grönlund – Enfo Sweden
Markus Murray – Truesec
Herakles – Unknown
–
References
Plan for Kerberos authentication in SharePoint 2013
http://technet.microsoft.com/en-us/library/ee806870(v=office.15).aspx
Plan authentication in SharePoint 2013
http://technet.microsoft.com/en-us/library/ee794879(v=office.15).aspx
Plan for user authentication methods in SharePoint 2013
http://technet.microsoft.com/en-us/library/cc262350(v=office.15).aspx
Setspn (Windows Server 2008, Windows Server 2008 R2)
http://technet.microsoft.com/en-us/library/cc731241(v=ws.10).aspx
Klist (Windows Server 2008 R2)
http://technet.microsoft.com/en-us/library/hh134826(v=ws.10).aspx
DNS Server Overview (Windows Server 2008)
http://technet.microsoft.com/en-us/library/cc770392(v=ws.10).aspx
Trust for delegation (Windows Server 2003 but this still goes)
http://technet.microsoft.com/en-us/library/cc739764(v=ws.10).aspx
How the Kerberos Version 5 Authentication Protocol Works
http://go.microsoft.com/fwlink/p/?LinkID=196644
Kerberos Explained (old but still good)
http://technet.microsoft.com/en-us/library/bb742516.aspx
Microsoft Kerberos
http://msdn.microsoft.com/en-us/library/aa378747(VS.85).aspx
Multiple Authentication Methods in SharePoint 2010
http://shpt2010.wordpress.com/2011/11/10/multiple-authentication/
(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)
http://en.wikipedia.org/wiki/Cerberus
_________________________________________________________
Enjoy!
Regards
blksthl 
This didn’t work for me unless forms based authentication was enabled in IIS
and it did not issue a ticket.
Hi Candice.
Most likely, you have missed some step, I have verified that the steps work. If you must have FBA enabled, are you really using WIndows Authentication then(Classic)?
My guide does not cover every possible situation, only the most basic. In that scenario, it works. COuls it be that you have skipped a step or assumed some configuration?
Regards // Thomas
This happens if the web application you’ve created is claims based and not windows auth. If you create the web app in central admin it defaults to claims based.
Use this powershell command and it should be fine:
New-SPWebApplication -Name “SharePoint – 80″ -ApplicationPool ” SharePoint – 80″ -AuthenticationMethod “Kerberos” -ApplicationPoolAccount (Get-SPManagedAccount “Contoso\svcSPappID”) -Port 80 -URL “http://Contoso” –DatabaseName “SP2013_80”
Good Point Erik! I will try to add some text on the different Auth options as well.
Since this guide is for 2013, it should primarily support claims…the new default.
Problem is though, if I were to cover every combination, the guide would grow humongous…
Thanks
Regards
// Thomas
@Candice Same for me, doesn’t work unless Forms Auth is enabled in IIS
I followed all these steps, starting with a 2013 site collection where NTLM was working correctly. I got through all of them and confirmed I got the two tickets with the correct information and the event viewer messages as well. But when I go back to my site, I now get the message that “this site hasn’t been shared with you”, where as it was a few minutes earlier with NTLM.
I have restarted IIS and can see the sucessful event log messages when I make a connection, but still get the same message about not being able to access my site. I even re-did the site administrator settings. And I have redoine it again just to be sure with no luck.
Any ideas? I would love to get this working. I’m sure its something in my environment I’m overlooking.
Hi.
I’ll give it some thought and get back to you, ok.
Are you accessing from the server or from a client?
Is the url in IE’s Local intranet zone?
Rgds // Thomas
Hi,
I have the exact same issue > get the message that “this site hasn’t been shared with you”, where as it was a few minutes earlier with NTLM.
Any ideas?
Best,
Jeff
the delegation settings are never required for end user authN
Oh yes, maybe you have an answer regarding if and if so, why, FBA has to be enabled in IIS for kerberos auth to work in 2013/IIS8?
I did not need it but others have reported that they can get it to work without it…
Thanks
// Thomas
Hi Spencer. Thanks for the comment.
I Added a note on that.
Regards
// Thomas
I do not understand why we have to disable the Forms Auth. on IIS… I’ve built my DEV farm without disabling it, and I do not have any ill effects, also if I am not mistaken Microsoft documentation doesn’t mention of this.
Hi Ali.
Thanks for your feedback, I have added an update about this to the post. This can be different from IIS7.5, IIS8.0, Preview and several other combos, but if it works with it on, let it be on.
You will if I’m not mistaken however, see the red warning telling you that they can’t both be enabled? 4.19
Regards
// Thomas
I do not remember the Red warning. But I’ll double check when I get a chance. And as a note: I was working in RTM version, may be something is different than Preview, Beta etc. Regardless, thanks for the guide and the post!
Hi. You’re welcome. If you have any more feedback, let me have it 🙂
// Thomas
Hi Thomas
Thanks for the guide, it was a great help.
I am unable to get a kerb ticket on my client (Windows 8 with IE10)
I can however confirm that I am using Kerberos on the web servers Security event log with the 4624 event using the kerberos Logon process with my username when I access the site.
would it be safe to assume that kerberos is working?
I have installed Central Admin in Kerberos mode and it works, as well as made sure that my Web application is in kerberos with claims mode authentication.
If I disable Forms authentication, I can only get it to work by installing the web application in Windows mode, not claims mode.
Even with adding the site to the Local intranet zone, I still get the access denied page with FA disabled. If I enable FA (yes I get the red Challenge-based warning in IIS) in claims mode then it works.
Only thing I am missing is the kerb ticket on the client?
Hi Leigh.
Thanks for your feedback, I hope that the guide helped you.
What you say about FA is true, I have been told Before and verified this myself, if you have a look at the Note at the beginning of section 4, you will see that you can ignore those steps. I realise that this was not clear enough so I will make it even more clear so that you are the last one to have to make that mistake.
Best regards
// Thomas
Leigh, I am having this exact same issue (Windows 8, IE10). The SharePoint server says that the user did use Kerberos but klist is empty on the client.
Thomas
You are the MAN! this article is by far the best most applicable for this topic I have ever seen! I intend to use this as the standard in my organizations system sustainment SOP documents. Thank you so much for making somthing that has been so complicated and hard for me to understand how to impliment so easy to learn and execute!
Hi Nathan
Thanks for the feedback! I can go a long way on comments like this!
Glad that I could help make your life a little easier.
Regards
// Thomas
Thanks for post, but if you are enabling delegation you also need to enable it on the application pool identity that corresponds to the web application. In your example, that would be corp\spwebapp. If you don’t, things won’t work in a multi-web front-end farm. This may already have been done, since you stated that the account is already running a previous farm, but it is important to show it in the guide.
Hi Eugene.
Thanks for the feedback. I’ll think about adding a note about that, but the thing with this guide is, and that is the thing that makes it possible to comprehend, that it does not cover every possible scenario. I’ll leave that for someone else to cover 🙂
The TechNet SharePoint Kerberos paper(see references) does a good job, thats 240 pages long…
But, you have a valid comment and it will be easy-isch to fit in the format.
Regards
// Thomas
Thomas,
I’ve setup a test SP2013 server and really appreciate your post. I have it working, but have a question about SPN. Our agency name changed so we created an SPN for users to login with the new FQDN. Let’s say the internal domain is test.local and we added the SPN new.org after our new agency name. When I follow your SPN instructions above do I need to create an SPN record for test.local or new.org or both? I created it for both and when I run klist it shows both. When people access this site it wll be https://sharepoint2013.new.org/sites/Home. Which spn do I need?
Carlton.
Hi.
You will nerd an SPN for every URL/FQDN that will be used to access.
So, if both are ever used from anyone, then I recommend setting up SPNs for both.
Regards
// Thomas
Hi,
Thanks for the post. I setup Central Admin site first for Kerberos based on this post, and it worked great. Next, I created the main web app and site collection for port 80, and was not authorized to login.
The question is: should the same farm service account be used for both application pools’ IDs, as Microsoft recommends, for Kerberos to work? For my case, the farm service account, with access to the database, was SPN subscribed an worked for Central Admin, but doesn’t work for the main site collection. The SPN is enabled for both the main url and the Central Admin port, fully qualified and not.
Could it be that only one application pool can be Kerberos enabled on one specific server?
Thanks,
Radu
Hi Radu.
No, you can have many different web applications running under different application pools on the same server and still have kerberos.
You will need to create a separate SPN for the two accounts, both for HTTP and with the appropriate URL’s. Use -S which will check for doubles before creating the SPN.
If kerberos fails, then you should check if you have any events in the security eventlog like I describe in the post.
Most likely, if authentication does not fall back on NTLM like it should, then it is because of an issue with something regarding that particular account. It could be that the account is a member of too many Groups in AD.
Check this KB: http://support.microsoft.com/kb/327825
You should also try using the same account that works for CA, if that works, then you know it is related to the apppool account. You should in my opinion use separate accounts for the two web applications but functionality with kerberos may trumph that…
Try that and get back if you still experience difficulties.
Best regards // Thomas
Thanks, Thomas; I made it work by using a different account on the port 80 main site app pool vs. Central Admin app pool. It looks like I didn’t have to add this new app pool account to an SPN since Kerberos is using the same farm service account to reach the database as the Central Admin app pool (same acct. that owns the SP dbs on SQL Server).
However, from a security framework principle, and going back to Candice’s point above, I created the site collection at the command line without specifying an authentication method. As expected, Claims has been implemented as an authentication provider by default. Then I removed all other authentication methods in IIS for this site (as almost all are enabled by default), besides Windows Auth, which resulted in Kerberos working but login popup windows showing up at times. Enabling forms authentication got rid of the login pop ups and everything is fine.
I did it this way, i.e. Claims Based Authentication, given the multitude of Microsoft documentation mentioning that Claims have to be used in order to take advantage of server-to-server connectivity services enabled in SharePoint 2013 as well as other protocols using OAuth to authenticate apps (based on the same, first reference you list above).
Is anything really wrong with allowing forms authentication be enabled as I have it now so that Claims works elegantly, e.g. with no login pop up windows? I am still confused about the relationship between Claims as a provider, Kerberos as a security protocol, and Forms; a lot of the documentation seems to compare Claims with Kerberos, but these are two different things – as far as I understand now since a Kerberos ticket is produced immediately at sign on time, without even prompting for a login so it is being used with Claims. (FYI, I am setting up an enterprise intranet for now – no network access to internet, and am looking for the best scenario to use Office Web Apps, Exchange 2013, and eventually other server-to-server services).
Thanks again,
Radu
Hi Radu.
Glad to hear that you got it working without compromising in security. You should perhaps take a look at this link for starters, it gives a good explanation on the inner workings of claims. It’s 2010 but its still a good piece of eye-opener.
Read that and then try and find the best info on 2013/kerberos/Claims.
Good luck
Regards // Thomas
First, very informative article. Second, I am not able to get klist to show anything after a purge. Does this mean that the ticket was not issued? On the SharePoint server, I see that my user account did logon via Kerberos (via Event ID 4624). Is that normal behavior?
Hi Hayden.
I’m not 100% on W8 and IE10, but in your case since IIS reports successful kerberos authentication, then I would assume its working.
For Klist, I also assume that a ticket should be visible in W8 as well as in W7 or W2K12, the times Klist have shown different from the server had been when you are using different users IE/Klist or if that user is lacking in permissions to list the tickets.
Is that any help?
Regards // Thomas
I have had the same behavior after a purge before. It was on w7 and IE8. I saw IIS event 4624 and I moved on, hoping that it is ok.
Yes, that’s enough to satisfy me. The Event ID shows successfully on the SharePoint server for the user in question. I just can’t seem to get klist to populate the ticket on the client.
Can anyone point us a 3 tier example? We are having a hard time getting SSRS reports from our WFE through our APP(CA) server on to our SQL/SSAS server. From a 2 tier standpoint, everything mentioned here, we had setup. Unfortunately, our tickets are created on a WFE which did not match up to this guide, IIS wise. Steps 1-4 were nearly identical. The difference being that we setspn for quite a few things. Still, those additional services aside, simply loading up the home page from the WFE did not create any tickets according to klist.
If anyone gets 401 unauthorized errors, then try confugre AAM.
Because it’s such a pain, coworkers and I (SP consultants) wrote health analyzers to identify problems and provide recommendations. They were written for 2010, but should still be relevant for 2013.
http://sdssharepointlibrary.codeplex.com/wikipage?title=Health%20Analyzers%20for%20Delegation&referringTitle=Documentation
Hey Scott.
Reall nice actually, had a look at codeplax and it looks really good. A pretty good idea!
Regards
// Thomas
Hi Thomas,
I have few doubts, Please clear my doubts as below.
1) Can we able to use Kerberos authentication for those user which are outside the domain or Internet facing site? If yes please let me share the proper steps.
2) Can put Claims authentication and windows authentication together?
Regards,
Ravi
Hi Ravi.
I’ll try and answer best I can…
1. Yes and no, you can use kerberos on the internet, its not the best option but it will work. However, the users will have to be in an Active Directory domain since AD is what hosts the KDC and makes kerberos possible in a SharePoint Environment.
2. Yup, no problem. Read this:
http://technet.microsoft.com/en-us/library/ee806870.aspx#section2
Hope that helps?
Regards
// Thomas
Sorry, for the second, I read Windows with kerberos…
2. Claims with Windows works just fine.
Select ‘Enable Windows Authentication’ and either NTLM or Negotiate(which is the same as kerberos)
Rgds
// Thomas
Hi Thomas,
Can we put Cliams authentication and Kerberos authentication together on same site ?
Regards,
Ravi
Ok, there it is 🙂
See: http://technet.microsoft.com/en-us/library/ee806870.aspx#section2
No problem, yes! For internal use, an excellent choice.
Regards
// Thomas
Hi Thomas,
one more question.
1. Can we put Kerberos authentication for internet facing site for few users. if yes please share the steps to configure.
It would be great help for me.
regards,
Ravi
Hi.
You can, the users will have to be in an Active Directory domain though.
Depending on what is accessed from SharePoint, kerberos can be configured like in the guide. Add delegation if other Resources are accessed from SharePoint, like SSRS or similar that requires a double-hop scenario.
Rgds
// Thomas
Hi Thomas,
Thank you for quick reply. I followed your guide and I am able to do kaerberos authentication for one user please share the steps for more than one user who will access the SharePoint site dashboard over Internet . and How it will work for other NTLM user?.
Also please guide about double-hop scenario in detail and it would be work in my scenario.
Regards,,
Ravi
If one user works, all users will work.
Regarding the double hop scenario, read this to start with:
http://www.thesharepointblog.net/Lists/Posts/Post.aspx?ID=43
Its 2010 but is very much valid still. For the detailed steps and explainations, check the MS guide:
http://www.microsoft.com/en-us/download/details.aspx?id=23176
Regards
// Thomas
Hi Thomas,
Sorry, but I am little confuse please guide. I have used farm account for Kerberos authentication, but when I try to login with other user its give me error this site is not shared with you. so I have given access to that user in SharePoint site then that user able to login in site but when I checked the eventvwr I didn’t get any entry related to that user.
So my question is need to repeat the “steps 2.2 Next, list all SPN already in Place for the Service Account, type:” for each user is It right?
Highly descriptive post, I liked that bit.
Will there be a part 2?
Hi Elton.
Thanks!
That was the original plan, any preferences on what to cover? Any favorite scenario?
I Think that an update of this one is in Place as well.
Regards // Thomas
Hello there! This is my first visit to your blog! We are a team of volunteers and starting a new project
in a community in the same niche. Your blog provided us useful information to work on.
You have done a marvellous job!
Hi everybody,
Environment : Windows Server 2012 R2 + SharePoint 2013 SP1
I wanted to enable Kerberos for Central Administration Website on the port 40000. I created two SPNs :
SetSPN -S HTTP/FQDN:40000 Domain\SPFarmServiceAccount
SetSPN -S HTTP/Netbios:40000 Domain\SPFarmServiceAccount
I follow all this tutorial (Very well done 🙂 Thanks a lot by the way !)
But unfortunately I could not make it runs….Certainly because of my environment.
After many trials, it only works for me if I enable Kernel-Mode Authentification in “IIS / SItes / SP Central Administration v4 Website / Authentification / Windows Authentification / Advanced Settings”.
Does any one get the same issue ? And most important any idea why ?
Cheers,
AK
Hi.
Thanks for the feedback.
No, no idea why, do you mean that it is not sufficient to switch to kerberos in the CA gui? You have to change it in IIS?
Regards
// Thomas
Hi Thomas,
Environment : Windows Server 2012 R2 + IIS 8.5 + SharePoint 2013 SP1 + IE11
I was just making a reference to your advice in this tutorial about not enabling “Kernel-Mode Authentication”. You said that SharePoint disables this setting because of a ‘feature’ in IE8 that may prevent them from connecting.
=> If I do that, I cannot authenticate on the Central Administration Web Site from a remote computer, that why I had to enable it to make it works.
From Microsoft : As a best practice, you should not disable this setting if you use Kerberos authentication and a custom identity on the application pool. (This is exactly My situation !)
Source : http://technet.microsoft.com/en-us/library/cc771945.aspx
Does someone come across with the same issue on is environment ? Or did I misconfigured something ?
Thanks,
AK
Hi Alvar.
The circumstanses change, in this case, you have a different IIS version so it may be different, but from Before, you had two ways of avoiding this issue, see this link and scroll down to part 5. There you have a way to have kernel mode AND kerberos working.
http://stevekay72.wordpress.com/2013/02/13/kerberos-setup-for-sharepoint-2013/
Regards
// Thomas
One more thing, you don’t see SharePoint mentioned anyware in that article do you? 🙂
(We’re special…)
Regards
// Thomas
Just for information, if you cannot see the event ID 4624 in the Security Log of your APP or WEB SharePoint Servers…
Do not forget to set the Group Policy “Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy > [Audit logon events] Policy” to “Success”.
Regards,
AK
Thanks AK. A very valid Point!
I’ll try to get time to update the post.
Regards
// Thomas
Hi again. Added a note on this, with creds to you 🙂
Regards
// Thomas
Hi Thomas,
I am doing migration from SharePoint 2010 to SharePoint 2013. We had KErberos Classic for SP 2010 and now planning to move to claims auth in sp 2013. My question is we have 2 web-applications and both are configured for Kerberos-classic auth with SPN created for the Service A/C and URL. Now when we do migration we are going to use the same Service A/C and same URL (since we are upgrading to SP 2013 and dnt want to change URLs). What would you recommend? I dont think we have to create new SPNs here as same a/c and URL is being used. But I am not sure how to test it as “A” record will exists for same URL for SP 2010, so should I just create a SP 2013 HOSTS file entry and No SPN needed since one exists for SP 2010? Can you please help me this query I am little confused on it for Migration purpose. Appreciate your help. Basically Service A/C (DOMAIN/Srv_Act1) and URL (http://docs and http://docs.mydomain.com) SPN exists for that and same would be used after migration to SP 2013, except the new Servers (Names) would be used. Can you please help.
Thanks
Hi Kets.
That should work, the SPN need to match the URLs so you should be ok with what you’ve got.
Regards
// Thomas
Trusting the computer for any kerberos service creates a HUGE security issue. You should ALWAYS specify the service you want to delegate.
Delegating an AD object for delegation to ANY service is a VERY BAD IDEA, security wise.
I would review the article, following these steps:
http://blogs.technet.com/b/scottstewart/archive/2014/04/10/kerberos-sharepoint-2013-sql-2012-for-business-intelligence.aspx
Thank you.
Claudio
Great post!
You are a life saver! We were struggling with getting rid of the NTLM authentication from our SharePoint (and the rest of the domain) and your instructions took care of it nice and clean. I just had to restart the IIS service at the end of Step 4 and it started working. I confirmed it in the Security Log.