Random "Access Denied" Errors in SharePoint Even Though Users Have Access

Users of our SharePoint site have been experiencing random Access Denied messages, even though they have been given permission to access it (either expressly or as a member of an  AD group).  When the user clicks the "go back to site" link, or if they hit the back button and try to access again, they are able to access the site fine for a while.

Other Observations:  This typically seems to happen the first time they access a site for the day or if they have not accessed the site for awhile (few hours?), and it does not seem to happen at the main site (typically only sub-sites).  The problem only seems to occur when a particular user has read access; it does NOT seem to occur with users who have full control (e.g. my account has never had a problem, and I am in site owner group of all sites).  Also, the problem does not seem to change whether authentication is set for Kerberos or NTLM.

My symptoms are similar to the question at http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_23953683.html, however the solution does not seem applicable because I am in a single-server environment.

WSS 3.0
Single server
SQL Server back-end
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


To work around this behavior, enable Basic authentication on the client computer. To do this, add the UseBasicAuth registry entry to the following registry subkey, and then set the entry to a non-zero value:


To enable Basic authentication on the client computer, follow these steps:
Click Start, and then click Run.
In the Open box, type regedit, and then click OK.
Locate and then click the following registry key:
On the Edit menu, point to New, and then click DWORD Value.
Type UseBasicAuth, and then press ENTER.
On the Edit menu, click Modify.
In the Value data box, type 1, and then click OK.

Note Basic authentication is enabled if the UseBasicAuth registry entry is set to a non-zero value. Basic authentication is disabled if the UseBasicAuth registry entry is not present or if the UseBasicAuth registry entry is set to 0 (zero).
Exit Registry Editor, and then restart the computer.

In Internet Explorer>Tools>Options>  Please configure the following as well.
Security tab>Trusted> added Sharepoint server name
Content Tab>Autocomplete>Settings> uncheck all this since it can save changed passwords.
Advanced Tab> Uncheck Do Not Save Encrypted Pages to Disk.
Make sure to flush their IE cache for any saved pw's and files/forms.

This should resolve your password issue.
Sorry meant CHECK on Advanced Tab> Do Not Save Encrypted Pages to Disk.

Not uncheck, since by default it's not enabled.
BClarkIndyAuthor Commented:
I have tested the above solution and does not solve the problem.  The referenced KB article seems to pertain to Basic Authentication and WEBDAV on the client when accessing WSS document libraries using explorer view.  I believe my symptoms are different.

The weird part of my issue is that clients ARE able to connect, but only after they are first presented with an access denied error.  If they immediately re-attempt access to the sub-site, they can see it just fine.  It's almost as though there was some sort of authorization timeout, causing an access denied page to be presented to the user even though they are authorized.
5 Ways Acronis Skyrockets Your Data Protection

Risks to data security are risks to business continuity. Businesses need to know what these risks look like – and where they can turn for help.
Check our newest E-Book and learn how you can differentiate your data protection business with advanced cloud solutions Acronis delivers

Try resetting the IE security setting to default, then test. You could have something set too high like the Intranet security. I know I have to personally touch every pc for my sharepoint users due to the our corp. default image IE security settings are not Sharepoint friendly.

Download that FIddler2 web debug tool, it can help you watch the initial timeout session.  Might help point you in the right direction, as it will show you each session between the client and servers and allow you to review the HTML requests, acknowledgements, and failures under the Session Inspector tab in Headers, Textview, webforms, Hexview, Auth, RAW, and XML.  Pretty handy tool. Helped me narrow down my issue with the UseBasicAuth issue.
Found this answer to a similiar problem: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_23953683.html

adaco:Well I finally figured out what was causing our issues.  We recently installed a sharepoint add on that modified the web.config file.  The install failed so we had to uninstall.  In the process the web.config file was different on both front end web servers.   I restored the web.config file from back up and all is well.

Hope this helps.
BClarkIndyAuthor Commented:
Thanks for the comment Maverickpoet.  As stated in my original question above, I also saw this same question you are suggesting.  However, because the solution to that problem was to synch-up two different web.config files on two FE servers, I unfortunately do not see how that relates to the problem I am having since I only have one web server.
BClarkIndyAuthor Commented:
I believe I have found the problem.  It seems to be related to a setting I changed in the site root's web.config file in order to get "developer friendly" error messages when debugging an application rather than just getting the generic SharePoint error message.
I followed the points outlined in the following blog article when making changes to the web.config file: http://blogs.msdn.com/pranab/archive/2007/07/04/how-to-implement-debug-option-in-sharepoint-application-within-vs-2005-with-complete-call-stack-instead-of-custom-error-page.aspx.
Unfortunately, I made a typo in the compilation element.  I meant to change <compilation batch="false" debug="false"> to <compilation batch="false" debug="true">.  However, I accidently changed it to <compilation batch="true" debug="true">.
According to http://support.microsoft.com/kb/953459, the batch attribute in the compilation element should not be set to true in web.config for the root of the web site.
After changing the batch attribute in the compilation element back to "false", my intermittent access denied messages seem to have disappeared.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.