Archive for the 'Kerberos' Category

DNS and Kerberos… the answer to our mystery

It’s not an obvious one, so I thought it warranted a blog posting.

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

Information I failed to give, was that our K2 [blackpearl] workspace was accessable only by a host header, and likewise our MOSS instance. This has some significant implications for Kerberos authentication. The SPN for those instances should be made with the host header rather than the machine name.

OK. So you’ve got your SPN’s… but how have you configured your DNS server?

You host header entry really should be an ANAME entry. We however, had defined our MOSS instance with a CNAME. A CNAME is really just a way of providing an alias for a server, this should almost certainly result in failed Kerberos authentication against the SPN with a CNAME entry.

SpittingCAML



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



When the Delegation tab is missing in Windows 2003 Active Directory Users and Computers

So you’ve been investigating Kerberos, and you’ve done the command ’setspn.exe’ setup (part of the Windows 2003 support tools install) of your Security Principle Names for your domain controller… but when you try to assign a user account some delegation rights… the damn delegation tab is missing!

The first thing to do is to check that your domain controller is operating in Windows 2003 mode. By default you’ll find your system will operate in the Windows 2000 compatible mode.

To do this, look at the screenshot below, you’ll need to go to active directory users and computers, right click on your domain, and click ‘Raise Domain Functional Level’

image001

This will give you something like this:

image002

This dialog box tells me that my domain controller is operating in the correct mode for the Delegation tab to be displayed in the active directory settings. If your server is running in Windows 2000 compatible mode, you’ll be given the option to raise it’s functional level - you should do this if you want the delegation tab to appear! I’m guessing, as I’ve never tried it out, that if you want the server to be a domain controller with Windows 2000 and lower machines it wont work when you change this setting, so beware, as once you’ve done it… there’s no going back!

And there you have it… my server now has a delegation tab:

image003

I hope this helps you out, as when I googled for this issue, I found nothing… please add any links to more descriptive discussion of this issue you you know of any.

enjoy

SpittingCAML



Enabling Kerberos Authentication

Following the training course, its been put to me that we should really be using Kerberos for our authentication model, especially as its going to solve lots of the multi-hop authentication issues.

I need to look into how Service Principle Names (SPNs) are used.

The command:

setspn.exe -A HTTP/servername ADDomain\usernameidentityforapppool

Will enable kerberos authentication, once we’ve configured a web application that will utilise kerberos.

According to sources, NTLM and Kerberos will work together, with NTLM taking precidence when the Key Distribution Center (KDC) is unavailable or if a client machine has an unsyncronised clock.

There is a KB article on this subject:
Microsoft KB Article

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.