Running SharePoint 2010. I need to set up Kerberos authentication, since the double-hop problem with NTLM is causing trouble with a web part I am developing.

Long story short, Kerberos authentication fails after setting it up. I followed this guide to the letter - my environment is slightly different (DC is on a separate server, not on the SharePoint server itself...WFE and Application Server are on the same box, SQL is not). The guide describes setting up two SPNs, whereas I only set up one. When attempting to open my site in the domain, I get a password dialog which does not accept my credentials. Sniffing with Wireshark, it seems the web server returns the error message KRB_APP_ERR_MODIFIED.

Different support forums have suggested a number of fixes. Some obscure ones: I have verified that IIS does not use kernel mode authentication. There do not appear to be any duplicate DNS entries. The SharePoint server's DNS cache has been flushed. The clock on my SharePoint server is synchronized with the domain.

My SharePoint server has the DNS name "sharepoint" and the domain name is "bkf.internal". My SharePoint Application Pool uses the account SP_Service. Hence I set up the SPN thusly:

C:\Windows\system32>setspn -s HTTP/sharepoint BKF\SP_Service
Checking domain DC=bkf,DC=internal

Registering ServicePrincipalNames for CN=SharePoint Servicekonto,CN=Users,DC=bkf
Updated object

Looking for duplicate SPN entries, I ran the command 'ldifde -d "dc=bkf,dc=internal" -r "servicePrincipalName=http*" -p subtree -l "dn,servicePrincipalName" -f output.txt' on the DC. Output.txt contains

dn: CN=SharePoint Servicekonto,CN=Users,DC=bkf,DC=internal
changetype: add
servicePrincipalName: HTTP/sharepoint

...so at least there aren't any duplicate SPNs.

Does anyone have any suggestions, or pointers for further troubleshooting?

[Edit: In response to webdes03, I forgot to mention it but I also activated delegation for the SharePoint server in AD...and the SQL server and the DC itself, although I got the impression it wasn't necessary].

4 Answers 4


A couple of things to check for

  • First of all - you do not need delegation yet. Wait with that until you get the log on process to work
  • make sure that the DNS name sharepoint is registered with an A record in DNS (and not a CNAME)
  • register SPN's for both HTTP/sharepoint and HTTP/sharepoint.bkf.internal
  • make sure that the account you use when setting the SPN is the web application pool account running the application pool for that web site!
  • run this setspn command to query for any other HTTP SPNs: setspn -q HTTP/*
  • Avoid any tools to configure this for you, they most often make your life miserable...
  • if you want to follow a guide, only use the "SharePoint 2010 Kerberos whitepaper" from MSFT http://technet.microsoft.com/en-us/library/ff829837.aspx
  • 1
    Setting SPNs for both the addresses solved my issue. Thanks very much for a very clear response :) Commented May 31, 2012 at 11:46
  • 1
    Probably the best list of "quick first things to check" that I've seen written out. Excellent post Wictor!
    – webdes03
    Commented May 31, 2012 at 12:46
  • Thanks. Kerberos isn't hard, just as long as you take it easy and do it right :) Commented May 31, 2012 at 15:34
  • Adding my thanks - after a day searching a re-trying it was the A record and not CNAME that fixed it for me
    – JJones
    Commented Apr 14, 2013 at 19:17

Check out the DelegConfig utility on the IIS site. Deploy this to its own IIS web site, and configure it similar to SharePoint. It will provide troubleshooting steps to verify your SPNs, etc., and see if you are getting a successful Kerberos ticket.

DelegConfig v2 beta (Delegation / Kerberos Configuration Tool) http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887

  • This tool looks promising, I'll have a look. Thanks. Commented May 31, 2012 at 7:56

Have you activated the delegation in Active Directory after running the SPNs? Additionally, you need a SPN to the service account running the web application, you're setting your SPN to BKF\SP_Service, which I'm assuming isn't a web application pool identity... looks like one of the service accounts. In a best practices environment, your web apps should have dedicated accounts.

Where are you testing the SPN? If you're logged into the WFE and it's a single WFE in the environment, then you probably need to disable the loopback.

  • Yes, forgot to mention it but I've activated delegation in AD for the SharePoint server (and a couple of others, even though I thought it wasn't necessary). I haven't done any testing of the SPNs except locating them, which was done successfully from the DC (different server) using the 'ldifde' command. You're right that one of the service accounts has somehow become the app pool identity. Could this in itself cause problems? Commented May 31, 2012 at 7:46
  • That could cause problems, if the app pool account doesn't have the right permissions to things. Have you tried JesseC's link yet. Kerberos is one of those things that's very difficult to troubleshoot, but there are a couple good tools out there. You can also use Fiddler to sniff the packets on page load and see if that double-hop is there for the negotiation.
    – webdes03
    Commented May 31, 2012 at 12:24

Make sure you also read this article as it list several issues with Kerberos authentication and how to handle them.

Kerberos configuration known issues

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.