IIS Won't authenticate domain user: 401.2

6,628

401.2 typically means that IIS isn't supporting the type of authentication that you are trying to use. Are you sure Windows Integrated Auth is enabled?

Check out the IIS settings on your STAGING machines - the User Authentication/Logon setting in Security setttings (for the zone your SharePoint site is in...) should be set to "automatic logon with current user name and password" - or, if you SharePoint site is in the intranet zone you could use "automatic logon only in intranet zone"

Check out AuthDiag - it is built to help diagnose authentication errors.

Share:
6,628

Related videos on Youtube

Narkha
Author by

Narkha

I work with Olo solving problems for people who want to order food online. I'm also a Stack Overflow alumnus and Microsoft alumnus. I love Jesus, my family, programming, Texas, and craft beer. Find me on twitter and GitHub as @aggieben.

Updated on September 17, 2022

Comments

  • Narkha
    Narkha over 1 year

    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?

    • Admin
      Admin over 14 years
      Are Staging users using IE? Is the site in the Local Intranet-zone and is the integrated Windows Authentication enabled in their browsers?
    • Admin
      Admin over 14 years
      Yes. I've checked those issues. Turned out to be a kerberos vs. ntlm configuration issue in SharePoint.
  • Narkha
    Narkha over 14 years
    I tried to use AuthDiag, actually. It always failed, saying "the url is invalid" or some such. I gave up on that.
  • Narkha
    Narkha over 14 years
    Ok. It turned out that the Windows auth provider in the sharepoint site was configured to use Kerberos, instead of NTLM. Once I switched it to NTLM, that fixed my problem. I'm sure my site wasn't configured correctly for Kerberos, so it all makes sense now.