Best Practices for Permissions on an O365 Group SharePoint Site

Silver Contributor

So it seems that you can break permissions of individual lists/libraries/items, but you can't actually set permissions on the site as a whole?  Am I missing something when looking at configuring general permissions of a SharePoint Site

 

Is there general guidance on best practices for doing complex permissions on an O365 Group SharePoint Site?

38 Replies

Hi Brent,

 

in regards to the improved permission management for Office 365 groups (https://techcommunity.microsoft.com/t5/SharePoint/UPDATE-Create-Office-365-Groups-with-team-sites-fr...) there are some more options to handle advanced permissions - I wouldn't call this complex. However, this already helps a lot for several user scenarios.

 

Moreover, I'd recommend as best practices first to set each new Group as private so that not everybody in the tenant can access it. Second, only certain users in the regarding security group should be allowed to create groups. And third, consider the invitation to external users (guests): permit this generally or only allow for certain groups.

 

Unfortunately, at the moment this has to be done manually after a group's creation. This also applies to more granular permissions, which are still possible to modify in the SharePoint site. However, I'd wish to have a better permission management or other governance options during groups creation process in order to enforce policies. At the moment this is only possible with 3rd party solutions. For now I can just say, use PowerShell and the manual permission management in the SharePoint sites to achieve your complex group permissions.

 

Hope this helps.

Rob

Can somebody please shed some light here -

 

When an Office 365 group is created, the Owners group in the Sharepoint team site has no user added to it !

Now, when we reduce the permissions of the Members group to contribute, there is no user in the site, who can then manage the permissions on the site !!

Its strange, why isn't the user who created the Office 365 group added as an Owner in the site. Or am I missing something here ?

Hi @Vipul Kelkar,

 

I guess, this is a GUI issue, because I have the same problem. I cannot see the users in the regarding groups. However, when I check the permissions, I can see that regarding users should have permission due to the membership of regarding permission group.

group-permission.png

 

Microsoft would say, this is by Design, although it's actually a GUI bug. ;) Hope, this will be fixed.

In the current Groups UI, site permissions are managed in the new pane accessible from the cog menu:

 

2017-03-07 15_11_51-TestPrivateGroup01 - Home.jpg

And, as clearly stated, owners and members should be managed only by OWA.

Hi @Salvatore Biscari,

 

you are right, it's recommended to manage permissions with the end user interface. However, every PowerUser is aware how to use the native permissions from previous normal site collections. Very often companies have complex permission requirements, which will definitely not be covered by only three groups (Owners, Members, Visitiors). Therefore we want to conifgure additional permissions directly on the site. It's deifnitely confusing, when users are granted permission to this site, but there is actually nobody in the regarding groups.

 

Doesn't matter, which UI I use, it should be deifnitely consistent to avoid ambiguities. That's my opinion. Happy to hear your opinion. :)

I agree with you: the various UIs should be consistent.

Nevertheless, Groups have definitely a non-standard implementation wrt their parts (team sites, shared mailbox etc.): I think we should accept it.

Also, in classic team sites, upon creation, the three groups (Owners, in particular, but also Members and Visitors, of course) are empty.

You think that's fun, try creating a subsite in a Group team site, the permissions there are all wonky too. The same restrictions are applied to "sub-site Members" (can't edit default "Edit" permissions). It tries to act like a "Group", but its not, "site information" doesn't load because it is not a Group. No way to get back up a level unless you hard code in a "go back" link or inherit menu, which may or may not work depending on the day.

This is a mess.
Ah ! well thanks for that. So the user IS an owner in the site.
I am not sure why but I don't see the note "To view or change the group members..." as you have indicated in your screenshot. But that apart, the outlook interface will only allow us to add members to the group which are directly added to the AD group.

Now that we have a full team site, people are going to want to manage permissions directly in team site on the list, libraries etc or for that matter provide access to the users to only READ the content. I was trying something similar and was baffled to see the owners group empty.
  1. For managing permissions, you can use (with care!) the hidden page https://tenant.sharepoint.com/sites/group/_layouts/15/user.aspx. But, while there, leave alone the standard groups!
  2. In the "Site permissions" pane, under the cog menu in the connected team site, you can safely change the default permissions for the standard groups.
  3. In the OWA UI, you can safely manage the standard groups membership: add members, remove members, promote members to owners, demote owners to members etc. The same can be done in the "Group membership" pane in the connected team site. And the same can be done also by PowerShell.

 

 

 

Hello everyone! 

I absolutely agree with Robert Mulsow. I also cannot see members once I enter the advanced site permissions options for a specific private group. 

 

Also, it is very difficult to set permissions on a folder level. I entered the library settings and then entered permissions for this library. Later I tried to break the inheritance, but I ended up being kicked out of the group. 

Any recommendations?

 

It is important to be able to set permissions on a document or a folder level as 3 types of group members (owner, member, visitor) will not cut it :(.

@Deleted

As it has been stated in several other threads, it is better to leave alone permissions in Groups teamsites.

If you need more sophisticated permissions structures, then you should better use classic team sites.

Or a modern communication site, if the design template fits the use case.

Great blog about these modern sites, Groups, Teams, etc. and what's the recommended way to use them - also from security perspective.

https://info.paitgroup.com/blog/modernizing-your-approach-to-site-architecture-in-sharepoint-and-off...

 

I found this helpful:
When working with Team sites (that have an associated Office 365 Group), there are some options to grant site access.

Start by selecting the gear icon in the upper right hand corner and select Site Permissions from the drop down menu
Select Invite People:
Add Members to Group: this option not only grants access to the site but adds the account to the Office 365 group. When an account is added via this method, the number of members at the top right of the page is updated. Note, that when using this selection only Owner and Memberpermission settings can be granted. Read access cannot be granted utilizing this method.
Share Site Only: this option adds the user to the appropriate site group. This does NOT add them to the Office 365 group. When added using this selection, the account can be granted Owner, Full Control, Edit or Read access. However, this does not update the members number on the home page of the screen and does not allow the account to participate in conversations (in a private group). This is the equivalent to selecting Advanced permission settings and adding the account that way.
Bottom line: Even though the Advanced permission settings can be utilized to grant permission to ‘Modern’ team sites, but isn’t necessary. Don’t be afraid of the Invite People selection. Just be aware that the Add Members to Group will add the user account to the Office 365 Group and can only be used to gran Owner or Member permissions. Share Site Only will grant access to the team site only and will add the account to the appropriate site group (and this is the only option for read access).

<https://newsignature.com/articles/sharepoint-modern-team-site-permissions/>
Yeah, it’s important to differentiate between office 365 group membership and good ol sharepoint permissions :)

@Brent Ellis wrote:
That is accurate. And I whole-heartedly agree with bumping it down to contribute. We do that manually right now.


We do the same.

@Alexander Schönfeld 

I know this is a dormant thread, but just in case I'd be interested in ongoing developments on this thread.  Launching a number of group/team sites and would love to be able to kick members down to contribute rights.