A Fundamental Guide to SharePoint Online Permissions & Sharing Links

Posted on Updated on by antoniomaioCategories:Administration, Permissions, Security, SharePoint Sites, Sharing
gold colored abus padlock with key

I’ve found in recent months that conversations about AI and rolling out generative AI solutions to clients have reignited a number of previous discussions on the security and data protection of our content in the Cloud. Often, those conversations relate to the content in SharePoint Online (including OneDrive for Business and Teams) that may be available to a solution like Microsoft 365 Copilot. You’ll often hear me say at conferences that “we’ve been sitting on a mountain of risk in our SharePoint environments for a very long time because most organizations have not done a good job of managing permissions to content in SharePoint”.

As well, when we talk about the need to clean up permissions and better manage permissions or information sharing in SharePoint, there is often confusion about how permissions in SharePoint work and how Sharing Links work. This blog is intended to be a pragmatic guide to answer a few of those questions:

  • How do permissions in SharePoint Online work?
  • How do Sharing Links in SharePoint Online work?

Fundamentals of Permissions in SharePoint Online

In SharePoint Online, access to objects that are shareable is managed by assigning permissions to those objects. A ‘permission’ is made up of one or more users and/or groups plus a ‘permission level’. When assigning a permission to an object, one or more Entra ID users may be assigned, as well as one or more SharePoint Groups, Entra ID groups, or Microsoft 365 Groups. The ‘permission level’ that is assigned controls all of the detailed permissions that a user or group has on the object that is shared, and therefore it controls which actions a user can take on that object.

  • The objects that can be shared (i.e. shareable objects) include:
    • Sites (formerly site collections and subsites)
    • Lists or libraries
    • Folders (this also includes Document Sets)
    • Items and documents
  • Types of users and groups supported (also referred to as principals):
    • Entra ID users
    • SharePoint Groups
    • Entra ID/Azure AD Security Groups
    • Microsoft 365 Groups
  • The following built-in permission levels are available on most types of SharePoint sites:
    • Read
      • users can view site pages, lists/libraries and list items and documents within lists/libraries
      • users can download documents
    • Edit
      • users can view, add, edit and delete lists/libraries within a site
      • users can view, add, and delete items or documents within lists/libraries
      • users can can update and manage permissions on items and documents within lists/libraries
      • users can download documents within a library
      • users cannot manage permissions on sites
    • Contribute
      • users can view, add, edit and delete items on a site page
      • users can view, add, edit or delete items and documents within lists/libraries
      • users cannot create or manage lists/libraries
      • users cannot manage permissions at the site level
    • Full Control
      • users have all permissions and have complete control of the object to which they have permissions
    • Limited Access
      • users can view specific lists/libraries, items, folder or documents without giving access to all elements within a site
      • this permission level is typically not assigned manually to a user; rather it is automatically assigned to a user, when a lists/library, folder or item/document is shared directly with a user
      • it is designed primarily to give the user enough access to sites, lists/libraries, and folders so that a user can simply navigate down to an item or document that was shared directly with them.
    • View Only
      • users can view site pages, list items and documents
    • Design
      • users have almost full control access of a site, lists/libraries, and items/documents within a site, except that they cannot manage permissions at the site level and they cannot create SharePoint groups
  • Note: for older publishing site templates, mostly found in SharePoint Server or as classic SharePoint Online sites, there are additional permission levels available that are named: Approve, Manage Hierarchy, Restricted Read.

The following are a few definitions to keep in mind:

  • Principal – An individual user or group in this context is also referred to as a Principal.
  • Access Control List (ACL) – A set of permissions assigned to an object in SharePoint is also referred to as an ACL (access control list). An ACL is in fact a list of ACEs (access control entries).
  • Access Control Entry (ACE) – an ACE is in fact a combination of a principal and a rights mask (read, write, etc.). Think of the rights mask like a permission level, or a set of permissions.
  • Permission Scope – an object that has a unique set of permissions assigned to it. A permission scope applied to an object in SharePoint Online means that the object has a unique ACL assigned to it. A permission scope is a combination of the object that has unique permissions and the list of unique permissions (the ACL) assigned to it.

There are many ways to assign permissions to shareable objects in SharePoint Online, which I cover later in this article.

Inherited Permissions and Broken Inheritances

When you first create a site, and give a user or group access to it, it has one set of permissions at the site level. This is called a permission scope, which I go into more later. When I then create a new list or library within that site, by default it inherits the permissions from the site. When I then create a folder within a library, add documents to a library or items to a list, that folder, the items or documents inherits permissions from its parent (a list or library), which in turn inherits permissions from the site level. And so on… as I add more objects or content to a site, list, library, or folder that object by default it inherits permissions from its parent container. You can see that this creates a hierarchy within SharePoint, both related to content structures and permissions. Consider the following diagram, with a SharePoint hierarchy where permissions inheritance has not been broken, and therefore there is only one permission scope:

However, at any of those levels (on lists, libraries, folders, items or documents), I can break that inheritance and give that particular object a unique set of permissions. Envision a scenario where I have a site for my Finance Team, and it contains a library with 10,000 documents. That site (and therefore the library and documents within) are likely shared with and accessible by the Finance Team. If I want to share a particular document within that library with someone outside the Finance Team, I can navigate to that document to break inheritance on it and share it with that unique user. Consider the following diagram, with a SharePoint hierarchy where permission inheritance has been broken at Document Library2, Folder1, and Document5, and therefore there are 4 permission scopes:

When I break inheritance on a list, library or folder in the SharePoint Online user interface, that object immediately has all the permissions from its parent container copied to it. So, by virtue of breaking permission inheritance on library for example…

  • …that library will automatically have all permissions from its parent site. I can then edit the permissions on that library to remove some users/groups, edit some of the permission levels already assigned, or add some new users/groups with permission levels.
  • …as well, if I break inheritance on a library, list, or folder, all of the items/documents within those containers will now inherit permissions from container as opposed to the site.

Each time I do this, it creates a new ‘permission scope’ (see next section for more info). There are many ways to break inheritance and assign unique permissions in SharePoint Online, which I cover later in this article.

For more information on breaking permission inheritance and the impacts, see the following Microsoft article: https://learn.microsoft.com/en-us/sharepoint/manage-permission-scope#breaking-inheritance.

Permission Scopes

Each time I break permission inheritance on an object and assign unique permissions, it creates a new permission scope for that object. You can consider the reverse as well – that by default, every object in SharePoint inherits the permission scope of its parent, until you break inheritance on it.

Another way to think about this is that users have “explicit permissions” to a parent object at the top of the permission scope and they have “implicit permissions” for objects under that parent object.

This is important because there are limits and thresholds within SharePoint related to how many permission scopes you can safely create within a library. The thresholds and limits specifically refer to the library or list level. More specifically:

  • Threshold: a SharePoint document library or list performs best if you keep the number of permission scopes to under 5,000. When you exceed this threshold, then performance of your SharePoint Online instance can be degraded – that performance degradation is mostly felt when accessing that specific library. Remember, document libraries can still contain much more than 5,000 documents. The upper limit for documents in a library (or items in a list) is in fact 30 million. So, if 1 or more documents in a library inherit permissions from the library level, then they do not add to the permission scope count for that library. This threshold is really about keeping the number of documents within a library that have unique permissions to under 5,000.
  • Limit: a SharePoint document library or list supports up to 50,000 unique permission scopes.
  • Limit: users can only break inheritance on a folder if it contains 100,000 documents or less. Once a folder contains more than 100,000 documents, you will no longer be able to break inheritance on the folder. So if you need to unique share a folder, and therefore create a new permission scope, break inheritance on the folder before the folder contains more than 100,000 documents.

For more information about permission scopes and related scenarios in SharePoint Online, refer to: https://learn.microsoft.com/en-us/sharepoint/manage-permission-scope.

For more information about the service limits and thresholds for SharePoint Online, refer to: https://learn.microsoft.com/en-us/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits.

Permission Levels

The permission levels listed above are built-in and available out of the box on all sites. They can be edited if you wish, but that is not recommended. A permission level is made up of a combination of 33 unique built-in permissions. If needed, SharePoint Site Admins can create custom permission levels by selecting a combination of these 33 built-in permissions and give their custom permission level a unique name. Custom permission levels are created for specific SharePoint sites and cannot be shared across sites. If a custom permission level is required on multiple sites, it will need to be replicated on each site either manually or through code.

A custom permission level may be created by logging in as a SharePoint Site Admin, navigating to a specific site, clicking the Gear icon in the top right, clicking Site Permissions in the Gear Menu, clicking Advanced Permission Settings, clicking Permission Levels in the ribbon bar and then clicking Add a Permission Level. Again, this is only available to Site Admins on the specific SharePoint site (this role used to be called the Site Collection Admin). Rarely these days do we actually create custom permission levels, but its good to understand what makes up a SharePoint permission if you are going to effectively manage them.

It is highly recommended that you DO NOT delete or modify built-in permission levels. There are often old site templates or background processes that rely on these permission levels being there. In the rare circumstance that you need a custom permission level, copy a built-in one and modify it. If you click on the name of an existing permission level in the screen shown above, there is a “Copy Permission Level” button that lets use easily do this.

A History Lesson… and the Impact on Permissions

The user experience for configuring permissions manually in SharePoint has changed over the years, however the fundamentals above are still the same. First, a bit of a history lesson is in order:

  • In earlier versions of SharePoint, both on-premises and online, a top-level site was referred to as a site collection and below it we could have subsites, and below those subsites you could have more subsites, and so on. The site collection always started off with one root site, and you could truly turn it into a collection of sites. You could in effect create an entire hierarchy of subsites. This caused a whole host of issues with performance in the online world, users having difficulty navigating a deep hierarchy of subsites, information getting lost or orphaned in those deep hierarchies, and URLs getting very long with subsite after subsite appending to it. Today, we now only create site collections and we refer to them simply as “Sites”. As well, there is now the notion of a Hub Site, which lets you create a top-level site and “associate” other sites to the hub, in effect creating a hierarchy but one which is much easier to manage and maintain.
    • The hierarchy that can be created with a Hub Site and its associated sites (the sites within the hub) is just a collection of links, so its much easier to manage.
    • Moving sites between different hubs is just a matter of unlinking an associated site from one hub and relinking it to a new hub.
  • Then, in the mid-2010s or so, Microsoft started introducing the “modern” SharePoint UI in SharePoint Online. Whether you like the modern look or not, one advantage of it is that it is responsive by default… meaning it looks good and functions well on mobile devices, tablets and laptop/desktop screen sizes by default. Another advantage was a new way of interactively laying out your site page with new modern web parts. I believe Site pages first went modern with a new user interface, then libraries went modern, and so on… and now almost all of the SharePoint Online user interface is modern. At that point, sites and libraries with the old look and feel were declared to be “classic” SharePoint sites or “classic” SharePoint libraries.
  • In earlier versions of SharePoint on-premises and online, we had a large number of site templates we could either utilize or build ourselves. For those of us around back end, you’ll remember the Fab-40 site templates. A very common site template that was utilized extensively was the publishing site template. When SharePoint Online went modern, they eliminated most of those site templates and we were left with just 2 modern site templates:
    • Team Sites
    • Communication Sites
    • Note: there are now some site templates available from Microsoft, and you can create your own. However, the site templating mechanism is very different now and does not have as big an impact as it used to.
  • With the advent of modern Team sites and Microsoft Teams, we also got a new concept called a Microsoft 365 Group (or M365 Group). These new types of groups were similar to Azure AD (or Entra ID) groups, in that really they were simply an Azure AD group with a couple of differences:
    • They have a slightly different schema in the AD directory schema from your typical Azure AD security groups.
    • We really focus on the concept of a Microsoft 365 group a set of “owners” and a different set of “members”. You can envision the group allowing you to manage 2 different sets of users, with of course owners having more privileges that members depending on how the group is used.
    • They have a provisioning engine behind them, so that when an M365 Group is created, you also get a bunch of artifacts automatically created and associated with the group, like: a SharePoint site, a group Mailbox in Exchange Online, a Planner plan, etc.

This history lesson is important because when assessing SharePoint Online environments for a permissions clean-up activity, if there are old sites present that might not be used heavily (or at all) which were likely migrated from SharePoint on-premises a long time ago. In such a project, you’ll likely come across subsites, or classic sites, or old SharePoint site templates. And these legacy SharePoint artifacts tend to have different types of groups, or different user interfaces for setting permissions, or different default permissions applied. The fundamentals above are still the same, but the way those permissions were configured or their defaults can be different.

Default Groups and their Impact on Site Permissions

In SharePoint Online, when I create a site of any kind (modern or classic, top-level site or subsite), I end up with a default set of permissions assigned at the site level which are made up of 3 SharePoint Groups and specific permission levels. These groups and permission levels are structured to help simplify how a user can assign permissions to a site. They are:

Group NameGroup TypePermission Level
<site name> OwnersSharePoint GroupFull Control
<site name> MembersSharePoint GroupEdit
<site name> VisitorsSharePoint GroupRead

You can see this on a new site by navigating to the site, clicking the Gear icon in the top-right, clicking Site Permissions, and then clicking Advanced Permission Settings:

In both screenshots above, you can see the notion of Site Owners, Site Members and Site Visitors. The top screenshot is the modern experience for managing permissions, and I can use that to add any of those types of users. I can click the Add Members button at the top to either add members to the M365 Group (see next paragraph), or add users directly with permissions to the site. The bottom screenshot is the classic (old) permission management experience, which I personally still prefer because it shows me exactly the permissions that are assigned. It doesn’t try to obfuscate anything for me to make the experience “simpler”. In this case, it shows me that the 3 SharePoint Groups that were created are in fact “Antonio Demo 4 Owners”, “Antonio Demo 4 Members”, and “Antonio Demo 4 Visitors. This is important when you are assessing permissions across a large environment.

Modern Team Sites

Modern Team Sites are designed to be used as collaborative spaces within SharePoint Online, where owners and members can all produce, edit and share content collaboratively. When you create a modern Team Site, you automatically have a Microsoft 365 Group (M365 Group) created and “associated” with the site. We also say that the site is backed by an M365 Group. You can them manage access to the Team Site as follows:

  • Assign “owners” to the M365 Group and those users will have full control on the site. Not only that, the owners will be site admins as well for that particular site.
  • Assign “members” to the M365 Group and those users will have Edit permissions on the site.

It’s important to know that the M365 Group that is backing a modern Team Site, and its notion of owners and members, is a completely different object than the SharePoint Groups that are created by default with the words Owners, Members and Visitors appended to them.

So, this brings up the question – if I have a modern Team Site, and its backed by an M365 Group where I can manage its owners and members, and the SharePoint site itself has 3 different group structures created by default, which are also called Owners, Members and Visitors which I can use to manage access, how does one relate to the other and which one do I use to manage permissions?

Well, here is what happens:

  • As mentioned, when I create a modern Team Site, an M365 Group is automatically created and associated with the site. The site itself also has 3 SharePoint Groups created and named as mentioned above.
  • The members of the M365 Group are added to the default SharePoint Group which is named <site name> Members.
  • The owners of the M365 Group are added to the default SharePoint Site Admin list (what we used to call Site Collection admins).
  • Ultimately, you should manage access to a modern Team Site by adding members and owners to the M365 Group which is associated with the site. Because those members and owners are by default within the SharePoint groups that have been given certain permissions on the site, they will automatically get full control (and more) for owners and automatically get Edit permissions for members.

You can see the M365 Group Members within the SharePoint Members group by navigating to the modern site permission pane and clicking the down arrow on Site Members:

You can also see this by navigating to the classic site permission experience (clicking Advanced permission settings) and clicking on the members SharePoint Group to see its contents:

You can see the M365 Group Owners within the Site Admin list by navigating to the modern site permission pane and clicking the down arrow on Site Members:

You can also see this by navigating to the classic site permission experience (clicking Advanced permission settings) and clicking the Site Collection Administrators button in the ribbon:

A few other considerations about groups:

  • Notice that M365 Groups do not have the concept of a visitor or Read Only permissions. So, if you have a modern Team Site and you need to give user(s) or group(s) Read Only access to it, how do you do that? You simply add the user or group to the SharePoint Group that was created by default named <site name> Visitors. Since that group has the Read permission level assigned on the site, adding them to that SharePoint Group will give them the Read permission level.
  • The SharePoint Groups mentioned above are simply default ones that are created when you create a new site. You can create your own SharePoint Groups if you have the right permissions on a site, and name them whatever you want.
  • SharePoint Groups cannot be nested. SharePoint Groups live and are managed within the site in which they are created. In other words, if you create a SharePoint Group in one site, it cannot be used in another site. And multiple sites can have SharePoint Groups that are named the same thing. There is no admin center in SharePoint for managing all SharePoint Groups across all sites. SharePoint Groups do not appear in Entra ID/Azure AD, as they are purely a SharePoint construct.
  • Entra ID/Azure AD security groups can be nested. They are managed within Entra ID/Azure AD.
  • M365 Groups appear in numerous places, including Entra ID/Azure AD, and the M365 Admin Center. Owners and members of M365 Groups can be managed in multiple places, including SharePoint Online sites, in Teams, in the M365 Admin Center.
  • Within SharePoint Online, you can see the members of a SharePoint Group. However, you cannot see the members of an Entra ID/Azure AD group. You also cannot see the members of an M365 Group.
    • To view the members of an Entra ID/Azure AD Group, you must view them in Entra ID.
    • To view the members of an M365 Group, you can do so in Entra ID or in Microsoft Teams (only if you have access to manage a Team).

Modern Communication Sites

Communication Sites are a modern SharePoint Online site template which largely took over for old publishing sites. They designed for the publishing of content to an organization. Typical scenarios including enabling a small number of people to add, produce, edit and ultimately publish content which is consumed in a read-only fashion by a much larger number of people, like an intranet.

When a Communication Site is created, it does not create an M365 Group and there is no association between M365 Groups and Communication Sites. Upon creation, Communication Sites only have the 3 default SharePoint Groups created for them, which are mentioned above. Permissions are managed using either those 3 default groups, or assigning permissions directly to the site or the content within. Again, I can see the permissions on a Communication Site by navigating to the site, clicking the Gear icon in the top right, clicking Site Permissions to see the current permissions in the modern experience:

…and again, I can see the permissions in the classic experience by then clicking Advanced Permissions Settings and clicking one of the default group names:

Microsoft Teams and Sites/Permissions

With the introduction of Microsoft Teams a few years ago, we then got scenarios where SharePoint sites could be created automatically when a team is created – for example:

  • If I create a standard Team with standard channels, then one modern Team Site is created automatically and associated with the Team. The general channel stores its content in that site, and any other standard channel I create also stores their content in that same site. As a result, one M365 Group is created automatically and associated with both the Team and the modern Team Site.
  • If I create a private channel inside a Team, then one new modern Team Site is created automatically and associated specifically with that private channel. Each private channel gets its own dedicated Team Site. If a user stores content in that private channel, it gets stored in that new Team Site.
  • If I create a shared channel inside a Team, then one new modern Team site is created automatically and associated specifically with that shared channel. Each shared channel gets its own dedicated Team Site. As you can imagine, if a user stores content in that shared channel, it gets stored in that new Team Site.

As you can imagine, with extensive use of Microsoft Teams, the number of sites can proliferate very quickly, which ultimately complicates permissions review and management.

The best place to manage access to a Team is within the Microsoft Teams user interface. Within the Teams UI, you manage permissions to a Team (and therefore permissions to the SharePoint site behind it) by clicking the … beside a team name, clicking adding/editing/removing owners and members from the team. This ultimately adds members and owners to the M365 Group associated with the team and site, and ultimately gives those users permissions to the underlying modern Team Site. This will give the users access to all standard channels within a Team.

If you need to add a user which will have Read Only permissions to the file content in a Team, the only option you have is to navigate to a standard channel in the team, click the Files tab, click .. and then Open in SharePoint, and add the user to the default Visitors SharePoint Group (or give them Read permissions directly to the site).

Remember that for standard channels in a Team, it is only the contents of the Files tab that is stored in the SharePoint site behind the team. The conversation (ie. Posts) for example, is not – the conversation is actually stored in a group mailbox in Exchange Online, which is created and associated with the M365 Group. So, although you can go to the SharePoint site behind a team as shown in the last screenshot, and in SharePoint add all kinds of users to the site with all kinds of permissions, that will likely get out of sync with the owners and members of the M365 Group associated with the team. So we do recommend minimizing the instances in which permissions are modified directly on a site when it is associated with a Team in Microsoft Teams. Instead, we recommend using the owners and members of the associated M365 Group to control access.

For private or shared channel in Teams, permission management must be done in Microsoft Teams. Channel owners become sites owners in SharePoint and channel members become site members. Permissions in SharePoint cannot be managed separately and will display in read-only mode in the SharePoint UI.

Configure Permissions at the Site Level

Today, in Modern SharePoint sites, we configure permissions at the site level through either the modern or the classic experience. The following is the modern experience

  • Navigate to the site, click the Gear icon in the top right, select Site Permissions, and click the Add Members button
  • Select either ‘Add members to group’ or ‘Share site only’
  • If I click ‘Add members to group’, this will add the users that I select to the associated M365 Group
  • Before I click Save, I can click Member under the user’s name and select if I will add them as a member or an owner. Remember, this step is adding them to the M365 Group associated with the site and I must select if they will be in the Members list or the Owners list for that group.
  • If I click Share site only, this will give the user direct permissions to the site by adding them to one of the default SharePoint Groups created for the site (owners, members or visitors)
  • Before clicking Add, I can click the ‘Edit’ permission level below the user’s name and select if I want them to have Read access, Edit access or Full Control. This corresponds to adding this user to the Visitors, Members or Owners group respectively.
  • We can also navigate to the site, click the Gear icon in the top right, select Site Permissions, and click Advanced Permissions Settings to modify permissions manually. This will allow you to add users, other SharePoint Groups, other M365 Groups, Entra ID/Azure AD groups to the root of the site, or to the default SharePoint Groups, and select which permission level you want to assign them. You can also create new Groups here if you are a site admin.
  • After selecting a user, click Show Options to reveal options for selecting the permission level and whether or not to email the user

Configure Permissions at the Library Level

Configuring permissions at the library level (or list level) requires using the classic experience, even in modern Team Sites.

  • Navigate to your SharePoint site and then your library
  • Click the Gear icon in the top right and select Library Settings in the menu
  • On the pane which appears, click More Library Settings
  • Click the ‘Permissions for this document library’ link
  • This experience looks very similar to the classic experience for managing permissions on sites. However, there is one unique item – notice the yellow banner which says “This library inherits permissions from its parent. (Antonio Demo 4)”. Antonio Demo 4 is the site which this library is contained within, so this banner is telling you that this library inherits permissions from its parent site. As well, you can see the user David Drever added with Contribute permissions at the library level, which is a permission I added to the site level just in the previous example. Since the library inherits permissions from the site, it makes sense that it appears here.
  • To modify permissions on this library, I must first break inheritance with its parent. To do so, click “Stop Inheriting Permissions” in the ribbon bar.
  • Notice the warning message which appears. If I continue, any changes I make to permissions at the site level will no longer get inherited down to the library level and below. Click OK.
  • Now we can see that the banner has changed, and its telling me the library has unique permissions.
  • Now I can modify permissions on this library, by clicking Grant Permissions, Edit User Permissions, etc.
  • Whatever I change at the library level, will affect anything below it which inherits its permissions (like folders and documents), but it will not affect the site’s permissions above it.
  • I could navigate into each default SharePoint Group here and add users to those groups as well. However, if I do so, since the site level also uses those groups for permissions, those changes will affect permissions at the site level.
  • If I want to revert back to inheriting permissions from the parent level (a site in this case), I would simply click on Delete Unique Permissions in the ribbon bar.

Configure Permissions at the Folder and File Level

Setting permissions at the folder or file level are very similar:

  • Navigate to the folder or file that I want to manage permissions on, and either:
    • Click the … beside the item and click the Share menu, or
    • Select the item by clicking the checkmark just to the left of its name, and in the ribbon click the Share button
  • This will bring up a dialog from which you can share either the folder or file selected
  • Here I can type the users or group names, select them once they resolve, and I can click on the pencil/eye dropdown to determine if I want to share the item with the Read permission level (the eye) or in an Edit permission level (the pencil)
  • Here I also have the option to select if I want to prevent the user from downloading the item.
  • I can optionally type them a message, and click Send. The selected users will receive an email letting them know that they’ve been granted permissions to the item with a link to use to navigate to it.

If I once again click … on the folder or file I shared, and click Manage Access, I can see that permissions were granted to the selected user(s) or group(s). This works for both files and folders.

However, when I do this, I have necessarily broken permission inheritance on the folder or file in order to share it. If I click … beside the folder or document I shared, click Manage Access, and then in that page I click the … at the top right and click Advanced Settings, I can return to the classic permission page for that folder or document.

  • I can now see that the folder has unique permissions, and I can see the Contribute permission that I granted to 1 user in the previous step.
  • If I then click Delete Unique Permissions in the ribbon, the permissions I just added will be removed from this Folder and it will once again inherit permissions from its parent (which is a library).

Everyone and Everyone Except External User (EEEU) Permissions

There are 2 special built-in groups within SharePoint Online – they are the Everyone group and the Everyone Except External Users (EEEU) group. These are SharePoint specific groups and do not appear in Entra ID/Azure AD. These groups are automatically populated with all users in the tenant. They provide an easy way to grant permissions to everyone in the organization or even those users outside the organization that have been shared with. I can easily share a site, library/list, folder or item/document with everyone in the tenant or everyone except external users. That said, they are the source of a tremendous number of governance and security issues because of the broad access they can provide – literally to everyone.

When performing a permissions assessment and remediation project for SharePoint, an interesting question to ask is should users be able to share content with everyone in the organization from their OneDrive. Typically, OneDrive is a space for each person to store their work content, their early drafts, content that is not yet ready to share with others, and perhaps to do some light sharing from – as such, the answer is typically “no, users should not be sharing content from OneDrive with everyone in the organization”.

When I select a site, library/list, folder or item/document, I can easily share with EEEU:

If I now navigate to Manage Access for an item, and click the Groups tab I can see that this folder was shared with EEEU:

I can also see this in the classic Permissions Management page:

Although using these groups can be very convenient, because you know that anyone in your organization will be able to access something shared with EEEU, they have caused an extreme number of governance issues for organizations because significant amounts of content gets shared with all users. For example, if you have a site or library or folder shared with EEEU, then you add a document to it, that document will inherit that permission and automatically be shared with everyone in the organization.

It is possible to hide these groups, so that when users share content they are not able to select them. This can only be accomplished using the following PowerShell cmdlets:

  • Set-SPOTenant -ShowEveryoneClaim $false
  • Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false

Keep in mind, that all this does is hide these groups for all sharing instances going forward. Any place where these groups were utilized in the past are still sharing with Everyone or Everyone Except External Users.

Differences between Permissions in SharePoint and Sharing Links

Up until now, we have been configuring and managing permissions on sites, libraries/lists, folders, and documents/items. When a user has permissions to content at any one of these levels, Microsoft 365 Copilot will also have access to it and the actions they’ll be able to perform on the content will be controlled by the permission level granted. When performing a permissions assessments and remediation project, cleaning up these permissions so users only have access to the content they need is (initially at least) a point in time activity where we are looking at what do users have permissions to right now.

“Sharing links” however, are a different but related concept – very specifically for files and folders in SharePoint Online, I can create a sharing link to access them and send that link to a user. But, doesn’t this assign permissions to the content? Not exactly. A sharing link is in fact a URL that I can email to a user or send in a Teams chat message, and when a user clicks the link (at the time of click) the user is granted access to the item. Sharing links have the concept of “redemption” – when I create a sharing link to a folder or file, I am not giving users permissions to the content in the traditional sense. Rather, when a user clicks the link, we say that the link has been “redeemed” and the user is automatically given access to the content. Sharing links are only available for folders and files. You cannot create sharing links for libraries, lists or sites.

Depending on the type of sharing link, the content may or may not be searchable or accessible by the user when accessing Microsoft 365 Copilot. There are 3 different types of sharing links:

  • Anyone Links – give access to a folder or file to anyone who has the link.

Think of Anyone Links as a transferrable, revocable secret key. We say that Anyone Links are transferrable because they can be forwarded to anyone. We say that they are revocable because by deleting the link, you can revoke access for anyone that has the link. It’s secret because it cannot be guessed or derived.

People using an Anyone link do not have to authenticate, and their access cannot be audited. You can literally forward the link in an email to anyone in the world and they will be able to access the item by clicking the link. The only way to get access is to get the link, and the only way to get the link is for somebody to send it to you. Creating an Anyone Link does not make the associated content appear in search results, be accessible by Copilot, or immediately grant access to the content to everyone. Simply creating the link does not create any permissions. An Anyone Link must be redeemed by clicking the link before the content becomes searchable by the person in possession of the link. Anyone links cannot be used with files in a Teams Shared Channel site.

When creating an Anyone Link and sharing it with a user, it does not create a new permission on the file or folder that you can see in the UI (even the classic permissions management page). However, it does break inheritance on the item. If you then navigate to the classic permissions management page for a folder or file with sharing links, and you re-inherit permissions from its parent (i.e. you click Delete Unique Permissions in the ribbon), then all sharing links will be deleted for that folder or document.

  • People in your Organization Link – give access to a folder or file to anyone in your Microsoft 365 organization. They do not work for guests to your tenant.

You can also think of People in your Organization Link as a transferrable, revocable secret key. However, they only work for user accounts in your Microsoft 365 tenant. When a user clicks a People in my Organization link, they need to be authenticated as a member in your directory; if they’re not currently signed-in, they will be prompted to. Creating a People in your Organization link does not make the file or folder appear in search results, be accessible by Copilot, or grant access to everyone in the organization. Simply creating this link does not create any permissions or provide organizational-wide access to the content. To access the file or folder, a user must possess the link and they need to redeem it by clicking the link.

When creating a People in your Organization Link and sharing it with a user, it does not create a new permission on the file or folder that you can see in the UI (even the classic permissions management page). However, it does break inheritance on the item. If you then navigate to the classic permissions management page for a folder or file with sharing links, and you re-inherit permissions from its parent (i.e. you click Delete Unique Permissions in the ribbon), then all sharing links will be deleted for that folder or document.

Auto-Redemption – With People in your Organization links specifically, they may be automatically redeemed for individual users (without the users clicking the link) if the link is shared with up to 100 internal user(s) through the SharePoint or OneDrive Web UI, as an email in Outlook, or a chat message in Microsoft Teams. This does not work if the link is shared with groups or posted to a Teams channel conversation (only Teams 1-to-many chats). Auto-redemption in this case means that the content will be available for the user to search for using Microsoft 365 Search and it will be accessible by Copilot, when this specific type of sharing link is shared through those specific experiences.

  • Specific People Links – give access to a folder or file to specific users that you select when sharing the item.

A Specific People Link is a nontransferable, revocable secret key. It is nontransferable because, unlike Anyone and People in your Organization Links, a Specific People Link does not work if they are opened by anybody other than the users specified by the person sharing. You cannot forward it to anyone and have it work. In addition, unlike Anyone and People in your Organization Links, a Specific People Link will make the associated file or folder appear in search results and be accessible by Copilot for all user and security group members that were added to the sharing link.

Specific People Links can be used to share with users in the organization and people outside the organization. In both cases, the recipient needs to authenticate as the user specified in the link. For files in a Teams Shared Channel, Specific People Links can only be sent to others in the channel.

When creating a Specific People Link and sharing it with a user, it does not create a new permission on the file or folder that you can see in the UI (even the classic permissions management page). However, it does break inheritance on the item. If you then navigate to the classic permissions management page for a folder or file with sharing links, and you re-inherit permissions from its parent (i.e. you click Delete Unique Permissions in the ribbon), then all sharing links will be deleted for that folder or document.

For more information on how Sharing Links work, see the article: https://learn.microsoft.com/en-us/sharepoint/shareable-links-anyone-specific-people-organization.

One area where we see Sharing Links get created extensively is when we share something from our desktop, or OneDrive, or a SharePoint site with a user in a Microsoft Teams Chat. This inevitably breaks inheritance on the item and creates a sharing link. As a result, when performing a permissions assessment and remediation project for SharePoint Online, it typically must include OneDrive for Business as well. In my opinion, it is not enough to simply assess and cleanup the current state of permissions; you also need to assess and cleanup the sharing links that have been created.

User Experience for Working with Sharing Links

As mentioned, Sharing Links can only be created for folders and files. You create a sharing link by navigating to an item you want to share and either:

  • Click the … to the right of the item, select the Share menu, and click the Copy Link button in the share dialog
  • Select the checkbox just to the left of the item, click the Share button in the ribbon bar, and click Copy Link button in the share dialog

If you simply click the … on the item and click Copy Link in the menu, it does not create a sharing link. If you select the checkbox just to the left of the item and click Copy Link in the ribbon menu, it does not create a sharing link. In these cases, it simply copies a link to the clipboard to the item and only users that already have existing permissions will have access to the item with the link.

To create a Sharing Link, you must click the Copy Link button in this dialog:

In this case, my default Sharing Link type is Specific People Links, so I must select at least one user and click Copy Link. After you click it, you will see a message below it that will show you the type of access that the sharing link will grant. Its important to pay attention to that menu, so you know which type of link was created.

If you want to change the type of sharing link you will create, click the Gear icon beside Copy Link:

When I select a different link type in this dialog and click Apply, it does not create a Sharing Link at this point. I must click Apply, and then in the next dialog I must click Copy Link. For example, if I want to select a People in your Organization Link, I must select ‘People in ProCanadaTC’ and click Apply and then when it returns to the previous sharing dialog I must click the Copy Link button:

I can view the Sharing Links that have been created for specific folders or files by selecting the item and navigating to the Manage Access dialog:

From the screenshot above, I can see on the first tab that 4 users have access. However, I cannot tell which ones have direct permissions and which ones are a result of Sharing Links.

  • If I click on users in this tab, it will tell me the type of access they have – for example, if I click on David I see that he has Direct Access and can Edit (Direct Access means he has permissions to the file with the Edit permission level):
  • If instead I click on Test User 1, I can see that they have access through a Sharing Link:
  • If I click on the Links tab, then I can see the sharing links that were created:
  • On the main Manage Access page, if I click the … in the top right and click Advanced Settings, it takes me to the classic Permissions Management page. Here I can see a yellow banner at the top telling me that the item has unique permissions after creating a Sharing Link (remember you have to click the Copy Link button), but I cannot see the links themselves. I have to click the “Manage Links” menu and that will take me to the same page as above to see the links that were created.

Access to Anyone Links

All types of sharing links are available to all types of modern sites, except for the Anyone Links.

  • If a site does not allow external sharing with anyone inside or outside the organization (what we used to call anonymous guest access) then Anyone Links are not permitted. Here is what the Link Settings page looks like when sharing with anyone outside the organization is not permitted on a site:

However, if you perform the following steps to enable access to a site by anyone inside or outside the organization, then Anyone Links will be available:

  • Navigate to the SharePoint Admin Center > Policies > Sharing
  • Find the External Sharing settings, select the bar for SharePoint and elevate it to the Anyone setting and click Save
  • Navigate to Active Sites > select the site you are interested in
  • In the side pane which appears to the right, select the Settings tab, select the External Sharing dropdown, select Anyone for that site and click Save
  • Then, navigate to your site, select a folder or file you want to create a sharing link for, and click Share
  • Click the Gear icon beside Copy Link
  • You are now able to create an Anyone Link, in addition to the other link types

Configuring Default Sharing Link Types

Sites will have a default type of Sharing Link configured. You can adjust the default sharing link type for all new sites through the following steps:

  • Navigate to the SharePoint Admin Center, select Policies and Sharing in the left hand menu
  • Scroll down to the File and Folder Links section
  • Select the type of link that you would like to have as a default Sharing Link type for all new sites
  • Select whether Sharing Links will by default grant View or Edit permission level
  • If you allow Anyone Links, you can select some expiration and permission options for those

You can adjust the default sharing link type for a specific site through the following steps:

  • Navigate to the SharePoint Admin Center, select Sites and Active Sites in the left hand menu
  • Click the site name for the site you are interested in adjusting default Sharing Link type for
  • In the side panel which appears to the right, select the Settings tab
  • Click the More Sharing Settings link
  • Scroll down to the Default Sharing Link Type section
  • Deselect ‘Same as organization-level setting’ checkboxes and select your default sharing link type and permission level.

There is no way to prevent sharing links of specific types from being created for files or folders (except the Anyone Links as mentioned above). For more information on changing the default link type, see the following article: https://learn.microsoft.com/en-us/sharepoint/change-default-sharing-link.

antoniomaio