Hi Mark.
Will the benefits of Kerberos be noticed in this small deployment? Hence is it worth the extra effort?
This is very difficult to answer without hard data about the environment, namely:
number of concurrent users
usage profile of an average user session
location and capacity of domain controllers
amount of non sharepoint authN traffic
However, as you only have a single MOSS server it is safe to assume you have a small number of users to support (<3k). And assuming you have a couple of reasonably specced DCs nearby you probably don’t need the performance benefits that Kerberos can bring. Bear in mind that if user sessions are shortlived, Kerberos will actually negatively impact performance due to the overhead of granting service tickets. Of course we are only talking about the performance side here. You may have security or functionality requirements that trump performance. SSRS and CRM in particular need Kerberos for some elements to function. Detailed instructions for these scenarios will be published soon.
If I select NTLM for the Central Admin site, can I switch to Kerberos later, easily?
Absolutely, this is very straightforward. You need a SPN for the application pool identity used to host Central Admin, and you can configure the web application to use Negotiate using Central Admin itself or STSADM. To just use Central Admin you don’t require any additional delegation settings, although these are required if you also wish to make your SSP and its admin web site use Kerberos.
If I configure Kerberos and it isnt set u correctly, is it noticeable (i.e. errors) or does it revert to NTLM?
It depends! By default, Fallback is in place so if Kerberos AuthN fails, NTLM will be attempted, this can often result in pop-up login dialogs for users. If you configure the application to use Kerberos only, then of course NTLM won’t work and clients will be returned a 401 error if they cannot authenticate using Kerberos. Bear in mind of course that certain functionality cannot work with NTLM – e.g. the RS Viewer web part.
Finally, you mention in your slides that you recommend to always go with NTLM first. Can you elaborate slightly for my benefit?
This recommendation is all about making the process easier. By sticking with NTLM initially you can be sure that SharePoint is all up and running fine before attempting Kerberos configuration. If you go with Kerberos straight away and run into problems you cannot be sure whether it’s a SharePoint issue, a Kerberos issue or indeed a Client Issue. The idea here is to make troubleshooting a bit easier. Of course if you’ve done the config a hundred times etc there’s nothing wrong with going straight for Kerberos.
Again, it makes sense to not use Kerberos unless you need it. And it can be difficult to see the future! So by using NTLM first – unless you hit specific problems or requirements – you can leave it be and reduce the complexity of your deployment.
hth
Spence
Cheers
Spence
www.harbar.net