The many faces of permissions in Microsoft 365

Like what you see??

"Ask Sympraxis" is a bi-weekly webinar series, where we discuss an array of topics and answer your submitted questions. Join us by downloading our recurring calendar event. You can also join us directly in the meeting without downloading the event.

See a listing of Ask Sympraxis episodes by topic covered: Topic List, Series List, or a full listing Archive

Permissions in Microsoft 365 can be complex, but a clear approach can help simplify management, protect data, and enhance collaboration. Below, we break down the highlights from our recent Ask Sympraxis session, The Many Faces of Permissions in Microsoft 365, which explores our philosophy on permissions, the many sharing settings, and best practices for permissions in Microsoft 365.

Sympraxis Permission Philosophy

Our core philosophy is to keep permissions simple. We recommend setting permissions at the site level without breaking inheritance, as this approach avoids complex configurations. Instead of creating one overarching site for multiple projects, consider creating separate sites for each project or unit of work. This structure reduces the risk of permissions mishaps and makes it easier to control access.

Microsoft 365 groups are another essential tool; they are membership objects designed to be reused across applications. Avoid adding members solely for short-term access, and instead use groups strategically to manage permissions efficiently. Educating users on sharing links is also crucial since these links can inadvertently bypass inheritance settings.

Modern vs. Classic Permissions in Microsoft 365 SharePoint and Teams

Whenever possible, stick with modern permissions. Modern permissions provide a simpler, more streamlined experience and are generally easier to manage. Classic permissions should only be used for cleanup, particularly when you need to review or adjust inheritance settings. Advanced permissions in classic settings can show where inheritance is broken but should be used sparingly.

Public vs. Private SharePoint Sites and Teams

The distinction between public and private sites is more impactful than many users realize. A public site or Team allows everyone in the organization (excluding external users) to make changes, which may be suitable for specific scenarios but usually isn’t ideal. Be deliberate when choosing between public and private settings.

Tenant-Level Settings

Tenant-level settings control organization-wide sharing policies, such as allowing or blocking guest users. Located within the Microsoft 365 Admin Center under Security and Privacy, this setting is somewhat hidden but fundamental. If guest access is turned off, existing guest users won’t lose access automatically, so it’s essential to understand the implications of these adjustments.

SharePoint Admin Settings for Tenant, Affecting SharePoint and Teams

In the SharePoint Admin Center, tenant-wide sharing settings apply to both SharePoint and OneDrive. These can range from allowing anyone with the link to access content to strictly limiting sharing to users within the organization. By default, guests can share items they don’t own, which can lead to security risks. We recommend unchecking this option for better control.

On a per-site basis, admins can set sharing restrictions, although these cannot override tenant-wide settings. To access advanced options, use the “More sharing settings” link, which will reveal additional controls for that specific site. This helps customize sharing capabilities on a site-by-site level within the broader tenant framework.

Site-Level Settings, Affecting SharePoint and Teams

Site-level sharing settings offer further control and are accessed through the Site Permissions menu. Within this menu, users can find the “Change how members can share” option, which allows administrators to control sharing settings at a more granular level. This is also the only place to manage access requests in the modern environment.

SharePoint Premium (SAM): Restricted Access Control

At the SharePoint tenant level, you can set restrictions to limit site access to a specific group in Entra ID. This means that even if a site owner adds someone as a member or owner within the site, they won’t be able to access it unless they’re part of the designated Entra ID group. This restriction also extends to file-sharing permissions, though this feature isn’t enabled by default and currently requires PowerShell to configure.

Microsoft 365 Permission Extras and Callouts

When choosing default sharing links, “Anyone with existing access” is usually preferable since it preserves permission boundaries. However, this option isn’t available at the SharePoint Admin level and needs to be set individually for each site. Provisioning services like ShareGate or Orchestry can help automate this if site creation is handled centrally. Also, remember that there’s no “deny” permission in SharePoint, so access must be managed proactively by not granting it initially.

Managing permissions in Microsoft 365 requires a balance between security and usability. By adhering to site-level inheritance, leveraging Microsoft 365 groups thoughtfully, and carefully setting sharing controls, administrators can create a secure and effective permissions strategy. For those looking to simplify and streamline permissions in their organization, applying these principles and exploring available tools can make a significant difference.

All Resources

Do you have any questions for us? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.