Authentication and the SharePoint ServiceObject

I’ve had a pretty hard time over this particular issue… put it this way, a deadline has slipped on us, probably because with all things new and untested have that unknown element about them… this was the first time that we’ve introduced Kerberos authentication into the loop as our development and staging environments have all the necessary components in one installation, on one machine.

impersonateissue0 
Figure 1 - the configuration

Having followed the K2 [BlackPearl] Kerberos guide I was confident that the three servers would talk to each other without a hitch.

How wrong was I! After checking all the logs and doing some further investigation I concluded that there must be something amiss with the configuration. It’s strange though as there was no evidence of failed Kerberos authentication, but there was evidence of use of the NT AUTHORITY\anonymous user being used.

Problems first arose when I couldn’t get impersonation to work on the SharePoint service broker

impersonateissue1  
Figure 2: adding a SharePoint service instance (K2 Workspace on Machine A)

Notice in Figure 2 that the impersonate option is checked.

impersonateissue2
Figure 3: error message - The request failed with HTTP status 401: Unauthorised connecting to MOSS running on Machine A (K2 Workspace on Machine A)

This shows that Machine A has rejected the impersonate option on it… but why?

impersonateissue3
Figure 4 - K2 Server running on Machine C 

A quick look at the K2 Server console running on Machine C . Nothing conclusive here, but a quick scan on the Security tab on Machine A shows that somewhere in the pipeline the NT AUTHORITY\anonymous user has got in the loop.

I carried on with the install of our workflows, leaving the impersonate option unchecked, which meant the service instance could be added. This meant that the deployment of the workflows was a success, but upon testing, the workflows failed to connect to the SmartObjects that utilise the SharePoint service object that failed to impersonate.

What could we have done wrong in our configuration? I’ve checked the SPNs, and it seems to be fine, and users are able to authenticate with the K2 Server with Kerberos….. but why aren’t they able to authenticate with the SharePoint service object?

I’ll keep my fingers crossed that someone out there has had this problem before!

SpittingCAML




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Authentication and the SharePoint ServiceObject”

  1. Mark Green Says:

    When ticking the “Impersonate” tick box the service object will use Kerberos impersonation to talk with the instance of SharePoint. As this is the case I would check the usual things;

    - Are the SPNs for MOSS and K2 correct.

    - Is constrained delegation being used and if so what services is the K2 Host server allowed to delegate to.

    If all the above check out I would then go about switching Kerberos logging on each server on and set all logging to verbose. Go through each server in the chain checking the “Security” and “System” sections of the “Windows Event” log, check the IIS log for the MOSS site collection in question, check the access logs to the SQL DBs.

  2. SpittingCAML » Blog Archive » DNS and Kerberos… the answer to our mystery Says:

    [...] may have read my previous posting about the Kerberos issues I’ve been experiencing with K2 [blackpearl] and MOSS [...]

Leave a Reply