The last thing you need in your Microsoft 365 tenant is another global administrator (many prospects we’ve talked to have over 10 Global Administrators!). Unfortunately, sometimes it’s the easy way out to just give someone the Global Administrator (or other high privileged) role so they can do their job. But how much access are you giving them? Do you know every permission granted in each of the Microsoft 365 roles? Also, what if you just want to give someone higher-level permissions over a subset of users in your tenant? Giving someone too much access (even by accident) leaves you open to security issues down the road.
In this blog post, we will highlight some of the benefits of limiting your admin access to your M365 tenant using CoreView and show some video examples using a scenario with “Bob from Accounting”. Bob is a manager in accounting, and we want to give him access to manage users in accounting but not users in any other department. Before we get started with Bob, let’s talk about a few concepts in CoreSuite and how they can be applied.
With CoreView you can segment your Microsoft 365 Tenant into sub-tenants or what we call Virtual Tenants.
Virtual Tenants can contain any Microsoft 365 object (users, groups, devices, even phone numbers). These objects are added to the VirtualTenant based on the query (or group membership) of any attribute in Azure Active Directory. Or to put it more simply, Virtual Tenant membership is dynamic, and doesn’t need to be manually updated when there are new users or groups.
You then select operators for the virtual tenant. Operators are the delegated administrators (or even department managers) who will manage the objects in the Virtual Tenant. When a Virtual Tenant operator logs into the CoreView portal, they will only see the objects in Microsoft 365 that are in the Virtual Tenant. This way, operators only see what they need to see (and manage) in Microsoft 365. Bob will be the designated operator for the accounting Virtual Tenant.
Next up is limiting permissions. In CoreView, you can create custom permission sets (similar to Roles in Azure Active Directory). CoreView permissions are very granular, allowing you to give access to only the items (or functions) you want the delegated administrator to perform.
For example, if you want HR to be able to update user information, you can do just that and not give them the ability to change anything else. We like to call this Functional Access Control because you’re giving access to just the functions need to perform the tasks. Functional Access Control also follows the least privileged access model by granting just the right permissions and not more.
Permissions also control which parts of the CoreSuite interface is visible to the operators. If the operators aren’t supposed to do anything with Exchange, you can remove all of the Exchange reports and management actions from them. Just like with Virtual Tenants, you assign operators to the permission sets. We’re going to create a custom permission set and make Bob the operator, giving him access to manage some user properties as well as some Microsoft Teams. The Virtual Tenant will limit what Bob can see and the permissions will limit what Bob can do.
In the following videos, I walk through a scenario of giving “Bob” from Accounting access to manage accounting users. First, I create a Virtual Tenant for the Accounting department and make Bob an operator on that Virtual Tenant. You can see the process here:
Next, I create a permission set giving Bob limited capabilities for the users in Accounting. Bob can only manage some of the user attributes and using the permission set, I can also limit what parts of the interface (and which reports) are visible to Bob. Here’s a video walk-through of creating the Accounting Permissions for Bob:
By combining the power of Virtual Tenants and permissions in CoreView, not only can you limit what delegated admins are allowed to see, but you can also limit what they’re allowed to do. If you’d like to learn more, please request a demo.
