Few months back, Microsoft extended the Exchange RBAC model to cover application access scenarios. To support this, a number of building blocks were added to the service, and now it looks like some of them are making they way to the “sister” Security and Compliance Center endpoint too. Let’s cover how SCC handles service principal objects and the type of RBAC controls you can apply to them!
To begin with, a refresher. As detailed in our initial examination of the updated ExO RBAC controls, Azure AD service principal objects are not automatically synced to ExODS, at least for now. This means that you will have to use the New-ServicePrincipal cmdlet to create a matching object before you can create management role assignments for the corresponding application. The same applies to the SCC endpoint now, where the New-ServicePrincipal cmdlet has been made available. In the future, Microsoft should make this step irrelevant and will automatically sync the relevant objects from Azure AD.
Here’s how to use the cmdlet to provision a new service principal object. First, don’t forget to connect to the SCC endpoint (via Connect-IPPSSession), as you might end up working with the ExO cmdlets instead. Make sure you collect the ObjectID value of the service principal and the AppId of the parent application, which you will have to provide as part of the creation process (-ServiceId and –AppId parameters, respectively). In addition, a DisplayName should be added. Here’s an example:
New-ServicePrincipal -AppId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -ServiceId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -DisplayName "Service Principal for ExOPS app" DisplayName ServiceId AppId ----------- --------- ----- Service Principal for ExOPS app xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
You can use the Get-ServicePrincipal cmdlet to list any existing service principal objects, Set-ServicePrincipal to update a SP’s display name (no other properties are editable) or Remove-ServicePrincipal to delete an existing SP. Most importantly, once a SP object is present in the directory, we can leverage it for RBAC assignments. Next, let’s see which RBAC operations are supported.
Unlike the Exchange Online scenario, we don’t have any SP-specific roles just yet. Which is interesting, as SCC operations actually have better coverage within the Graph, compared to ExO admin operations. On the positive side, the IsServicePrincipalRole property has been added to existing roles, which indicates that Microsoft might be adding such roles in the future. That, or they’re simply “borrowing” some of the ExO bits. While we don’t have any management roles corresponding to Graph API scopes, we can still use the existing roles to assign permissions to a service principal, as we will see next.
Apart from the service principal object (the “who”) and management roles (the “what”), to create a proper RBAC assignment we need one more building block – the management scope (the “where”). Unfortunately, no news on this front it seems – the SCC still does not expose any management scope cmdlets. Which is puzzling considering they just added support for scoping some functionalities based on Administrative units, as we discussed in this article.
With the above in mind, you’ll likely won’t be surprised that the New-ManagementRoleAssignment cmdlet is also not available, so we cannot use it to create “manual” management role assignments. What we can do however is add the newly created service principal object as a member of existing Role Groups, which effectively leverages existing management role assignments. Similarly, we can create new Role Groups and add the service principal as member. The caveat here is that we can only perform these operations via PowerShell, as the relevant UI bits do not yet recognize service principal objects.
As a simple example, let’s take a custom Role Group I’ve created, named “Search only”. The Role Group has a single management role assigned to it, namely Compliance Search. Effectively, a single management role assignment exists, as shown below:
Get-RoleGroup "Search Only"
Name AssignedRoles RoleAssignments
---- ------------- ---------------
Search Only {FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/Compliance Search} {FFO.extest.microsoft.com/Microsoft Exchange Hosted
Organizations/michev.onmicrosoft.com/Compliance Search-Search Only}
To add our newly provisioned service principal object to the Search Only Role Group, we can use the Add-RoleGroupMember cmdlet as follows:
Add-RoleGroupMember -Identity "Search Only" -Member xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
where we need to provide the ServiceId value for the service principal object. We can now verify the SP is a member of the Role group:
Get-RoleGroup "Search Only" | select -ExpandProperty Members FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/michev.onmicrosoft.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Interestingly enough, the Purview Compliance Center UI does actually list the SP object as member:
Other than that though, there is no UI support for any operations on service principal objects in the Purview Compliance Center. In addition, the handy Test-ServicePrincipalAuthorization cmdlet is also not available.
Even with all the limitations and missing bits mentioned above, this is a nice little addition to the service. Being able to manage Role group assignments for service principal objects means we can now create granular assignments for scenarios such as using Certificate-based authentication, much like we detailed here in the case of ExO. Granted, we cannot go as granular as with the ExO scenario, but it’s still a nice step forward.
Whereas previously CBA connections to the SCC PowerShell endpoint required the assignment of one of the “blanket” Azure AD roles listed here, we can now tailor access to better suit our needs. In the example above, any connection leveraging the service principal object will only get access to the Compliance Search cmdlets (in addition to few “personal” ones). The screenshot below illustrates this:
And that’s a good thing!
P.S. Thanks to Neil Murphy over at the Q&A forums for the tip on this!