Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Fixing Sharepoint 401.1 HTTP errors

English
Portuguese

Occasionally after you install Sharepoint you can get the 401.1 HTTP error when you try to navigate to Sharepoint on the same domain, but when you try to access for an external network, everything seems to work fine. This happens 'cause when you are on the same domain IIS believe that you should be authenticating using Kerberos Authentication, and, for external machines, IIS try to use NTLM first. Both Kerberos and NTLM Authentication are part of the "Integrated Windows Authentication" option on IIS. As you probally didn't want to use Kerberos authentication, you haven't edited the IIS metabase to configure the SPN (service principal name) account, and, because of this, the Kerberos Authentication will always fail. To solve this issue, you can disable the Kerberos for the website, and use just the NTLM authentication for both internal and external requests. To do so follow this steps:
  1. Open the IIS Manager
  2. Expand the local computer and then click on Web Sites
  3. On the sites list, find the web site you want to change and take note of the Identifier column
  4. open the command prompt and navigate to the following folder: "C:\inetpub\adminscripts"
  5. run the following command:
    adsutil GET W3SVC/YOURID/Root/NTAuthenticationProviders

    change YOURID for your the ID of the website you want to change
  6. If the command returns "Negotiate,NTLM" then Kerberos is active for the website, to change this, just run the same command again, but with the SET parameter instead of GET and with the NTLM parameter:
    adsutil SET W3SVC/SEUID/Root/NTAuthenticationProviders NTLM

6 Comments

  • Hi Felipe,
    This is a great article. I have a question,
    Whats the difference between

    adsutil SET W3SVC/SEUID/Root/NTAuthenticationProviders NTLM

    and

    adsutil SET W3SVC/SEUID/NTAuthenticationProviders NTLM

    In our environment adsutil GET W3SVC/SEUID/NTAuthenticationProviders, returns NTLM. But we still see a lot of 401.1 errors. Will it make a difference by adding the Root/ switch ?

    Thanks
    Raj

  • This worked for me! thanks!

  • Thanx for the hint! You save my time and nerves.

  • The query posted returned "not set at this node". After setting it the problem still occurred. NTLM was set at
    W3SVC/SEUID/NTAuthenticationProviders.

    Guess I'll have to search some more...

  • Understandably, this is a quick and dirty fix. The reality of the matter though, is that in a production environment, Kerberos SHOULD be used. While I have seen SharePoint farms deployed using NTLM, it is NOT in the server / network / security team's best interests.

    I've typically deployed a farm using NTLM only in small farms with little security concerns.

  • Hi Steve,

    thanks for your comment. I agree that Kerberos is a lot more secure than NTLM and should be the first option..
    but in my case I was in an OpenLDAP + Samba domain, using an old version of both openldap and samba in fact.. so Kerberos was not an option unfortunately..
    but this was indeed a small farm :)

    regards

Comments have been disabled for this content.