Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a lot of trouble with configuring authentication for IIS correctly. I have a SharePoint site running under IIS 6.0, and the IIS web site is configured for Integrated Windows Authentication. The web server is on a domain called STAGING, and most of my users are an another domain, called CORP. The CORP users have STAGING domain accounts, and are able to log into the SharePoint site across the domains (e.g., the users are logged into their CORP workstations and are able to log in to the site). However, STAGING domain users are unable to log in from within the STAGING domain. My understanding was that STAGING domain users should be able to access the site without being prompted for credentials, but this isn't the case. Even so, once the credentials are entered, the result is always a 401.

I looked at the HTTP session in Fiddler, and it appears that the server simple isn't accepting the negotiated credentials sent by the client browser. Here's an abbreviated record:

HTTP GET  server /sites/mysite with headers: { }
    --> 401.2, with headers: { WWW-Authenticate: Negotiate, WWW-Authenticate: NTLM }
HTTP GET  server /sites/mysite with headers: { Authorization: Negotiate <digest1> }
    --> 401.1, with headers: { WWW-Authenticate: Negotiate <digest2> }
HTTP GET  server /sites/mysite with headers: { Authorization: Negotiate <digest3> }
    --> 401.1, with headers: { WWW-Authenticate: Negotiate <digest4> }

The GET/401.1 cycle repeats 3 times before the browser finally gives up.

I would expect that if I had everything configured correctly, the in-domain client would just pass the credentials and life would be good, but that's not what's happening, and life isn't good :-(

Anyone have any suggestions?

share|improve this question
This should most likely be moved to serverfault. – Scott Markwell Jan 27 '10 at 16:58
Ah, yes. I kinda had a feeling this wasn't the place. – Ben Collins Jan 27 '10 at 17:18
up vote 2 down vote accepted

Sounds like a Kerberos/SPN issue. Simple fix is to disable Kerberos in favor of NTLM. You do this in Sharepoint's Central Administration site.

You could also add the SPN's for your site to the SharePoint Service Account.


share|improve this answer
Yeah, this turned out to be the issue. When I forced NTLM-only authentication, it all worked just fine. Turns out I had done exactly nothing to get Kerberos working, so naturally it didn't work :-) – Ben Collins Feb 7 '10 at 20:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .