SharePoint Site Default Groups, Access Requests and Access Denied Errors

SharePoint Site Default Groups, Access Requests and Access Denied Errors

Posted on August 10, 2018 by Eric Shupps

One thing you can usually count on in SharePoint is that members of the site Owners group have full control over everything in the site unless granular (item-level) permissions say otherwise. Which is true, of course, until it isn’t. And in the case of default groups and access requests, it most definitely isn’t.

Case in point. A site owner, who can otherwise access most administrative functions, gets redirected to the standard Access Denied error page (“/accessdenied.aspx”) whenever they attempt to modify permissions at the site or list level. The ULS logs show the redirection happening but they don’t indicate that permissions are lacking for any particular resource. The usual culprits behind unexpected access denied errors – the master page gallery and style gallery – all have the correct permissions. So why can’t a site admin so something as simple as change permissions on a library folder?

The answer, it turns out, has to do with default groups and access requests. As I discovered back when I was trying to figure out why publishing feature activation wasn’t working on subsites, creating a site with its own security groups (the standard Owners, Members and Visitors) and then deleting those groups leads to all kinds of strange behavior (in that particular case, it breaks a bunch of permission assignments to things like Device Channels, Published Links and Reusable Content). There are specific processes that take place behind the scenes when the standard groups are created, one of which is the “Default Group” designation that gets applied to the Members group. Access requests rely upon such a group existing on the site but rarely (if ever) does anyone think to re-apply this setting after they delete the default groups and create their own. This situation is easily discovered by opening the Access Request Settings dialog from the Site Permissions page, which will display the following error: “Members cannot share this site because this site is missing a default members group”.

 

 

 

 

 

 

 

 

With Access Requests enabled, but no default group assigned, the SharePoint security gremlins lose their minds and start pulling all the wrong levers whenever attempts are made to access certain application pages like “/_layouts/15/user.aspx”. This leads to access denied redirections even when the current user is a member of the site owners group (site collection admins and farm admins don’t see these particular issues as they don’t rely upon the site group membership mechanisms for access control) and does, in fact, have the correct access rights.

The fix is relatively easy. Either recreate the default groups from the “/_layouts/15/permsetup.aspx” page, which will wire up the new Members group to the Access Request settings automatically, or select an existing group and designate it as the default group (from the Settings toolbar menu on the People and Groups page). Once Access Requests are working again, the access denied errors for site owners will disappear. Even better, don’t remove the default groups in the first place. Instead, leave them in place and create new groups beside them, designating one as the new default group. Not only will it prevent this particular error but also other errors that may arise in the future (such as the subsite publishing features conundrum).