“ACCESS DENIED 401.5” – On first load, canceling the prompt shows “401 ACCESS DENIED” but you can refresh the page and it works fine without any future prompt until app pool recycle.
I recently had the misfortune of trying to resolve an access denied issue in SharePoint 2007 running on a Windows 2008 OS, which means IIS 7.5 as the web host platform. The other web front end which was Windows 2003 with IIS 6 was working fine (don’t get me started on why they decided to mix and match the load balanced front end OS and IIS versions).
Typically, getting an access denied issue on an anonymous site can mean one of the following:
All of these are addressed by this TechNet article.
For the more advanced issues:
And finally, the one which cost me two and a half days trying to locate and debug and ultimately spawned this blog post…
You are getting a “401 ACCESS DENIED” blank white screen, your IIS logs are reporting 401.5 errors, failed request tracing is returning nothing, event logs are returning nothing, and even the ULS log is returning nothing usable other than just saying “ACCESS DENIED”.
More specifically, I found the following set of entries:
General 8xfr Verbose PermissionMask check failed. asking for 0x00010000, have 0x00000000 General 8xfr Verbose PermissionMask check failed. asking for 0x46871000, have 0x00030041 General 8kh7 High Access denied.
I asked Google many different ways and read almost a hundred blog posts, stack over flow questions, and forum posts:
Sadly none of them worked for me.
My issue turned out to be a very deep web.config file configuration issue, someone changed something on the server (I have no idea why… and isn’t it always those mystery changes people made but never recorded that get you?)
I found this forum post.
I would have loved to have known how they came to that conclusion to set batch debug compilation to off.
The issue was that the web.config had:
<compilation batch="true" debug="true">
The reason why it was getting access denied on the first load of the page for anonymous users was some-how related to how the initial compile was run, and having that
batch="true" was causing the problem.
To fix my issue, changed
batch="false". However this could also be caused by the entry missing the value settings, as they default to
I hope you find this post helpful in diagnosing and fixing anonymous access denied issues in SharePoint 2007.
Although I might add to this, even though it fixed the issue it didn’t fix it “the right way”.
Batch compilation is designed to help IIS / ASP.NET save time and cache the compilation results, as outlined here.
So the real problem would be more related to the fact that their organization has potentially made a security change which causes the account that pre-compiles the pages to lose access to a required directory. Unfortunately even when using process monitor, I wasn’t able to catch any access denied issues, so sadly the real problem eludes me. I’m sure if I had more time to sit down and dig through all of their group policy settings I could find out how it came to be broken.