Organizations often have content that is sensitive, even to those within the organization. This requires an extra layer of governance to ensure that it isn’t seen by anyone except the intended people. By using the Restricted Access Control (RAC) functionality within SAM, you can lock down your SharePoint team sites and ensure any site with sensitive content remains secure.
How does RAC secure your sites? Traditionally there are three ways to gain access to a site or its contents:
- Group Membership – If you are a member or an owner of a group that is connected to the site, you will, by default, have access to the site and all its contents. This is the most common access mechanism for modern SharePoint sites.
- Sharing Links – When a person with access to the site or contents generates a sharing link for you to gain access to the resources that they’ve shared. For general users, this is the most common way of granting access to others.
- Direct Access – Adding a person or group directly to a site (or piece of content on the site) is known as direct access. This is typically used by SharePoint admins when configuring solutions that involve complex permission structures.
When RAC is enabled on a site, only users within a specified group or groups are allowed to access and importantly, can be granted access to, the site and its contents.
Sharing links and direct access cease to work if the user in question is not a member of the group(s) specified by RAC. They will not be able to access the site or its contents, even if they previously had access. By restricting access based on specific group membership, the risk of oversharing is greatly reduced. This helps protect both your users and your sensitive content and is an important component of a broader SharePoint governance plan.
In this article, we are going to go through a step-by-step process of implementing RAC for M365 group connected sites and non-group connected sites.
Our Scenario – Human Resources Sensitive Content
Any organization that has a Human Resources department will know how important it is to keep employee information locked down and governed. There are significant risks involved with having unauthorized people see sensitive information such as employee salaries and employment contracts. In our scenario, we are going to be locking down two areas:
- The HR Department site – This site contains content only meant for HR to see such as employee contracts, disciplinary records, and other similar content. This is a M365 group connected site.
- The Remuneration site – This site is a shared site that both Finance and HR need to have access to, as it contains information about employee remuneration. This is a non-group site.
Each area will have a different implementation of restricted access control to govern it and ensure only the correct people have access to their content.
Requirements
Licensing
- SharePoint Advanced Management Plan 1 – You will need this per-user license for all your users, excluding guest users on your tenant.
- SharePoint K, P1, or P2 – These services are included within other licenses such as M365 Business, or M365 Enterprise.
Apps & Modules
- PowerShell – There are several versions and ways to access PowerShell, in our guide we will use PowerShell ISE.
- SharePoint PowerShell module – We suggest using the latest version of the SharePoint PowerShell module to ensure you have all the latest commands available.
Roles
- Admin Role – You will need the SharePoint Admin or Global Admin role to be able to make these changes to your tenant.
Step 1 – Enable RAC for your tenant
Before we can implement RAC on our sites, we will need to enable our tenant for it. Note, this doesn’t automatically apply it to any of your sites, so you don’t need to worry about adversely affecting your users or any of your content.
To enable it, we need to connect to our tenant using the SharePoint PowerShell Module in PowerShell and enable RAC with the following command:
Set-SPOTenant -EnableRestrictedAccessControl $true
Once you have successfully executed this command, it will take approximately an hour before you can start implementing RAC for your sites.
Step 2 – Govern Access for Group Connected Sites
With RAC enabled for our tenant, we can now start securing our sites. We’re going to start with our HR team site that is group connected. To do this, it’s as simple as using the following command:
Set-SPOSite -Identity <siteurl> -RestrictedAccessControl $true
Step 3 – Govern Access for Non-Group Connected Sites
Now that we have locked down our HR team site, we can look at restricting the access to the Renumeration site. As this site is not group connected, the setup process for RAC is slightly different. We first must enable RAC for the site and then we need to add the groups that need access to the site.
Enable the restricted access control
Set-SPOSite -Identity <siteurl> -RestrictedAccessControl $true
Set groups allowed to access the site
Once you have successfully run the command, PowerShell gives you a warning about adding the groups you’d like to be able to access the site. To do this, you’ll need to know the Group IDs of the groups you want to use. To do this, you can use the following command:
Get-SPOSite -Identity <siteurl>| Select GroupID
Note, your M365 groups will need to be security enabled to qualify to be used for RAC on non-group connected sites. You can ask your Entra ID Admin to set the existing M365 groups to be security enabled with the following command in the Azure AD module for PowerShell:
Set-AzureADGroup -ObjectId <groupid> -SecurityEnabled $true
We already have the required Group IDs to lock down our Renumeration site so we can apply them by using the following command:
Set-SPOSite -Identity <siteurl> -AddRestrictedAccessControlGroups <groupid>, <groupid>
Once you have successfully run the command, PowerShell will confirm that RAC has been configured for the site for the groups that you have specified and display the Group IDs for each of the groups.
Final Considerations
Why the restriction?
Governance efforts aren’t always popular with system users, SharePoint governance is no exception.
Before implementing this on a site, you need to ask yourself why are you placing a restriction on the site? By governing access, you are also limiting some of the core functionality of M365 and this could be seen as a hinderance to your users, so you always need to consider if the requirement could be better served by educating users, or whether the content is indeed sensitive enough to have this restriction placed on it.
Review Restricted Sites
If you are restricting multiple sites, you’ll want to keep track of them, to do this, the easiest way is to export your sites to an csv file and review the entries there with the following command:
$Sites = Get-SPOSite-Limit All | Export-Csv -Path "<folderpath>" -NoTypeInformation
