0

I have a new Site and have "Everyone except external Users" in a Company Group (which I then apply to all of this site's Subsites with Read Permissions).

The default Members group grants Edit permissions at the root Site level, which permits users to add Document Libraries (and other apps). When I go to the Permissions for the site, I am unable to change the Permission levels for the Members, Owner, and Visitor Groups from their defaults.

What is the best way to restrict our Users from manipulating the "root subsite" (since each department has a subsite where they are designated to do their thing).

Improve this question

2 Answers 2

Reset to default
1

The default members group grants edit to the entire site collection, not just the root web. You shouldn't change the default group permission levels, create your own groups instead. You'll have to break inheritance on the subsites and create a "subsite members" group or whatever you want to name it and give it the permission level you want users to have on that subsite. You have to do this for each subsite since they now have unique permissions.

Make sure the groups you create (or some group) has read on the root site so users can at least login at the root site URL and get a page to navigate from the root site to where they can edit. You could use the visitors group on the root site for this purpose. Also, if publishing is turned on, there needs to be a major version of the root site's default page published or they will get an access denied error when opening the root site, which will probably lead to confusion and frustration.

Improve this answer
2
  • Thanks for the head's up regarding the root site pages! I've already broken inheritance as outlined for the departments, but was hoping that there may be a way to shift everyone to read without making another group. Guess that's the best option though.
    – vanblart
    May 2, 2018 at 18:42
  • 1
    Alternately, you could set all group permission levels to read on the root site, then create a root site editors group. Any site created directly under the root site would inherit this though, so depending on your situation, it might be more work than the other way around.
    – DubStep
    May 2, 2018 at 18:53
0

Usually "Each department gets a subsite" is a bad design.

I would grant each department its own Site collection. This will make stuff much easier to manage.

There are a bunch of issues that can come up with this design. Among them are information leakage, Shared resources (Site MMS data), Permission horror with 1000's of groups, backup and restore (Full fidelity restore is only on Site collection level - site only restore is having several issues), no quota management (Not a real issue in SPO) for subsites, dependencies on root site changes (Content types/fields/...)

Yes, you will have to work on a navigation solution to make up for this, but I prefer the isolation in this case. Also having a Sitecollection owner for each department makes them the primary contact for managing permissions.

So my tip: Change it while you can without much problems now ;)

P.s. Edit permissions can be modified to suit your needs under this URL:

https://yourTenant.sharepoint.com/_layouts/15/role.aspx

I would create a copy and not mess with the default levels though.

P.p.s.: I know this is a touchy subject - I did say usually... So if you want to vote down let me know why

Improve this answer

Your Answer

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

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