Welcome to this video on delegating administration using CoreView. Delegated administration is all about decentralization, in CoreView we accomplish this by enabling segmentation of logical boundaries across tenants to fit business needs, as well as by providing granular permissions that empower admins to take only those actions that they have specific administrative responsibility for.
The result is a more focused and modular administration model that can be customized to fit a variety of business needs. To accomplish all of this, we'll take advantage of two very powerful features of the CoreView platform, virtual tenants, and permission sets.
In a native administration model users and admins are bound to the physical limitations of the Microsoft 365 tenant. To segment responsibility and silo the admin experience, you must create additional tenant spaces to work in with CoreView's virtual tenants, you can create any number of logical boundaries that are not limited by notions of physical tenants.
Therefore, I might have several individual silos of visibility within a single tenant, or I could aggregate visibility across multiple tenants. The choice is driven by business needs as opposed to physical or logical boundaries. On the other side of this coin, granular permissions control what IT users can do.
In a native administration model, users and admins are delegated rights by role-based access controls. This is a good system, but often it results in administrators being either under or overprivileged for very specific administrative tasks. With CoreView permission sets, you can quite literally cherry-pick exactly what specific actions your administrators can take across a multitude of workloads.
In effect, you can design the exact administrative role required for very, very specific responsibilities. In the end, virtual tenants and permission sets allow IT to design and create specific administrative responsibility experiences for their workforce. So, let's look at a couple of examples. Here we are in the CoreView portal, the operator that I'm currently logged in with is a tenant admin. As you may have learned in a previous video, an operator is essentially a CoreView user.
In other words, the user context with which I'm working in the CoreView portal, again, this operator admin demo has tenant admin rights within CoreView.
This is effectively analogous to having global admin rights within native Microsoft 365. I'm currently looking at one of several tenants I have access to, and I'm viewing a teams-related dashboard to see all teams and teams' activity across this tenant. For instance, I can see here that I have upwards of 10,000 total teams within this tenant.
I could probably use CoreView to put some controls around how we manage the life cycle of those teams, but more on that in another video.
I have a simple active user's report saved as a favorite for this operator. Please see our other available videos for how to customize and save these reports this way.
But in this report, we can see that I have about 28,000 users across multiple departments within this tenant. Additionally, when I select a user, I have access to quite a few actions I could take against that user or any other object for that.
But I want to create a very specific experience for one of my IT operators. I want my operator to only be able to see users relevant to the departments they have responsibility for. And I also want to control what exactly that operator can do with those users. So, we'll start with the virtual tenant to control what my operator can see.
To accomplish this, I'll go to the user's context, and there are various ways that I can filter the user experience for this operator. For me, I want to specify a particular delegation filter. I'm going to add a couple of filters here. Filter one, I'll be looking for the department attribute. Now, as you saw in this dropdown, I can essentially choose from any attribute that is available from Azure Active Directory to pivot upon.
In my case, I care specifically about the department, so I'm going to select that, I want the department to equal, in this case, accounting services. But there are two different departments that this operator should have. Administrative responsibility. So, I'll be adding a second delegation filter with an OR condition operator. Once again, this is department equals accounting. So, what I've done here is defined a filter that says if and only if the department for a user equals either accounting services or accounting then show that user in the reporting. I can also under-tenants, define which tenants this operator will be able to run, and filter these users across.
I know that I want him to be able to work in the demo company tenant, but I also want them to be able to work in the demo partner tenant. So, in a couple of clicks, I've defined what users will be returned for this operator and in what tenants can he return those users. Note I'm creating an experience for a user management admin, but if I were creating an experience for an administrator of, let's say, groups, I could only give them access to groups the same way.
If I were creating an admin experience for a Team's voice administrator, I might limit them to phone number ranges. If I were making an admin experience for a SharePoint manager or device administrator, I might limit them to specific devices. So, the flexibility of the virtual tenant is such that we can build out and design very specific scoping mechanisms to limit the visibility of our administrators on a business need-by-business need basis.
That's the power of virtual tenants. So, I've got that virtual tenant all set up and ready to go. I'm going to go ahead and save it.
And if I search for it, I can see Accounting Department Demo is right there. So the other side of the coin is once this operator returns those specific users in their report, what will they be able to do with it? Enter the permission set. So over here in that same settings menu under permissions, I could do something very similar. Here's a list of all the different permission sets that have been created for this installation. Again, I'm going to create a new one, and again, I'll call it something like Accounting Demo Perms.
Now in the permission set, we can do some interesting things. First off, I can define what is the first thing that this user or operator will see when they come into CoreView. That might be a dashboard like that Teams dashboard I mentioned, that might be a specific report, perhaps that active user's report.
Let's just stick to that particular Teams dashboard just for simplicity.
What reports will this operator be able to run? Well, I know I want them to be able to run a basic active user’s report, maybe guest users, maybe inactive, all these user reports in fact. I don't need them to care too much about licensing or Exchange. Maybe give them access to a couple of Teams reports because we did give them access to that dashboard, so maybe they want to see which of their users are teams, maybe see the activity across those teams, maybe see the actual teams themselves that their users are part of, and so on. Once we've defined some things, we want them to see, in terms of things we want them to do, we'll go ahead and enable them for management actions, and we'll see how these manifest at the moment.
I could also allocate that saved report that we talked about, the favorited one I mentioned users by department, but the real meat and potatoes are the management action themselves. What actions will this operator be able to take once he's run these reports, well for his users, I might want him to be able to edit user properties.
Maybe he can edit their sign-in status, manage their licenses, manage their password, perhaps I want them to be able to reset multifactor authentication or just manage the multifactor dedication in general, but not to do any of these other things like cloning, deleting, creating. On the team side since we did give him access to some teams' information, maybe I want him to be able to add and remove members from those teams.
I don't want them to be able to archive, create, or edit teams themselves. That would be a separate independent Teams focus administrative responsibility I might build independently, but at least giving some cursory capability might be prudent here. If I have workflows defined for processes that are relevant to this operator’s responsibility, I might add those here as well.
I don't in this case, more on this topic in another video. So, for now, I think we're in good shape to go ahead and save this permission set.
And just to confirm, you can see Accounting Demo Perms. So, what I've done is I've created a virtual tenant to control what my operator can see, and I've created a permission set to control what my operator can do. Now we want to assign these objects to an operator, and luckily as tenant admin, I have visibility of the operators in my installation, and I just so happen to have an operator by the name of test operator.
We're going to go ahead and assign a virtual tenant and a permission set to this operator.
There we have it, the virtual tenant is assigned to him, and the permission set is assigned to them. Let's see what their experience is like when they login to CoreView.
Here we are at the login string for the CoreView portal, and as you can see, I've passed in the credentials for my test operator. This is an operator who has been given a virtual tenant and a permission set. So, let's see what the experience is like now.
Okay, so upon logging in, we land at that Teams dashboard that we delegated to this operator, and as you can see, the total number of teams is only 827 now as opposed to the 10,000 plus we saw with our admin, that's because these 827 teams happen to include users from within that virtual tenant scope, the accounting users.
Furthermore, over on the left here under reports, there are only a couple of things here. I have that one or two Teams reports that we allocated, I have that handful of user reports that we allocated, and I also have that customer report that we allocated users by the department. Go ahead and open that one up.
Now we're seeing about 1200 or so users as opposed to the 20,000 plus that we saw on the other operator's experience. And as a notice in that department column, all these users are part of either the accounting services or accounting department. So, let's go ahead and select a user and we'll notice quite a few fewer actions are available to me to take against these users.
Remember we talked about being able to manage licenses, manage multifactor authentication, and edit sign-in status, also we can add these guys to specific teams if we need to. So, as you can see, what we've effectively done is we have controlled the experience for our administrative operators within CoreView.
It's worth noting that the test operator has no administrative role permission set within Microsoft 365 itself. When the test operator goes to M365, they have the normal end-user experience. They typically have within 365. However, when they come to CoreView, and only when they come to CoreView, they have access to the reporting that we've delegated to give them visibility of the users that they manage, not only in this tenant but in the other tenant within our enterprise that they have administrative responsibility in.
Hopefully, this video has shown you some of the flexibility and some of the power of how to delegate administration effectively using the CoreView platform.
Interested in seeing delegated administration in action? Schedule your demo today.
