While we all agree that security is important, SharePoint Online takes its security seriously. Maybe a little too seriously at times. And while having a lot of security levers to pull is good, it’s only as good as your understanding of them. This blog will explain some of the SharePoint, Azure AD, and Office 365 Admin roles a user can have.
We’ll start by describing the administrative roles available at the tenant level; then, we’ll drill down to what administrator roles are at the individual site collection level. You’ll have a good grasp of defining the correct roles for the correct use by the end.
SharePoint Administrators at the Tenant Level
Microsoft 365 is a big platform, and Microsoft has done a good job segregating the administrative roles so that a user can be given exactly the permissions they need and no more. The fancy name for this is the Principle of Least Privilege, and it’s a good philosophy to have when assigning permissions in SharePoint and everywhere else.
Users are assigned roles in the Microsoft 365 admin center. You can see which administrative roles a user has been assigned by opening the user’s properties or selecting the user and clicking “Manage roles” in the toolbar at the top of the Active user’s list.
You can also see which users have which roles by looking at the role details.
If you click on the permissions tab on the right, you’ll see the individual permissions that users with a certain role have. SharePoint admins boast an impressive list of permissions that allow them to manage SharePoint. They also have permission to manage Microsoft 365 Groups, create service requests, and more. The list of permissions each role has can be dizzying, and it changes and expands as the platform evolves.
To give us a fighting chance of keeping it all straight, Microsoft has given us the ability to compare the permissions’ roles to dial in the exact permissions a user needs. To do that, select two or three roles, then click the “Compare roles” link in the toolbar.
From here, you can see a SharePoint admin has more permissions than a Groups admin does. This screen would lead you to believe that a Global admin can’t manage Groups. I assure you they can, so double-check what a user can do if you’re trying to control their access. When trying to decide which administrative roles to give a user, you use the permissions list and comparing roles to give the user only the permissions they need to do their job, and no more.
Tenant Admin Recommendations
We’ve already covered that giving users the least amount of privileges necessary to do their job is the correct way to manage your tenant. What other tactics can you employ to keep your tenant safe and secure? We recommend limiting the number of Global admins in your tenant. When trying to get a new admin up to speed quickly, it can be tempting to make them a Global admin to ensure they can do what you need them to.
While that works, it opens them up to accidentally or on purpose cause problems. However, it is important to have more than one Global admin. There are a couple of special permissions that only Global admins have, like resetting a Global admin’s password, so it’s important to have two or three if one gets locked out or disabled.
Also, consider setting up Multi-Factor Authentication (MFA) on all accounts, especially the privileged accounts. Microsoft 365 and Azure offer several MFA levels, but all accounts have access to some amount of MFA protection. In today’s environment, enabling MFA is one of the first security steps any organization should take.
If your organization is big enough, you may have many people in various administrative roles. You can add them individually, of course, but Microsoft has other ways to handle it better at that scale. When a security group is created in Azure AD, you can assign an Admin role to it. Anyone added to that Group will get that Admin role.
Assigning Admin roles is also an option for Microsoft 365 Groups created in the Azure AD Portal. This way, admins also get access to a common Teams channel and SharePoint site to coordinate activities and store documentation. Anyone added to that Group will immediately have access to all the shared knowledge and the permissions needed to do the administrative tasks. No excuses for them not to hit the ground running.
Site Collection Admins, Site Owners, and Group Owners
Tenant Admins shouldn’t be the only ones that get to have fun. One of the most beautiful things about SharePoint is how it empowers business users. Once they have permission to a site, they can run with it and make it do amazing things without waiting for IT to configure it. Microsoft has also given us a fair amount of flexibility with that power, but it comes with some confusion. We have Site Collection Administrators, Site Owners, and Group Owners. Let’s break down those similar-sounding yet different permissions.
Site Collection Administrator
SharePoint has been around for nearly 20 years, and it’s changed a lot since the days of SharePoint Team Services 2001. One thing that’s changed is the guidance from Microsoft about using subsites. In on-prem SharePoint, especially older versions, we had to use subsites to get consistent navigation, search, and other resources shared across several sites. Subsites had some scalability issues, so in SharePoint Online, Microsoft added functionality, like Hub Sites, and discouraged using subsites. When we had subsites, that collection of sites was known as a Site Collection. Today, each Site Collection is usually having a single site, known as the root site, the difference between sites and Site Collections is somewhat fuzzy.
A Site Collection Administrator has full domain over the root site and all of the subsites in the Site Collection. They can change settings for the entire Site Collection like Search and Site Collection scoped Features. Site Admins can give themselves permission to any of the subsites, including ones that have broken their permission inheritance. They have ultimate power in the Site, or Site Collection, whatever you call it.
The person with this role should be somewhat technical as they’ll have access to all the settings in the Site Collection and could cause some problems if they flip the wrong switch or turn the wrong dial. They should also be part of the business team to help the correct people get access and help them get their job done.
Another vestige of the old days of SharePoint is a Site Owner who has elevated permissions to the Site or subsite, but not the Site Collection. While a Site Admin is responsible for the Site Collection’s configuration, a Site Owner is more responsible for the content of the Site and users who can add and edit it.
Today’s flat site structure doesn’t have a lot of need for users that are only Site Owners, so in most cases, the Site Admins and the Site Owners are the same people. For the most part, when you create a new site (Site Collection) in SharePoint Online, the person you add as an Admin or Owner is set to be both Admin and Owner.
The introduction of Microsoft 365 Groups (also known as Office 365 Groups or Unified Groups) brings another elevated role, the Group Owner. It is a group of users who will have full control of the SharePoint site and the rest of the Group’s resources.
Putting it All Together
Here’s where it gets ugly. Really ugly. We have three very similar roles, which is confusing enough. On top of that, the interfaces are completely inconsistent. There are places where you enter a value in a field called Site Owner, and that value populates the Site Admin field. It’s no wonder it’s so confusing.
When you create a Team Site that is not Groups-connected, the experience is also not consistent. The Site Admin is defined when you create the Site. It’s referred to as the Primary administrator. When you look at the permissions for your newly created Site, that user is now listed as both a Site admin and a Site owner. You can add additional Site admins in the SharePoint Admin interface, and more Site owners can be added to the Site itself by a Site admin.
Communications sites have a similar issue. When you create a Communications site, you’re asked to provide a Site Owner. That person is made the Site Admin and the Site Owner. Like Team Sites not managed by Groups, you can add more Site Admins in SharePoint Admin, and Site Admins can add Site Owners in the Site.
For the most part, if you can change the Admin or group Owner inside the SharePoint admin center, you’re changing the Site Collection Administrator, not the Site Owner. In many cases, you can see the Site Owners there, but you can’t change them.
To add a Site Owner, browse to the Site as a Site Admin or Site Owner, then click the gear and Site Permissions. Click Share Site and add the user and give them Full Control.
Now when you view Site Permissions, that user will show up under Site Owners.
If you miss the old SharePoint permissions screen, you can get to it by clicking the Advanced permissions settings link. Non-Group connected Team sites behave the same way.
If you have a Group connected Team site, you don’t add Owners to SharePoint. Instead, you add Owners to the Group, and Group Owners can manage SharePoint and the other Group resources. You can make that change in any Group connected application and impact all the Group applications. To do this in SharePoint, click the Members link in the upper right corner of any page in a Group related site. Add the new Owner to the Group. They’ll be added as a Member, so you’ll have to change their role from Member to Owner.
As you can see, the end-user Site Admin / Site Owner experience is disjointed and inconsistent. After you use it for a bit, though, you’ll get used to its quirks and weirdness. Of course, the interface may change by that time, and you’ll have to start all over. Isn’t the cloud great?
SharePoint and Microsoft 365 are complicated platforms with an equally complicated administrative structure. In this blog post, we covered the tip of that iceberg. We talked about how you can leverage Administrative roles in your tenant to manage SharePoint and how you can delegate some of the administrative duties to Site Owners. There are a lot of ways to change SharePoint permissions, and there’s enough fun for everyone.
Check out SPDocKit, a SharePoint administration solution that lets you manage SharePoint permissions for admins and other privileged accounts. If you’re planning to move to the cloud, SysKit Point might come in very handy. It lists all the privileged users and lets you manage user and admin permissions in bulk. It also lets site owners automate the access review process. For instance, they can see who else has ownership over their Groups and Teams and edit it if necessary.
Want to read more posts from us? Subscribe to our blog and stay updated.