Forum Discussion
EXO's "User" and "Trustee" properties returned from Get-Mailbox/RecipientPermission
Thanks very much for this, Vasil! That trick is priceless to know. I use -ReadFromDomainController in on-prem all the time, generally to immediately confirm changes I just made when in a slow replication/large forest . I did not know about it's trickery status in EXO.
So that's Get-MailboxPermission and Get-RecipientPermission, Get-MailboxFolderPermission already good to go. Now just GrantSendOnBehalfTo.
Thanks again.
##EDIT##: I've now tested the -ReadFromDomainController trick. To be honest, it's nice to know but I would otherwise call this completely ridiculous. When supplying ReadFromDomainController, the output of Get-MailboxPermission no longer returns ACE's, instead just an array of users in objects of type 'Deserialized.Microsoft.Exchange.Data.Directory.Recipient.ADUser'. It's nice and all, but this is A) undocumented, so very hard to rely on with any faith at all, and B) requires at least two passes with Get-MailboxPermission to get the concrete info. If there are more than 1 users with granted permissions, it's 1 + however many users = # of times to run the command. I know it's my own problem, but man I find this stresses me out. The effort to have done it this way should have been placed somewhere else to do it better and properly. I sound spoiled and thankless having said this stuff, and do feel a little bad, yet I will take the risk and call it what it is - unacceptable.
These kinds of shortcomings don't just exist in PowerShell land either, they also bleed over into the web UI, where admins of all experience levels may encounter them. We have lots of FullAccess/SendAs that has to be managed using PowerShell and with GUID-type properties for the -Identity / -User / -Trustee properties. Dang it I was happy, and now I'm said. Not very but a little.
##EDIT 2##: With Get-RecipientPermission -ReadFromDomainController, it actually returns the mailbox object itself, as many times as there are users who are granted permissions! As in, it's not even returning the users with the permissions granted, it's returning the mailbox that is granting out those permissions. Aye aye aye.....
For the duplicate entries you're seeing, can you confirm that one of the objects represents a GuestMailUser? I've seen it happen with other object types occasionally, but that's very rare.
- The duplicate thing, check your side with Get-RecipientPermission -Identity <MbxId> (with/without -Trustee <TrusteeId>) -ReadFromDomainController. You'll see what I mean. It outputs a recipient object for <MbxId>, as many times as there are Trustees to return from the ACE. It's not output the <TrusteeId> (or the list of Trustees' recipient objects).
I'm adding a wishlist item here for a new command in EXO PowerShell. Something like my Get-MailboxTrustee.ps1 script which can get FullAccess/Send-As/Send-on-Behalf/Folder Permissions. This wishful command would have parameters allowing us to choose which permission types to return. All of the various ACEs that are outputted would be one consistent object type where the User or Trustee property is a guaranteed unique [GUID] property (e.g., Guid, ExternalDirectoryObjectId, etc. (object/string, either fine)). I would delighted to see a new/official Get-MailboxTrustee command that works like this. Where it could excel beyond Get-MailboxTrustee.ps1 / Get-ExoMailboxTrustee.ps1, is that it could offer the option to do a full mailbox folder permission dump. Maybe someday...- Sorry, I wasn't clear. The duplicate entries when using ReadFromDomainController are unfortunate, luckily you get the correct object when combining it with the -User switch.
But for your original question, I'm curious whether one of the duplicate UPNs/PrimarySMTPaddress entries you're seeing corresponds to a GuestMailUser object.- In my current scenario, there are 2 separate Exchange orgs with Hybrid Configs into the same tenant. There are some users from org1 who have moved over to org 2. They only require 1 mailbox, but require a user account in both orgs, and need to be visible in both orgs' Address Books. This was accomplished by converting the original mailbox to mailuser and the externalEmailAddress is the new mailbox in org2.
Everything is happy with this arrangement, such as AAD Connect and AAD (no conflicts etc). The only issue is this mailbox permissions non-repudiation.
It's funny because I remember way back in 2004, my teacher Jim, who was teaching me courses for MCSA 2003, ways very vocal about the importance of non-repudiation in IT security and compliance. Here it is 20 years later and customers do not have guaranteed non-repudiation within their mailbox ACL's.