This tip pertains to all versions of SharePoint and no versions of SharePoint. Again, it is really more of an IIS troubleshooting tip.

Since you have gone through Tip 30 and enabled all of the extended logging options in IIS you will not doubt have access to the “Protocol Status” and “Protocol Substatus” fields in all of your IIS logs. If not, go back and run through the tip and enable the options.

When a user cannot access a resource in SharePoint there can be many reasons for it. To track down the “why” of the failed access request a good place to start are the IIS logs. These logs are available in the location specified in the logging options in the web site properties. By default they are located at %SYSTEMROOT%\system32\Logfiles in IIS6 and c:\inetpub\Logfiles in IIS7.

The following list was taken from; The HTTP status codes in IIS 7.0.

  • 401.1 - Logon failed.
  • 401.2 - Logon failed due to server configuration.
  • 401.3 - Unauthorized due to ACL on resource.
  • 401.4 - Authorization failed by filter.
  • 401.5 - Authorization failed by ISAPI/CGI application.

 

I will get a little more in depth on these status codes as they relate to SharePoint. As there are many links in the chain of SharePoint security, it is best to have a starting point to begin troubleshooting and the HTTP status code will help in finding that starting point.

401.1

  • Usually means that the account information you are giving is incorrect. Check your username and password again, check the Caps Lock key. Make sure to specify the domain for Windows Integrated authentication sites that prompt for credentials (anything that is not in the Intranet zone).
  • This can also happen when you browse on the same machine as IIS is installed and the hostname does not match the server part of the URL. See http://support.microsoft.com/kb/896861 for more information.

401.2

  • The authentication method that your browser is trying to use is not supported by the site. Many of these are common on servers that have Windows Integrated authentication enabled because browsers will try to connect to the site using anonymous authentication first.

401.3

  • This HTTP status will most likely be shown in your browser stating that; “You are not authorized to view this page”. The most likely cause of this is that you are browsing to a file that is located on the file system of the server and the ACL permissions do not allow the application pool process account from reading the file. Check that the application pool is a member of the required local groups on the server and that the correct permissions are set on the file in the file properties security dialog.

401.4

  • This status code can be sent when using Digest Authentication and password is either not stored in reversible encryption, or the password has not been reset (http://support.microsoft.com/kb/241832). Since Digest is only used when running IIS on a domain controller and SharePoint should not be running on a domain controller (Except for SBS companyweb) this should not happen often. In fact I have never seen this status code while troubleshooting SharePoint.

401.5

  • This status code is sent when an ISAPI filter or CGI application is denying access to a resource. The most likely source of this is an antivirus solution or URL rewriter, but there are many ISAPI filters so check the listing of ISAPI filters in the IIS Management console for clues to the cause.

200.0

  • Wait, this is not an HTTP access denied status. That is true, but when you are denied access from SharePoint permissions this is the HTTP status you will see in the IIS logs. There will be a request for /layouts/AccessDenied.aspx with a 200 status code from the user trying to access the SharePoint resource. Adding permissions to SharePoint or changing the group to a group that has access to the resource will clear this up.