3

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
,DC=internal
        HTTP/sharepoint
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].

Improve this question
8

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
Improve this answer
4
  • 1
    Setting SPNs for both the addresses solved my issue. Thanks very much for a very clear response :) – Geir Smestad May 31 '12 at 11:46
  • 1
    Probably the best list of "quick first things to check" that I've seen written out. Excellent post Wictor! – webdes03 May 31 '12 at 12:46
  • Thanks. Kerberos isn't hard, just as long as you take it easy and do it right :) – Wictor Wilen MCA MCM MVP May 31 '12 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 Apr 14 '13 at 19:17
3

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

Improve this answer
1
  • This tool looks promising, I'll have a look. Thanks. – Geir Smestad May 31 '12 at 7:56
0

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.

Improve this answer
2
  • 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? – Geir Smestad May 31 '12 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 May 31 '12 at 12:24
0

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

Kerberos configuration known issues

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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