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:
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 Outlook.com 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.