Tracking down Sharepoint Access Denied errors
Every last business day of the month, freelancers working for our company access our SharePoint Portal to enter their project work times. This time, they got an “Access Denied” error instead of the usual homepage. Trying to access “www.someportal.com” would result in the error shown below. On the other hand, directly accessing the time sheet manager via “www.someportal.com/time/” was successful.
SharePoint: Access Denied
The first suspect was of course the main user and group setting of the portal. But nothing had changed and the “freelancer” group still had it’s permission to view the homepage. As the access rights were inherited down to the time sheet manager, which was accessible, that couldn’t be the problem.
Then I noticed that one particular thing was different with the URL displayed in the IE address bar. Instead of the usual
” https://www.someportal.com/_layouts/AccessDenied.aspx?Source=%2fsomepage ”
I got this:
” http://www.someportal.com/_layouts/AccessDenied.aspx?Source=somepage&Type=list&name=%7B12151589%2D7C0B%2D40DE%2DBD92%2DADB851B3D78E%7D ”
The additional GUID leads to some list, as you can see a little earlier in the URL. Now you can of course search you content database or, if you want to save time, use a little tool. For this case I stumbled upon this one: The Sharepoint Explorer by Ontolica. Run it on your portal server with an user that has full access to the site. This way, you can find the list in question quite quickly.
SharePoint Explorer
In most cases, identifying the list is the solution, as you then know where you have to review the permissions. In my case, this was a dead end, as the permissions were correct.
Going on, I copied the Windows user account of a freelancer and gave it full permissions. Looking through “their eyes” I found a new report viewer web part on the homepage which was targeted at the freelancer group, so I couldn’t see it with my account. This web part was added a few days earlier and obviously not tested properly. The “read” permission was not enough to display it, so the homepage was denied. I granted the freelancer group participation-level access to the report-item, which finally solved the problem.
Tags: Microsoft, MOSS, Sharepoint, Tool, Webpart
