2

I realise this might be a non SharePoint question but it might have been one that someone has encountered. I have a customer site that has a component (custom code) that use AD Kerberos delegation to work and its not for this particular site. I have found that there is a number of Kerberos errors in the event log: 

Error Code: 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN

The target name used was HTTP/portal.fqdn.blah This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server.

I have also discovered that there is a duplicate account registered for http/portal and its fqdn variant;

A check with setspn -x reveals:

setspn -X
Checking domain DC=domain,DC=sub

Processing entry 6

http/portal is registered on these accounts:
        CN=account1,OU=Accounts,OU=subou,DC=domain,DC=sub
        CN=account2,OU=Accounts,OU=subou,DC=domain,DC=sub
found 2 groups of duplicate SPNs.

Removing the duplicate 'account2' and with the site set for NTLM and Negotiate I would assume that with only the correct account 'account1' remaining that the SPN would only be able to use that account.

I have been through this article windowsecurity.com/articles/… and removed the wrong service account entry, restarted the WFE and the problem persists. I'm both entries for KDC_ERR_S_PRINCIPAL_UNKNOWN – which according to the article means there isn’t a registered SPN for the site. And the KRB_AP_ERR_MODIFIED which we see as well indicates the wrong service account is being used to access the site. So the question is how do I know when the tickets are being issues by the correct service account?

Improve this question
1
  • This problem is possibly related to some replication not happening properly in the customers domain. I will update the question if that is indeed the root cause of the problem.
    – pigeon
    Commented Feb 16, 2012 at 1:47

3 Answers 3

Reset to default
2
+50

Agree with Wictor here, with a "small" addition:

Getting an access denied does not necessarily mean sharepoint itself is denying you access.

  • It could also be a component running in sharepoint that can't access a resource and then throws the accessdenied exception. Seeing as SharePoint handles these exceptions differently, even though sharepoint itself is working, a component on for instance the page you are opening is blocking access. Could you try opening a non content page on your site, like say http://{yoursiteurl}/_layouts/settings.aspx?

  • Furthermore, simply restarting IIS is usually not enough I found. SPN's are not refreshed / reread by IIS when doing this. either do a full reboot or do a gpupdate /force and an iisreset, this forces the server to refresh any policies and related security information

As a last point, before Windows Server 2008 R2, SPN's needed to be registered 4 fold:

setspn -A HTTP/dnsname domain\user
setspn -A HTTP/dnsname.fqdn domain\user

and if url is different from the machine name (i.e. a host header):

setspn -A HTTP/machine domain\user
setspn -A HTTP/machine.fqdn domain\user

Since 2008, the machine name is an automatic "SPN". IIS will run in Kernel mode, meaning it will let the machine account (SYSTEM) handle the Kerberos delegation (so you would only need to allow delegation for the machine and not a specific account).

SharePoint does not support this. And using the 2 methods side by side with same account, or with the machine name registered as SPN to a specific account, will break Kerberos. You need to ONLY add the actual hostheader as SPN, not the machine name as well.

Improve this answer
1
  • Thanks for the clarification. I will set the answer, basically the customer has some deeper issues with DNS and AD replication within their organisation therefore the changes being made to the spn is seemingly not taking effect as it should.
    – pigeon
    Commented Feb 18, 2012 at 2:31
5

As Kjetil says you need to fix up your SPN's. This is one of the most common errors when setting up Kerberos - not having control of where your SPN's ends up and not having it thorougly documented.

Do like this to proceed:

  1. Remove the SPN using setspn -D from the account that is NOT the application pool of your web application
  2. Restart IIS (or reboot) your web/sharepoint servers
  3. Next time you're adding SPN's, use setspn -S instead of setspn -A, so that the command will check for duplicates
  4. Use setspn -Q http/* (or similar) to search for SPNs in your AD
  5. Thorougly document your SPN's and accounts!
Improve this answer
2
  • Thanks for the advice Wictor, in my case account1 is the one that is not running the app pool, account2 is the account responsible for that. Once I unregistred account1 then I was getting 401 access denied. I did attempt an IIS reset but not a reboot of the actual server. Do I need to remove all refrences to these accounts an re-add them perhaps? I just need to do this in a window where the users aren't at the site.
    – pigeon
    Commented Jan 25, 2012 at 1:51
  • 1
    It may be worth adding, I believe that the -S parameter for setspn is only available in Server 2008 R2. Worth mentioning just in case you happen to be running on the original Server 2008.
    – webdes03
    Commented Feb 17, 2012 at 22:53
1

You should only register SPN's for the account running as the application pool user on http/portal.

account2 should be deleted from the list of registered SPN's, as it is not possible to run two application pools for the same http/web app.

If anything starts failing after you have removed account2 from the list of SPN's, the failing party needs to be corrected. It will not help to try to register more accounts for your http/portal SPN.

Improve this answer

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.