More on service principal permissions in Exchange Online

Few days back I briefly covered the advancements in Exchange Online’s support for service principal objects. In the context of said article, we only talked about Full access permissions, but since service principals are now supported objects in Exchange Online, the question remains which other functionalities support them. So let’s take a deeper look.

First, let’s briefly talk again about creating and managing service principal objects in Exchange Online. Since no process exists to synchronize Azure AD service principal objects to ExODS, you’ll need to create a matching representation of the SP object yourself. In order to do that, you can use the New-ServicePrincipal cmdlet, which by default is available to users assigned the Role Management role. You will need to specify the client ID (application ID) value, via the –AppId parameter, as well as the object ID, via the –ServiceId parameter. Here’s an example:

If you do not know the values for said parameters, you can obtain them from either the Azure AD blade > App registrations > Overview page, or via PowerShell (Get-MsolServicePrincipal, Get-AzureADServicePrincipal or Get-MgServicePrincipal cmdlet, depending on which module you prefer). Do note that the New-ServicePrincipal does NOT validate the values, so make sure you double- and triple-check them.

To list the current set of service principal objects recognized by ExODS, use the Get-ServicePrincipal cmdlet. Interestingly enough, the RecipientType value for such objects is User, whereas the RecipientTypeDetails is ServicePrinciple (note the spelling!). You cannot however use the Get-User cmdlet to list them, and Get-Recipient with the corresponding filter doesn’t work either. The Set-ServicePrincipal cmdlet can be used to update an existing object, although the only property you can change is the DisplayName. Lastly, to delete an existing service principal object, use the Remove-ServicePrincipal cmdlet.

Now that we covered the basics of managing service principals in Exchange Online, let’s turn into delegating permissions. We already covered the Full access permission in the previous article, but as a refresher you can grant permission via the Add-MailboxPermission cmdlet, by specifying the service principal identifier (display name, appId and serviceId will all work) as value for the -User parameter:

You can list, update and remove Full access permissions via the standard cmdlets. The EAC UI will display existing permission entries for service principal objects, but not allow you do add new ones. Interestingly, the new EAC will show you the GUID of the service principal, whereas the classic one returns its Display name. Another interesting thing is that the REST-based cmdlets cannot seem to resolve service principal objects by their DisplayName values, so you have to specify GUIDs instead:

Now that we’ve covered Full access permissions, the question remains is there any other permission types for which service principal objects are supported? Turns out, you can actually grant Send As permissions as well, by leveraging the Add-RecipientPermission cmdlet and providing the service principal identifier as input for the -User parameter:

As with Full access permissions, the EAC UI will show you any existing entries, but does not allow you to grant the permissions, so you have to stick to PowerShell. Even PowerShell however does not support granting Send on Behalf of or folder-level permissions, at least currently. So it seems currently only Full Access/Send As permissions are supported. Granting permissions aside, just how one would leverage them is not clear either, the only example of using Full access permissions granted to service principal can be found in this EHLO blog and the script linked therein.

We still have one last set of permissions to cover though, namely granting administrative permissions to the service principal object by assigning RBAC roles, or adding it as a member of a Role Group. Both operations seem to be possible (via PowerShell), but there are some very important caveats to consider. In a nutshell, only specific roles are supported, as we will see below.

For now, let’s see what happens if we try to create a direct role assignment to a service principal object. We can select a random role, such as say “Federated Sharing”, and try to assign it to the SP via the New-ManagementRoleAssignment cmdlet. Doing so will result in the following error message:

So while the process fails, the error message itself gives us a clue. Apparently, few months back Microsoft introduced a new type of role, a Service principal role, and a corresponding parameter was added to all existing roles, namely IsServicePrincipalRole. This is illustrated by the following cmdlet

I’ve truncated the output above, but since all the SP roles (the ones with IsServicePrincipalRole = True) have names starting with “Application”, we now have the full list of such roles. Interestingly, most of the roles seem to correspond to specific Graph permissions, such as Mail.Read. Another interesting observation is that a new Type property has been introduced for management role entries, with the corresponding parameter for the Get-ManagementRoleEntry cmdlet. In other words, you can also list all “ApplicationPermission” management role entries via the Get-ManagementRoleEntry cmdlet, as follows:

But I digress. Back to assigning admin permissions to service principal objects now. As we established above, direct role assignment is only possible for specific roles, such as the “Application Mail.ReadBasic” one:

For all non-SP roles, direct assignment will result in an error, as we already saw above. Turns out however that you can assign service principal objects as a member of a role group that contains non-SP roles. While the end result is disappointing, it’s still interesting to know that this is possible. Here’s how to assign a role group to a service principal object (as usual we have to use PowerShell):

where “test” is the identity of an already existing custom Role Group in my tenant. Usually, one can use the –GetEffectiveUsers switch of the Get-ManagementRoleAssignment cmdlet to “expand” role group based assignments and get a list of the corresponding user objects. This however does not seem to work with service principal objects, so you have to employ workarounds. Here are some examples:

Unfortunately, while the above examples show that it is indeed possible to add service principal objects as members of Role Groups, the permissions corresponding to any of the roles contained within said assignments are not available for use with the service principal login. One would hope that this method would finally allow us to use Role Groups for CBA scenarios for ExO PowerShell. However, this will result in an error as shown below:

The role assigned to application xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx isn’t supported in this scenario. Please check online documentation for assigning correct Directory Roles to Azure AD Application for EXO App-Only Authentication.

So in summary, Exchange Online now supports service principal objects. Those are objects of RecipientType User, with RecipientTypeDetails value set to ServicePrinciple. A new set of cmdlets has been introduced to manage them, namely *-ServicePrincipal. Service principal objects can be used to delegate Full Access and Send As permissions in app-only authentication scenarios, such as OAuth authentication via POP/IMAP. Folder level, delegate and send on behalf of permissions are not supported.

When it comes to admin permissions, service principal objects can of course be granted Azure AD admin roles. Within ExODS however, only a subset of the management roles are available for direct assignment – those designated with IsServicePrincipalRole value of True. And while you can add service principal objects as members of a group, including Role Groups, do not expect the corresponding cmdlets and functions to become available to the service principal. Well, perhaps any of the “Application *” ones would work

Before closing, it’s worth mentioning that you can use yet another “hack” to look at the full properties of the service principal object. Whereas the Get-ServicePrincipal cmdlet exposes only a handful of properties via the Deserialized.Microsoft.Exchange.Data.Directory.Management.ServicePrincipal object, you can get a lot more by fetching the Deserialized.Microsoft.Exchange.Data.Directory.Management.ReducedRecipient object as follows.

Few things to note here. The ExternalDirectoryObjectId value will match the clientID/appID of the parent application. No email addresses will be present and no Alias either, so while HiddenFromAddressListsEnabled is set to False, don’t expect to see service principal objects in the GAL. Interestingly, IsValidSecurityPrincipal is set to False, which is strange for an object that can be used for delegating permissions. But hey, it’s still in the early days I suppose.

I’ll circle back to this article at a later point to update it with new information as it becomes available. In any case, some more details on granting permissions to service principal objects and the corresponding use cases can be found in the official documentation.