Reporting on Azure AD User objects via Exchange Online cmdlets and using them to grant mailbox permissions

Few months back, I blogged about an interesting observation that “plain” Azure AD Security groups can now be used to assign permissions to Exchange Online mailboxes. What was interesting in this scenario was the fact that all the familiar Exchange Online PowerShell cmdlets were oblivious to the existence of such objects, and happily reported an “object not found” error every time you tried to run them against an Azure AD Security group object’s identifier. The *-MailboxPermission and *-RecipientPermission cmdlets however do accept such groups as valid values and will allow you to configure permissions. You can find more information in the original article here.

Now, let’s examine a similar scenario for Azure AD User objects, more specifically user objects that are not recognized as valid Exchange recipients. Examples of such objects include non-licensed users, service accounts, objects synchronized from local AD and more. Generally speaking, any Azure AD user object without an email address assigned is a potential candidate, excluding Guest users. Here’s how to get a list of such objects:

Get-MsolUser | ? {$_.ProxyAddresses.Count -eq 0 -and $_.UserType -eq "member"}

or if you prefer the AzureAD PowerShell module:

Get-AzureADUser | ? {!$_.Mail -and $_.UserType -eq "Member"}

ObjectId                             DisplayName                                           UserPrincipalName                             UserType
--------                             -----------                                           -----------------                             --------
b1fbe4c6-d02c-447c-83c7-56c74df07197 Service Account for Cogmotive Reports                 CogmotiveReports@michev.onmicrosoft.com       Member
05fa5bac-b2d8-4952-800e-1e2d480e4d45 SfBUser                                               SfBUserSatya@michev.onmicrosoft.com           Member
fdd3c9ff-a101-4fec-84ba-3c42e3bef192 On-Premises Directory Synchronization Service Account Sync_DC01_052da20421fc@michev.onmicrosoft.com Member

Technically, the list generated from the above might be misleading, as in some cases the ProxyAddresses attribute isn’t correctly updated in Azure AD. In any case, we are interested in what Exchange Online knows about those objects, so how do we get this information?

Unfortunately, as with the Security groups case, the good old Get-Recipient cmdlets fails to return those users. For example, trying it against the Cogmotive service account results in this:

Get-Recipient CogmotiveReports@michev.onmicrosoft.com
The operation couldn't be performed because object 'CogmotiveReports@michev.onmicrosoft.com' couldn't be found on 'VI1PR03A001DC01.EURPR03A001.prod.outlook.com'.
+ CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=VI1PR03MB3920,RequestId=eaf8df8f-f33e-4db4-ba68-7d2ca11c06e9,TimeStamp=10/30/2018 3:08:36 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] A37BED4
2,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
+ PSComputerName        : outlook.office365.com

Bummer. But, the Get-User cmdlets comes to the rescue:

Get-User CogmotiveReports@michev.onmicrosoft.com

Name             RecipientType
----             -------------
CogmotiveReports User

So the object does exist in ExODS! Looking at its properties, one can spot a new value for the RecipientTypeDetails parameter, namely “User“. Thus, we can then use the following cmdlet to list all such objects:

Get-User -RecipientTypeDetails User

Name                    RecipientType
----                    -------------
Sync_DC01_052da20421fc  User
pta                     User
CogmotiveReports        User
SfBUser                 User

Interestingly, the “User” value is only accepted by the Get-User cmdlet, Get-Recipient does not recognize it. But cmdlets such as *-MailboxPermission and *-RecipientPermission do, and you can indeed use them to grant access:

Add-MailboxPermission sharednew -User SfBUserSatya@michev.onmicrosoft.com -AccessRights FullAccess

Identity             User                 AccessRights                                                                                                                                IsInherited Deny
--------             ----                 ------------                                                                                                                                ----------- ----
sharednew            EURPR03A001\SfBUs... {FullAccess}

And here’s the crazy part – you can actually access this mailbox now! Even though the user is in this shady, half-recognized state, and has no Exchange Online license applied, one can log in with it and use OWA to access the shared mailbox as shown below:

In contrast, trying to access OWA directly, without specifying the path to the shared mailbox results in:

This is of course the expected behavior, as the user does not have an Exchange Online license assigned, and is not considered a valid recipient. More surprising is the first scenario, as I didn’t expect that to work at all. Yes, we all know that Exchange Online does not enforce license requirements for some features and you have long been able to access a shared mailbox by directly logging in with the corresponding user account. But being able to access any mailbox via an account that is not even recognized as valid recipient is news to me.

At this time, I’m not at all sure that this scenario is supposed to work, and I’m almost 100% certain it’s not supported in any way. However, it does seem to work across different tenants, so it’s not just a temporary fluke. Whether it will continue working in the future, I cannot guess.

I wanted to also check how the audit logs reflect on access by such users, in particular what details for the delegate mailbox will be visible there, considering it’s half-recognized by Exchange Online. Luckily, it all seems to look just fine:

So, there you have it, not only Exchange Online now seems to recognize “pure” Azure AD user objects, at least to some extent, but one can actually use such objects to access mailboxes, even though the corresponding user doesn’t have either a mailbox or license applied. Fun stuff 🙂