Securing SharePoint Online is a multi-layered approach and can get highly complex due to the nature of permissions. I would say most of the settings in SharePoint online are not secure by default so I wanted to write this article to show you how to lock down some of the default sharing policies for links that are generated across all documents in an organization. Its important to understand the end-user impact for both internal users and external users where links are being sent. Keep in mind, this is only one of the layers as it relates to overall sharing permissions within your environment. I will be covering other layers in future blog post.
Permissions are Nested
An important consideration in SharePoint is that there is a nested permission structure starting with the Global Settings that can cascade down at a site, document repository, and individual document layer. For the sake of keeping things simple, I am only going to be focusing on the default sharing settings at a Global Layer and site layer in this post. Effectively you can apply more granular settings at a site layer that don’t inherit your global policy so that you can apply more granular control. A common example of this is having a global policy that is more open and then restricting a site down so that users cannot share any documents within that site externally.
Sharing Links -User Flow
The user interaction here for sharing links is if they copy a link or click share on a SharePoint or OneDrive document, the sharing settings that will be captured come from your global policy (unless changed at a site level). By default, these are going to be Anyone links (meaning public access/no authentication required) and the documents will be editable.
This is highly concerning if we think about users sharing links to sensitive documents where anyone can access the link if shared which is why I like to modify the default settings.
Permission Options
We have four options we can choose from in the SharePoint Admin center for our external sharing settings.
- Anyone-Public links, unauthenticated users can access
- New and Existing Guest -Users need to specify emails of users they want to access a document. If a user that gets shared the link is not already a guest user in the company directory, they will be directed to a workflow to consent to be added as an External User
- Existing Guest – Users already need to be listed as an external user. Depending on Entra settings, only certain users, like Admins or users with the Guest Inviter role can invite other users.
- Only people in your organization -as noted, no external sharing.
New and Existing Guest-User Experience
So if we take a look at the options, I think we could agree that we would love to move off of public links as a global policy. This just seems way too insecure, right? Making the settings to just Existing Guest and Only people in the organization as our GLOBAL policy is not feasible in 99.9% of organizations that you manage. So let’s look at New and Existing Guest. The user experience actually gets pretty clunky here for external users so let’s see why.
If we were to change our global policy to this setting, when a user goes to share a link the default (unless we modify more settings) will be to only share with people in our organization. The user can modify that and specify individuals. You will also note that the Anyone link is disabled:
I like what I am seeing so far. In this use case they could choose individuals in their organization but I want to focus in on external users as this is where things start to break down. If they specify an individual that they will get a link to share. Lets say this user is in the CloudCapsule organization and are sharing with someone in the external tenant of Tminus365. The Tminus365 user will get a flow prompting them first to sign in with their Microsoft 365 account. (What if the user does not have a M365 account? Don’t worry, we’ll get to that shortly). After, they will get the following:
Two things here:
- Kind of deceptive wording given what we will see next
- Way to go on updating your copywrite year Microsoft 🙂
Again, if we capture the default settings, when the user clicks next and they are not already an external user in the CloudCapsule org, they will see a consent screen:
This is effectively so the CloudCapsule tenant can log activity with this user context in mind around this document/future documents they interact with. When they accept, they will be added to the CloudCapsule directory as an External user:
They won’t ever have to go through this consent flow again for future documents shared as long as they are kept as an external user in Entra. Next, the other HUGE thing to note here is that if you have a Conditional access policy that applies MFA to all users (which we all should), then this user will then be taken to set up MFA tied to their guest access. Two important things to note about this:
- If they already have MFA set up for organization this does not matter. They will be prompted to set up a NEW MFA method in the guest context
- If they use SMS for their 2fa in their tenant but you enforce Authenticator only for 2fa, they will have to use Authenticator as their second factor.
Gmail Users and Other 3rd party considerations
The user experience starts to breakdown even further if we talk about users sharing links to documents to users who do not have a Microsoft 365 account. I use a gmail address as an example as it would likely be the most common you see. My biggest beef is that these users still see the Microsoft login page when clicking the link:
This is likely a full stop for those users on moving forward on their own. Intuition would say “I don’t have a Microsoft account, what do I do?”
They can actually proceed forward without an account if they simply add their email address and hit next. Here they will be promoted to use a code to proceed:
They will get the code in their email to enter:
After, the same consideration for MFA applies. This has an even higher likelihood of breaking down in my opinion given gmail users:
- Might not have any MFA already
- Are more likely to not have something like Authenticator installed.
Additional Settings
So if you read that and thought, “this is a support nightmare” you are not alone. You could also quickly make people angry within the organization. For that reason, I think the progression would be the following:
- Leave the default sharing setting at Anyone
- Alter the additional File and Folder links for the default settings (shown below)
- Training users up before modifying defaults to New and Existing guest
- Provide more granular control at a site layer while you have Anyone settings to lock things down more granularly. (i.e. for the “Finance” site that has tons of sensitive internal documents, modify the external sharing settings to not allow outside the org.)
File and Folder Link Settings
Modify these settings to the following:
These settings modify the permissions on the default links generated. While users can manually adjust these settings when they share, there is likely to be much less of a proliferation of anyone links with edit capabilities. We are effectively trying to promote a model of least privilege while still giving users capabilities to alter.
Take note that the “View” permission can get users in a bad spot if they want to co-author docs but don’t alter the setting of the default link. What ends up happening is the receipient of the shared document ends up either:
- Reaching back out because they cant edit and the end-user contacts you because they don’t know how to modify
- The user it was shared with saves a local copy and they end up working off of two different documents which creates a bad user experience and confusion.
For this reason, its important to train users on best practices.
Altering settings at a site level
By default, all sites in your environment will inherit the global settings unless you individually alter them. This is a good way to provide more granular protection on sites while not impacting users across the board. In this example, we have our global policy still set to “Anyone” for the External sharing settings, but we have updated our Communication site, to New and existing guest:
Other Considerations
- As you could imagine, over time there could be a proliferation of external users in your directory. Its best to periodically review these users and delete ones that haven’t signed in for 30 + days
- There are a couple of other sharing settings you can set to expire the links/access for guest users you can leverage:
CloudCapsule: Reporting on these settings/configuration
I’ve built a tool that can allow you to explore these settings and configuration across your customers. I’ve mapped these policy definitions to the CIS Controls. Specifically, it can help you identify:
- Your default sharing policy settings
- All of your existing SharePoint sites
- Dormat Guest Users
You can run a free assessment to see what this looks like in your environment today.
Conclusion
SharePoint administration can get complex and confusing. While that is the case, that does not mean you can just ignore any type of data protection within the environments you manage. Planning is key when it comes to implementing these settings across an environment and understanding basic data flows the customer has with users external to their environment. I hope this article helped in understanding more about the link settings in SharePoint that you can use to better secure external access.