Troubleshooting HTTP 401.3 errors with Process Monitor
Last week I posted the following blog which showed how to use Process Monitor to troubleshoot service startup issues.
To continue on that topic, I ran across another issue recently where Process Monitor was again very helpful in troubleshooting.
Problem – When browsing ASP pages, we were getting below error in the browser. Browsing any HTML page worked fine.
HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.
Note that you may need to uncheck Show friendly HTTP error messages in Internet Explorer on the Advanced tab under Tools/Internet Options as shown below to see this exact error.
It is good practice to leave this option unchecked when you’re troubleshooting an issue that involves an error message in the browser, since you’ll be more likely to get a full detailed error message. You could also check the IIS logs and look at the sc-status and sc-substatus fields to see 401 and 3 respectively.
Now I captured a Process Monitor log while reproducing the issue. As usual, I started by filtering on Result is Access Denied in Process Monitor after reproducing the issue. I found that there were no related Access Denied entries. You would expect that Process Monitor would capture an Access Denied result with an ACL (Access Control List) error like HTTP 401.3.
I found that this can occur when the account the IIS worker process was launched as has access to a particular file, but the user that authenticated through website does not. To see this in Process Monitor, I first filtered on w3wp.exe for the process name, which is the worker process that hosts a web site in IIS 6.0.
I then looked through the Process Monitor output for the access to C:\WINDOWS\Help\iisHelp\common\401-3.htm, which is the file IIS reads in by default to display the 401.3 error in the browser. Once I found that, I looked for what showed up in the log just before then.
The last thing that was accessed before the 401-3.htm file was asp.dll. Checking the permissions on that file and comparing it to a default installation, I found the permissions were the same.
See the entry highlighted above that shows a successful access to asp.dll for a QuerySecurityFile operation. The Detail column shows the information queried was the Owner, Group, and DACL (Discretionary Access Control List). Basically what’s going on here is the w3wp.exe process accesses asp.dll using the process identity (NETWORK SERVICE by default). We don’t see an Access Denied result because the process identity has the appropriate permissions. Now it checks to make sure that whatever user browsed the site also has access to asp.dll. In this case, Anonymous Authentication was enabled so the IUSR_MachineName account was checked, which did not have the appropriate permissions.
The issue here turned out to be that the NT AUTHORITY\Authenticated Users group was removed from the local Users group. Adding it back and then restarting IIS resolved the issue. The point here is that using Process Monitor I was able to narrow the issue down to the user accessing the site not having permissions on a specific DLL. In this case, IUSR_MachineName was an Authenticated Users, which should be a member of the Users group, and Users have permissions on asp.dll.
Summary
- Capture Process Monitor log while reproducing issue
- Filter on Access Denied
- No Access Denied, so filter on w3wp.exe
- Look for access to 401-3.htm
- Review entries before the 401-3.htm to determine what file was accessed last
- Check permissions based on successful QuerySecurityFile operation for last file accessed (in this case was asp.dll)
References
Below are a couple of articles we use frequently for HTTP 401.3 and other permissions related issues with IIS.
Default permissions and user rights for IIS 6.0
https://support.microsoft.com/kb/812614
Troubleshooting HTTP 401 errors in IIS
https://support.microsoft.com/kb/907273