Peeking behind the curtain of ExODS – fetching the ADRecipient object

Here’s another interesting fact – did you know that you can expose the full ADUser object for Exchange Online users? Meaning that you can peek at the actual user object stored in ExoDS – the active directory at the backend of Exchange Online.

As we don’t have any supported method to access that data, a simple workaround is used. You need to get the folder level permissions of any user to which the “target” has been granted access. For example, if my account has any explicit permissions given to another mailbox, I can do this:

(Get-MailboxFolderPermission delegate:\calendar -User vasil).User.ADRecipient

In other words, the output of the Get-MailboxFolderPermission cmdlet will return the full ADUser object. Yes, the proper Microsoft.Exchange.Data.Directory.Recipient.ADUser object. It might not look like this if you look at the output because of the formatting used. However, if you expand the User property and then do the same for the ‘AD recipient’ property, you will be presented with the full object. Here’s a sneak peek:

PowerShell example ADRecipient

And by full, I mean full. 443 properties last time I checked! Basically everything you can get from Get-Mailbox/Get-User/Get-Recipient/Get-CasMailbox combined. And some added ones, for example the “c” or “co” properties found in AD, or the “DelegateListBL” and “DelegateListLink” ones (although those two don’t seem to be populated in my case). Another interesting catch is the “RecipientDisplayType” property, the value of which (“ACLableMailboxUser”) gives us a hint that Microsoft is close to enabling support for cross-premises/cross-tenant permissions.

Lots of other interesting properties to look at, some of which are pretty much unknown as they don’t exist on-premises. Some hints about “premium” features, most likely related to consumer accounts, Guest related properties, or things such as “HijackDetection“. Certainly some interesting stuff, however as this method is more of a bug/workaround, none of this is supported or discussed 🙂

So, in case you want to look at all these properties for some account, and more, all you need to do is grant said account any level of permissions to any folder of any mailbox. Even on your own mailbox. For example:

Add-MailboxFolderPermission vasil:\calendar -User vasil -AccessRights Owner
(Get-MailboxFolderPermission vasil:\calendar -User vasil).User.adrecipient

You can apply the same method for Groups, or in general any other object you can delegate permissions to. Sadly, not Modern Groups, as they are not considered mail-enabled security principals. But any other User Mailbox, Mail User or Mail-enabled security group should do. Have fun!

/// UPDATE 02.2022 I’m not that good in keeping my own articles updated it seems, as I’ve known now for a while that the method outlined above no longer works. The output of the Get-MailboxFolderPermission cmdlet now returns a PermissionSecurityPrincipal object, with just a handful of properties exposed. But, there are still some ways to “peek behind the curtain”. Behold, the –ReadFromDomainController parameter:

Get-MailboxPermission vasil -User huku -ReadFromDomainController

The difference here is that data for vasil’s user will be returned, so you can enter anything for the –User part. Well, any user that actually has a matching permission entry on the mailbox. If nothing else, you can use the ” NT AUTHORITY\SELF” principal. Or you can run it without the –User parameter, however you will get duplicate output for each entry, and that’s a lot of data. 505 properties at the time of writing to be more precise, for the corresponding Deserialized.Microsoft.Exchange.Data.Directory.Recipient.ADUser object returned. So you can still get properties such as DelegateListLink or RecipientDisplayType. Have fun.

5 thoughts on “Peeking behind the curtain of ExODS – fetching the ADRecipient object

  1. jake says:

    the delegatelistBL no longer seems to be returned. not sure what happened on MS side.

  2. Jeremy Bradshaw says:

    Just commenting to say thanks and good info. As of February 2022 I repeated the steps, only now using “.RecipientPrincipal” instead of “.ADUser” and it comes back with a smaller object, but still with some decent unique-ID-quality properties.

    1. Vasil Michev says:

      Yup, they changed it a while back. Buuuuuuut:

      Get-MailboxPermission vasil -User huku -ReadFromDomainController

      still returns the full Deserialized.Microsoft.Exchange.Data.Directory.Recipient.ADUser object.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.