“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:
- You didn’t further enable anonymous access for the target web application zone.
- Your bindings in IIS are set up incorrectly and you’re still navigating to the authorization required zone.
- You didn’t enable anonymous access permissions at the site collection level.
All of these are addressed by this TechNet article.
For the more advanced issues:
- You set up restrictive anonymous access permissions at the web application policy level.
- Central Admin>Application Management>Policy for Web Application
- From the left most navigation (Quick nav area) there is a “See Also”. In there you will see “Change Anonymous Access Permission Policy” where you can block access to ‘anonymous’ despite granting it in the site collection level.
- You’re experiencing ACL issues for the anonymous access account (and IIS issue), this is usually accompanied by a 401.3 ACCESS DENIED and you actually get to see the access denied SharePoint page.
- In this instance, you can use the failed request tracking provided by IIS to debug file access issues.
- You can use the specific list ID or file ID from the query string on the access denied page to determine which library you need access to.
- You have required files checked out or otherwise not checked in to a major version and published.
- When editing the page under the Tools menu you will find Check for unpublished items. This report can help you find items not published which may be affecting anonymous access. This tool can help you find any images or css files that are failing authorization causing multiple prompts for login while still being able to access the page.
- There is also a report from the manage content and structure page which can help identify unpublished items in the site collection: http://servername/_layouts/sitemanager.aspx?rptmode=3″>http://servername/_layouts/sitemanager.aspx?rptmode=3
- You’ve selected the wrong caching profile in the object cache settings (located in site settings). It should be set for public anonymous if your site is a published internet page.
- If you’ve landed here and you were looking for a SharePoint 2010 problem where even site collection administrators are getting the access denied SharePoint page, you may have forgotten to configure your super reader and super user accounts for publishing portals…
- If you’re using windows auth make sure the super reader user as a policy defined at the web app policy level that grants full read.
- If you’re using Claims Authentication and you are getting Access Denied for Site Collection Administrators, you need to set the portal super reader and portal super user accounts to use their respective claims identities instead of the windows domain account format – click here.
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:
- Access denied on first load only
- Access denied 401.5 sharepoint 2007
- Access denied anonymous sharepoint 2007 iis 7
- Access denied anonymous output cache
- Access denied anonymous 401.5 “sharepoint”
- Anonymous 401.5 sharepoint IIS 7.5
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.
Originally posted by DevFacto Microsoft Certified Master, Kevin Cole, at SPDev.Info()