Moving from On-Premises to Cloud Permissions
The move from SharePoint on-premises to SharePoint Online is “interesting” and migrations can throw up many challenges. One of the non-technical changes is the transition to a new world of Office 365 permissions, where traditional SharePoint permissions are replaced in many cases by Office 365 Groups. This throws up many questions in the minds of those who have run SharePoint on-premises deployments and who might be used to customizing permissions.
Simplicity is Key to Office 365 Groups
Office 365 Groups implement a very simple permissions model. Owners have administrative permissions and manage the resources belonging to the group, including its membership. Members have access to the resources. They can see everything in the group inbox or calendar, upload and edit all the documents in the site library, take part fully in team conversations and meetings, schedule and update tasks in a plan, and so on. With just a few exceptions, the rule that a member has access to everything owned by a group even extends to guests (this is why you must use rights management to stop guest members being able to open documents in a group document library).
Office 365 Groups are a type of an Azure Active Directory group. When you create a new Office 365 group, you also create an Azure Active Directory group. The members and owners of the Azure Active Directory group form the membership and owners of the Office 365 group. Azure Active Directory is the directory of record and the details of the group are synchronized to workload-specific directories as needed. SharePoint Online has its own directory (SPODS), so background processes synchronize changes from Azure Active Directory to SPODS to make SharePoint aware of new groups.
Given the success of Teams and Groups within Office 365, many new group-connected sites are being created, all of which use the simple model for permissions. In some cases, the group permissions model is the norm and tenant administrators aren’t aware that SharePoint has its own permissions model. This is especially so if the tenant never used or didn’t make extensive use of SharePoint on-premises.
Synchronization with SPODS
When a new Office 365 group is created and synchronization occurs to SPODS, SharePoint Online creates an owners group, a members group, and a visitors group for the site (Figure 1). The owners group represent the owners of the Azure Active Directory group (owners don’t have to be members). The members group are the members of the Azure Active Directory group, and the Visitors group isn’t used.
If you look in the Office 365 audit log, you see what happens in SharePoint when a new Office 365 group (or team) is created. Figure 2 shows that the [email protected] background process creates a site collection and updates SharePoint with groups for the new site collection (remember, every Office 365 group has its own site collection).
Only Share a Site
Having its own directory means that site owners can assign access to a site without adding people to the underlying Office 365 group. To do this, select Site permissions from the cogwheel icon, then Invite people and select Share Site only. SharePoint generates an email invitation to the targeted person to share the site and adds them to the members group. Because these people are only in the members group in SPODS and not in the Azure Active Directory group, they cannot access the other resources belonging to the Office 365 group.
Simplicity Clashes with Complex Permissions
Simplicity is good because it makes Office 365 Groups easy to manage. However, the lack of granularity in Office 365 Groups permissions can be worrisome if you’re accustomed to tweaking permissions to restrict site members, which then sometimes leads to the question of whether it’s possible to update SharePoint permissions for modern group-enabled sites to do the same.
Take the SharePoint permissions assigned to site members for instance. In on-premises SharePoint, the default permission level for members of a classic team site is Contribute, which means that site members can view, add, update, and delete list items and documents. It’s enough to get a lot of work done. But when SharePoint assigns permissions to members of an Office 365 group, they receive the Edit permission level. This is more powerful, because it means that site members can ad, edit, and remove lists and document libraries in addition to the Contribute permissions.
The group permissions model grants group members full access to group resources. It is the responsibility of individual applications to decide how this should be interpreted. Teams, for instance, allows members to create new channels, but also allows owners to decide if members should have this capability. On the other hand, Planner allows members to create new tasks and boards as they wish.
In the case of SharePoint Online, its developers obviously decided that the Edit permissions level more accurately matches the group model, so that’s why it is implemented for modern group-connected sites.
A case can be argued that allowing group members to create new lists and libraries is a bad thing because storage structure is a topic best left to administrators. The number of group members who want to edit the home page for a site or create a new list is probably low. Nevertheless, it seems like it would be a good thing for the SharePoint developers to follow the lead of their Teams counterparts and allow SharePoint administrators some level of control over what group members can do to create new objects within a site.
Public Groups are Very Public
The permissions we’ve looked at so far are for a private group. In other words, a group whose membership is restricted. Public Office 365 groups can be joined by any user in the tenant, so an accommodation is needed for them too.
Interestingly, the choice made for public groups is to give everyone in the tenant Edit permission (Figure 3). I can’t work out the logic for this because even if a group is public, users must join the group to gain access to its resources.
What might drive the decision is the need to expose documents to Delve and SharePoint Search. Delve has a “Discover documents from people around you” section where it highlights what the app considers to be documents that might be of interest to the user based on the analysis of signals in the Microsoft Graph.
If this is the case, I don’t understand why the permission level must be Edit for Delve (or search) to work. Surely the Read permissions level would be enough?
Customization Might be Unwise
Experienced SharePoint administrators will say that you can solve these problems by editing the permissions assigned to members within a site. This is true and it does happen. However, before you edit anything, ask yourself if this is a sensible course of action. It’s possible that you’ll do something that will have unexpected consequences in the future if you change permissions. No one knows how Microsoft might evolve the Office 365 Groups membership and permissions model, so risking changing something for a site now that might cause future issues might not be such a good thing to do.