What is Delegated Administration and what does it really mean? Delegated Administration has broad use in computing, and generally means how Role-Based Access Control (RBAC) is used to decentralize the administrative function through delegation of these admin duties. This replaces a centralized IT administrative model which no longer suits today’s enterprises that can’t keep up with all the tasks – whether critical or menial. The result – IT is overworked and unhappy – just about as unhappy as the end users they are trying to serve.
At the same time, delegating these tasks out to others without carefully managing permissions is a special kind of security nightmare. Delegated permissions should really encompass two complimentary concepts, delegating the IT function so it can be done by someone else, and assigning limited rights, which is where RBAC comes in. Adding to RBAC, we believe, is a move to true Least Privilege Access supported, in the case of Microsoft Office 365, by Virtual Tenants.
The use cases for Delegated Administration vary greatly, all the way from basic delegation to delegating near full-fledged rights. For example, through Virtual Tenants, one can be the equivalent of a Global Admin – but only for that tenant.
With basic delegation, the admin can only do low-level tasks such as a simple password reset. This basic delegation is often handled or assigned by local or group business managers, or HR staffers.
Organizations using Microsoft Office 365 (now called Microsoft 365) with a single tenant that contains multiple departments, remote locations, sister-companies, and different agencies have complex environments to support and manage. Most of them want to delegate administration rights so IT groups can manage their own business units independently — but stop short of giving out full Global Admin Rights to regional, local or specialized IT admins.
CoreView simplifies this entire process. To enable admin monitoring, reporting and account updates for these dispersed organizations, CoreView enables the portioning of tenants into smaller, more manageable sub-tenants, or what we call Virtual Tenants (V-Tenants). All user accounts, licenses and activities can be grouped and segmented by common attributes in a V-Tenant such as: Business Unit, Geographic Location, Department, etc.
This model makes the segmentation of a tenant feasible for large, distributed organizations. All accounts for a specific business unit are visible from the same CoreView interface and the IT administrators supporting that segment of users can perform bulk-actions across multiple tenants with a single click. More on Virtual Tenants later in the guide.
There are 6 Key Reasons to Use Delegated Administration for Microsoft 365:
Unfortunately, Microsoft 365 administration is too often a blunt object, with admins laden with global credentials or assigned broad overly powerful and insecure roles. That is why so many M365 shops turn to CoreView. “One of our initial criteria we communicated to Microsoft was that we needed to delegate our administration, so our members can control their own users and data. We found this feature lacking in the native M365 admin. Empowerment in M365 requires delegation to the individual libraries who want and have the capacity to administer their own data and users. We needed to grant them that administration as much as possible,” said Tobin M. Cataldo, Executive Director — Jefferson County Library Cooperative, Inc. Birmingham, Alabama.
The set of administrative roles provided by Microsoft for a Microsoft 365 deployment are designed around a centralized management model. Within the native M365 Admin Center, there is no way to setup regional management rights for administrators who ONLY want to monitor and manage their local business unit or geographical site users. For large enterprises, or companies that are split into multi-tenant Microsoft 365 environments, there are complex administration requirements to support their deployments. What if they want to delegate admin tasks by different countries, business units, or office locations? What if they want to enable help desk engineers to perform ONLY simple admin tasks on their regional users?
By delegating tasks formerly done by M365 Global Admins, your IT staff saves myriad man hours that can be taken as pure savings or devoted to more strategic tasks and projects.
Let’s assume 30% of M365 tasks currently handled by central IT can be delegated to other operators, perhaps even power M365 users that work in local company departments. These tasks could include help desk requests, password resets, Microsoft Teams configuration, or provisioning new employees. This simple change could save a 10,000-seat organization with 5 central IT admins 2880 hours a year in the time spent. That represents either $270,000 a year in pure savings or 240 hours per month of time freed for central IT to do other things.
CoreView’s administrative sweet-spot is our ability to allow you to segment your organization into individual ‘Virtual tenants’ that you then then manage individually and our ability to then allow you to delegate permissions out to those business units.
These partitions, or Virtual Tenants, can be defined using a Security Distribution or Microsoft 365 Group, leveraging existing structures already in place in many organizations. Virtual Tenants can support:
Virtual Tenants are a CoreView construct that brings back the administrative points that we had in on-premises Active Directory. We used to create organizational units, and then we would assign administrators to those OUs, and those administrators could then do things for the users and machines and groups and so on in that OU.
A CoreView Virtual Tenant is basically scoping those accounts, but also applying it in Azure Active Directory. We lost that OU concept in Azure AD, so we will either import your existing OU structure if you’re doing Azure AD Sync or directory synchronization, or we can allow you to create new administrative points based on Azure AD attributes: department or city or location or Exchange custom attributes, or some combination of those. With those Virtual Tenants offering scope, and the permissions in the Least Privilege Access model, admins can only perform those actions granted them for users in your Virtual Tenant.
One can think of Virtual Tenants as dividing the organization into administrative units. Then you grant them Least Privilege Access within those Virtual Tenants. Lastly, workflow lets IT get granular – right down to the attribute level: IT can allow a delegated admin to create a Microsoft Teams channel, but since they are in the ABC department, IT can enforce naming conventions so that the Microsoft Teams channel gets created with ABC dash. Then the name the delegate selects for the Microsoft Teams channel is put through a workflow that insures that an actual person has to approve it and make sure that it’s not duplicating functions, and so forth.
These three components together provide a truly powerful and unique Least Privileged Access delegation model.
Before granting administrative access, IT should know precisely what is being given. That access should be granular, and based on the actions they’re taking and the function they’re trying to perform — not just a role. You don’t want to simply grant Exchange admin rights, which can change mail routing, when all the person needs to do is create a mailbox. Nor do you want to give them Microsoft Teams admin rights, which can delete Microsoft Teams channels, if the person only needs to create Team channels.
These admin limitations based on functions offer true Least Privilege Access. Roles are a Band-Aid on the Least Privilege problem, and Functional Access Control is the solution that we’ve all been looking for.
