Monday, February 4, 2008

The other day we deployed a MOSS instance and and almost no one could log in! Site Collection Administrators were the only users who could log in to the site. All other users, even those who supposedly had Full Control were given the user terrifying Access Denied page. The most difficult part of troubleshooting this kind of error was trying to figure out where to start. The resolution was that we had stripped all permissions from the Master Page Gallery. Because of this no users (except Site Collection Administrators) could pull a Master Page. Here's how we figured it out.

In the event log was the following exception which was pretty misleading. We thought there was some kind of exception being thrown, but after we stripped out all of our code we were still getting the Unhandled Access Exception.

Steps to Troubleshoot

First make sure the user should be able to log in. Have you added a group that gives the required users access (ie. an NT Authority\authenticated or a Domain\Users group)? Can users gain access as a Site Collection Administrator but not as full control? Are there any security policy settings set for the web application? Essentially make sure you haven't overlooked something.

Secondly, make sure you have a good MOSS/WSS install. If you having any glaring errors in your event log you should probably clean those up first. Troubleshoots get increasingly difficult when there's a lot of noise in the event log.

If you're trying to add/visit a page and are getting an Access Denied, ensure that the user has at least read rights to all the assets related to the page. This includes Master Pages, Style Sheets, Page Layouts, the Page/List Item itself and any other related assets.

Lastly I'd look at the Access Denied URL, if you simply get a:

http://[ServerName]/_layouts/AccessDenied.aspx?Source=[AnyUrl]

Then there's not really a lot to troubleshoot, you most likely have a configuration error. It's when the URL is of the form:

then you have something interesting to troubleshoot. Surprisingly enough SharePoint is telling us that we're trying to access a list and it's telling us to hit the road. The Name parameter is really a html encoded GUID...still don't believe me? What if I went ahead and html decoded it for you (I use this utility for that kind of stuff). Now it looks like:

Essentially we're looking for a list with the List ID of {12151589-7A0B-40EE-BD92-ADB851B3D78E}. It's time to play that age old game...FIND THE GUID!Now there's more than one way of tracking this list down. You can:

Write some SQL against the content database in question, this one is quick if you're familiar doing that kind of stuff but for most people this would be trouble.

Another option a little monotonous, it requires going into the list settings of each list in the site. You'll get a URL that will look like:

See our GUID above? Once you see the GUID in the List Settings of the list you know you've found the list in question.

The last that I recommend is using if you have access to the machine that SharePoint is running on is to install the SharePoint Explorer, a free tool provided by Ontolica. You can use this tool to go track down the list in question (below).

Once you've found the list in question make sure that users can access this list. You do this by going in to the List Settings->Permissions for this List/Document Library and add permissions for at least Read.

That's it folks, hope she helps. You can also use the URL of an Access Denied page to troubleshoot access rights to List Items, but that's for another day.

42 comments:

My users were getting access denied errors just as you described. I tracked it down to the master page gallery and noticed that the layout page being used had an Approval Status of Draft. I approved the page and all is well.

We had a similar issue with a custom build site. Users were getting access denied on the main page, but could browse the rest of the site. As soon as we added the user to site owners group they could see the page...

The developer had a dynamic menu that was different depending of a user is a site owner or not...

We fixed the problem by letting user view the membership of the "Site Owners" group. The web part was trying to see if the user that was accesing the site is a site owner, and since the user did not have rights to see who is in that group we got the access denied. It's the second time i bump into this issue - and the second time I end up spending a week troubleshooting this. Hopefully this will help somebody else.

Further value:1. creating a hilvl group on site collection level for instance, with full control, will indeed not give master gallery permissions.

2. For finding the list, there is magic:http://aravindrises.blogspot.com/2008/08/caml-view-of-splist.htmlthe point is, http://server/_vti_bin/owssvr.dll?Cmd=ExportList&List={GUIDGUIDGUIDGUID}will give you the list def onscreen.Fast, easy. I love it.

I had to put users in the Approvers group to get around this problem. I have web parts that load documents in that were causing the problem. There may be another group that is more appropriate, but this one worked for me. The users needed rights to see the contents of the files.

That english could have been worded a bit better (I've updated it). What that should have said is that you should check the obvious things (like if the users actually in a group that has access) and try to figure out if no one has access (not even site collection administrators) or if it's just select users.

Here is a SIMPLE problem that causes the same symptom: Central Admin, Application Management, Site Collection Quotas and Locks. If a site is set for "read only" access, it can generate the same "Access Denied" errors you describe. We had a problem that a backup process set a site to "Read only" and then failed without setting it back to "unlocked".

Had the same issue, I resolved it by going to Site Actions -> Site Settings -> Modify All Site Settings. Select the option Page layouts and site templates and then select the option to Reset all subsites to inherit these preferred subsite template settings for both subsites and page layouts. This is sort of related to the publishing the default master page; an obvious permission issue.

So what about access errors for anonymous users who want to export items from a calendar? They can view the calendar just fine anonymously, but when clicking on the link to "Export Event" they get prompted with a login box.

Tyler,Thanks for the insight. Given the fact that the calender is exposed for all to see on an anonymous site, I would have thought that the default RSS feed for a calendar would have allowed for anonymous useage of the embedded links for exporting the individual items (why would it provide a link for someone who couldnt use it? Shouldn't permission trimming take care of this?).

At any rate, to get around this I wrote a custom "iCal" web service that I have running alongside a separate custom-created RSS feed for the calendar. The custom feed includes a link for exporting the events that doesn't require authentication.

Thanks again for the help - I'll have to add this to my list of "working-as-intended" features of SharePoint that dont really work in practice.

I spent an entire hrs together for a way to use the AllWebs without throwing that error. Elevated permissions with impersonation of the current user refused to work unless the current user is a site collection owner. I just wanted to thank you for posting this finding.

First, clear any errors in Event Viewer pertaining to SharePoint. Then, login to http://yourmachine/sites/DefaultCollection using the services/Primary admin for sharepoint. (not Administrator).Then, set your Site Collections administrators there, you can also set Individual user permissions for each site from there.This worked for me.

So glad I found this blog! We migrated our whole site and could not change anything! Though the method explained did not apply in my case, one of the comments was the key: The whole was auto-locked after the move. We went into the CA, set it back to 'not locked' and BAM! everything is fine. Thanks 'anonymous'!

THANK YOU, helped me solve a problem for a client who accidently deleted some of the standard sharepoint groups. Suddenly they couldn't create any new pages in the page library because of the missing master page user rights.

Hi, guys.Could anyone help me? I have the next url while getting "Access Denied" error : http://[ServerName]/_layouts/AccessDenied.aspx?Source=[AnyUrl]. I'm using Sharepoint 2010 with custom membership provider and membership works fine because I have no problem adding users to the site collection administrators. But I can't log in. Tyler wrote that there's most likely a configuration error. What type of configuration error can it be? Thanks in advance.

Thank you so much for your post!!! You got me on the right track to solve my plan!! I had a major panic attack as I locked all my client's users out of SharePoint after I edited Permissions at the root site level.

In my case, I had to go to /SitePages/Forms/AllPages.aspx, and add my Active Directory Security group where my users are back into the permissions on this. When I edited the root permissions, it only left "Site Owners" with Full Control and nothing else.

You definitely got me on the right track and saved me a night staying up to resolve this!

I recently was tasked with changing the passwords on our MOSS 2007 service accounts due to a systems manager quitting the company. I followed the steps to use the STSADM tool, but once the password was changed I can no longer access our site via an AAM. We can access it via server:port but not via the AAM's URL. Also, when someone sends an approval workflow through, it works all the way to the point of the Approver clicking the approval button but then throws an Access Denied error. (The workflow tries to access the Tasks list through the AMM). I did your steps above and found that the appropriate permissions are in place. I even granted Authenticated Users read access just for good measure. Any ideas?

About Me

Tyler Holmes is a Solutions Architect working in Portland, Oregon. He lives mostly in the MS tech stack and is currently treading the waters of Communication/Collaboration and Business Intelligence with off the shelf/open source technologies.