I opened a ticket for this issue, and received the response that Kerberos authentication is required for the server setup I described for our scenario. Hope that helps others that are experiencing this problem.
Thanks Chris. In plowing through the document you've attached, it seems as if you can use Kerberos only for the blackpearl services and you don't have to turn it on for other existing services. Is this true? I'm asking because we've deployed blackpearl to an exisitng production environment where I can not just change the authentication method for everything that is already running on that farm (seems pretty dangerous to try that on production!). All I really want to do is have the blackpearl task list use kerberos while have the rest of SharePoint using NTLM, and it seems like it would be possible because we are setting up a specific account (blackpearl service account) to use kerberos. What do you think?
As usual, I think I found the answer to my own question just after posting... on page 27 of the document Chris attached, it appears as if you must switch SharePoint from NTLM to Kerberos authentication, which is a bit too broad of a change for me to implement on our existing production servers. If anyone thinks otherwise or has some other ideas, I am definitely interested in hearing them. Thanks!
Old thread, I know, but just for the benefit of the anonymous Googler, I've recently run into the same errors, and was able to cure it.
Our situation: Kerberos was already set up and relatively healthy.
One user was causing this error:
SourceCode.Security.UserRoleManager.Runtime.UserRoleManagerServer.GetDefaultLabelName
Authentication required for session
This user did not have the K2 Workspace (and MOSS sites) listed in his Internet Explorer Local Intranet zone. The errors showed up even after successfully logging into the K2 workspace site via the normal Windows authentication box.
Adding the sites to Local Intranet fixed the problem.
I have experienced this error many times.
sometimes due to bad Kerberos authentication configuration ( which is now pretty much clear with Windows 2008).
but the main culprit to this error , is bad SharePoint authentication provider configuration .
In many cases I have seen SharePoint admins I consulted for , select with the windows Authentication.maybe by mistake.
this will cause Negotiate failure similiar to NTLM / Kerberos Mix.
The Fix
Disable lAllow Anonymous ] on the authentication provider for your zone
SharePoint Administration - > application managmanet - > authentication providers.
Hope that save someone time in the future
-George Gergues
-SharePoint Architect.
Great input thanks George!
