0

I would like all members of the DOMAIN\Domain Users' or 'DOMAIN\Users' AD groups to have read-only access to a site collection and its subsites. I have added these groups to Site Permissions at the top-level site, and given them all of the following perms: Read, Restricted Read, View Only, Site Viewer, and Site Guest.

Yet attempting to access the site by any domain user always results in Access Denied error.

The only way to prevent this error is to add these groups to the web application's User Policy as Full Read. However, this overrides restricted access to subsites (subsites which have their own restricted list of allowed users).

I really need both scenarios supported: All domain users can read all sites, except those which are locked down (subsites which don't inherit permissions).

CHECK PERMISSIONS result:

Permission levels given to MYDOMAIN\domain users :

Read, Restricted Read, View Only, Site Viewer, Site Guest Given through the "Read-Only Users" group.

Improve this question
2
  • 1
    If you use the "check permissions" feature and check the permissions of domain\domain users does SharePoint demonstrate that the domain group does in fact have these permissions? There is no reason that I can see that your setup would cause you any issues, so we just need to troubleshoot this. Commented Feb 13, 2014 at 23:54
  • I updated my question with the results of checking permissions. This was done at the top-level site (root web). Commented Feb 14, 2014 at 4:32

2 Answers 2

Reset to default
1

This means you have some asset you have not checked in, published and approved. It could be an image, css file or master page you are using.

Improve this answer
6
  • 2
    Eric raises a very useful point as well, there may be elements of the master page, or the master page itself that users cannot see because its not published or approved. Good shout. Personally I would use the "check permissions" function first just to ensure that the domain group does in fact have the necessary permissions. Commented Feb 13, 2014 at 23:56
  • I searched manually, but could not find anything not published and approved. Is there a way to check this for the entire site? On a related note, I noticed that the URL for the 'access denied' page includes a GUID, which points to one of the top-level site's lists. However, upon viewing that list's permissions, it is inheriting from the top-level site. But this is a unique list: it is deployed to the site from a Visual Studio solution. Not sure if that give you more leads to go on. Commented Feb 14, 2014 at 4:52
  • I learned how to find unpublished items (via page: /_layouts/sitemanager.aspx). I published the one item that was unpublished. No change the 'access denied' though. Commented Feb 14, 2014 at 5:07
  • Just BTW, the list I mentioned above is a CAML ListInstance, ala: <Elements xmlns="schemas.microsoft.com/sharepoint"> <ListInstance Title="Mega Menu Items" ... Commented Feb 14, 2014 at 5:20
  • I found and fixed the issue. I discovered that the Style Library list had restricted permissions (was not inheriting from top-level). Please advise as to how I should give credit. Commented Feb 14, 2014 at 5:52
0

As it turns out, there were a number of causes for the Access Denied message I described. Here is what I did to resolve the issue:

1) Remove 'DOMAIN\Domain Users' AD group from User Policy for the web application. This helped in troubleshooting, since no Access Denied errors occur with this enabled (as described in my question).

2) Log into the top-level site as a site administrator, then navigate to /_layouts/sitemanager.aspx. Click on the Home tree node at top left, then in the right pane, change the view to All Draft Documents. This revealed 3 items in an unpublished state (which I then published).

3) I also discovered that a custom web part was attempting to access the SPSite.AllWebs object without using the SPSecurity.RunWithElevatedPrivileges method. This we discovered by deploying the web part using Visual Studio in debug mode. Subsequently fixed.

4) Finally, I discovered that the top-level site's Style Gallery list was using restricted permissions. I changed it back to inherit permissions from the top-level site.

After doing all of these things, the problem was solved. It was a challenging but useful learning experience.

Improve this answer

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.