SharePoint 2010 is giving me a major headache.

We have a site collection with a number of sites where we are trying to give certain users access to certain areas of the site.

The problem is that before I have even started to try and "Deny" access to anything (read wise) certain pages reports access denied for the user. If I run a "Check-permissions" for that element it reports that the user should have read access correctly...

I have even tried to give him "Full Control" to the group he is a member of, and little does it help.

The only thing I have seen work for giving access is to give the user "Full Read" from the Central administration board. However that suddenly defeats the purpose since we can't block the user from certain areas anymore then (at least it seems so)...

So it must be something "outside" the control of the site collection that he requires access to when visiting those pages, but what might that be?...

What we have is a Site Definition that defines a set of pages, this serves as a template for creating a generic portal for a part of an organization. These pages contains a set web parts that pulls data from lists based on custom content types.

This pages are placed in a "Site Pages" library. Now the page they do have access to as opposed the the ones they don's is in the root of this library, the others are placed in a folder called "_hidden"... If that can have anything to do with it?...

The library is the standard one you get with the "Wiki Page Feature". (Can't remember the exact name as I write this)

ANY help at all would be welcome, I have found many others having similar problems, but nothing that kind of said "AHA..." in my mind yet.

5 Answers 5


If you think everything is looking fine with respect to SharePoint thne start looking at the AD security principals instead, has the users account been changed recently, if you're nesting AD groups within SharePoint groups ensure none of those are distribution groups. I've had situations whereby an account got re-created with the same account name yet the SIDs will be different and SharePoint will not recognise the account thereby you will need to perform an SP-MoveUser(?) can't remember the exact cmdlet but there will be something to reassociate the user, however in doing this please be aware it can completely strip out individual permissions across the site collection so there needs to be some care taken when executing that.

  • We haven't mapped AD groups in our tests, only users directly, and they haven't changed either. And without modifying any permissions at all, meaning that everything should inherit from root, where access is granted just fine... But for now we have had to recommend that our customer gives full read permission to all authenticated users on the web application level (One level up from the Site Collection). Since that is the only thing we have made work... That is not very desirable though. (as also noted in the question)
    – Jens
    Dec 17, 2012 at 9:35

Not sure if this will help, but I was having a similar issue yesterday. I had users who had access to a site being asked for their password multiple times before being allowed access. The problem turned out to be that I was linking a content editor on that page to a CSS file which was in another document library, that library did not have access permissions for the users so they kept getting prompted for their password.

Any ways, double check that the library that is storing your pages does have permissions so that those users can access it, basically if you broke the permissions for the library this might be the issue.

Also you mentioned the pages they do not have access to are in a folder called 'hidden', does this folder have individual permissions from the library itself or how is it set up?

Not sure if that is the issue for you, but just a thought since I experienced something somewhat similar.

  • Can't see it should be any CSS files or like that, because we access the same set of files in all our pages, and since some pages work that would be odd? And I did check the folder, there didn't seem to be anything different about it, but i'm not sure if there is places, however I will try to add a page in that folder containing no content tomorrow, see what happens. Trying to think if there is anything different about those pages in that folder than other pages, maybe also try to add the "same" pages to the root.
    – Jens
    Sep 14, 2012 at 20:31

I had a similar problem a while ago. I'm still not sure what caused the change but I know what fixed it for me. My problem was that I needed to grant READ ONLY access to the masterpage in the master page library. It only happened in one site collection, and once i added All Authenticated Users with read only access the problem was solved.


I had a similar problem where a user was a contractor and account was recreated after returning. after extensive investigation. I sound 1 instance of his user account applied on another sub site but part of the same collection. I removed all instances of the account and then re added the user. and it worked fine now.


I know this is an old issue, but I had experienced this same situation and it took me a while to find the correct solution. Hopefully, posting it here will help others in the future.

Our SharePoint sites are set up to utilize AD groups instead of SharePoint groups, and access to the document libraries and folders under them are granted by AD group. One AD group had been set up with Full Control on their folders, and had read access from the top down to their folder list.

All users in this AD group could create new folders, and could add documents and add a Link to a Document. However, one user in this same AD group, got an access denied error when choosing to Add a Link to a Document. This same user could perform all other tasks such as creating folders and setting permissions. Comparing this user's access to others in the same AD group granted full access, the permissions were the same (these two users aren't in all the same AD groups, just shared this one in common).

Looking at the permissions from the top of the site down, everything seemed to be in order. Checking permissions for the user, everything checked out okay (note: we follow grant not deny access methods so there was nothing denying access anywhere). After researching online and trying many possible solutions without success, I found a post regarding the status of Master Pages.

On checking the Master Page, it was checked out. I checked it back in, re-published, and approved it. This corrected the issue.

I'm still not sure why only one user experienced this issue, while others in the same groups and with the same permissions had no trouble at all, but it may have something to do with when the page was checked out and the timing of when this user was added to the AD group.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.