Did you know: Search-Mailbox adjusting permissions on target folder

While browsing the Unified audit log in search for events related to some tests I performed the other day, I noticed something interesting. Namely, the “copy search results” workflow initiated by good old Search-Mailbox cmdlet took care of stripping folder-level permissions for people that might have ended up having access to the TargetFolder, where the result of the search was being stored. How very nice!

Here’s the scenario in short. I did some tests with moderation, and wanted to get my hands on the actual messages exchanged between the user and the system mailbox facilitating the moderation functionality. While you can easily grant yourself full access permissions to said mailbox, the messages in question are hard-deleted and can only be found in the Purges folder, to which regular clients do not have access. Enter Search-Mailbox. A quick search allowed me to target the messages in question and save a copy to another mailbox, where I could easily examine them. Which is exactly what I did.

Some time later I was checking the unified audit log for any events that might relate to the moderation tests performed earlier, and the following entry caught my attention:

Since I’m pretty much the only user within my tenant who can play with permissions and I certainly didn’t perform that action, I needed to understand what’s happening here. Interestingly, the Logon User Sid value above did match my user account, however the Client Info String and IP address values give us a clue that the action might be performed server-side, plus External Access is marked as true. Expanding the event details shows additional clues, in particular details about which particular permissions were modified:

Since the “Moderation” folder was the one I designated as value for the -TargetFolder parameter when running the Search-Mailbox cmdlet, the mystery was solved. What in fact was happening is stripping any folder-level permissions that might be inherited from the root folder of the mailbox, in effect ensuring that only users with Full access permissions will be able to access the content copied via the Search-Mailbox cmdlet. Just to confirm this, I checked the root folder permission entries on said mailbox:

Get-MailboxFolderPermission sharednew | ft -AutoSize

FolderName User AccessRights SharingPermissionFlags
---------- ---- ------------ ----------------------
Top of Information Store Default {None}
Top of Information Store Anonymous {None}
Top of Information Store shared {Reviewer}
Top of Information Store Pesho {FolderVisible}

There you have it, two entries in addition to the Default and Anonymous ones. In fact, those two entries are the exact ones that were stripped, as they are effectively inherited from the root upon creation of any new folder, be it client- or server-side. Thus, the good folks at Microsoft have ensured that such permissions will not interfere and potentially allow access to people that should not have it in the first place.

I imagine this behavior is not something new, it’s just something I haven’t noticed before. I do find it useful though, and decided to share it as an example of a nice finishing touch to an already very useful functionality. Oh, the good old days where products were being coded by people that actually knew them in and out 🙂

And yeah, I’m not actually using a Discovery mailbox here, but that only increases the value of this automatic permission removal.

This entry was posted in Exchange Online, Microsoft 365, Office 365, PowerShell. Bookmark the permalink.

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.