While reviewing the sharing and permissions on a department's shared mailbox, we discovered that the calendar permission for "People in my organization" had been changed from "Can view when I'm busy" to "Can view all details." Because employees sometimes include personally identifiable information in calendar entries, this may represent a privacy incident.
I started an audit search in Microsoft Purview, but when I entered the shared mailbox address in the Users field, I only saw activity performed by the mailbox itself. I need to determine whether other employee accounts accessed the mailbox or calendar during the past 180 days, including delegated users or people who may have viewed the calendar because of the overly broad default permission. The mailbox has a Microsoft 365 E3 license.
What audit searches or Exchange Online PowerShell commands should I use? Also, can events such as FolderBind or MailItemsAccessed identify who accessed the calendar, and what limitations should I be aware of?
2 Answers
You should first look for who changed the calendar permissions. Folder-permission changes and the corresponding Exchange admin cmdlets may be audited, so search for operations such as AddFolderPermissions, ModifyFolderPermissions, RemoveFolderPermissions, Add-MailboxFolderPermission, Set-MailboxFolderPermission, and Remove-MailboxFolderPermission. Then inspect AuditData to see whether the shared mailbox appears as the affected object and identify the account that made the change.
For example:
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-180) -EndDate (Get-Date) -Operations AddFolderPermissions,ModifyFolderPermissions,RemoveFolderPermissions,Add-MailboxFolderPermission,Set-MailboxFolderPermission,Remove-MailboxFolderPermission -ResultSize 5000 | Where-Object {$_.AuditData -like '*[email protected]*'} | Select-Object CreationDate,UserIds,Operations,AuditData
You can also check whether mailbox auditing is enabled and review the current calendar permissions:
Get-Mailbox [email protected] | Select-Object AuditEnabled,AuditOwner,AuditDelegate,AuditAdmin
Get-MailboxFolderPermission [email protected]:Calendar
A major limitation is that someone who merely viewed the calendar because the Default permission allowed it may not appear in mailbox audit logs. Auditing is more reliable for owners, administrators, and delegates with mailbox access than for every person who can view a shared calendar. If the permission change occurred outside the retention window, the audit system may not be able to establish who made it. Export any relevant results now, and run searches in smaller date ranges if you hit the 5,000-result limit.
The Users field is easy to misinterpret here. Searching for the shared mailbox as a user primarily shows actions performed by that account; it does not necessarily show every person who accessed it. Treat the mailbox as the target, then inspect the actor identified in each audit record.
You can start with Exchange Online PowerShell and search using the mailbox’s Exchange GUID:
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-180) -EndDate (Get-Date) -FreeText (Get-Mailbox [email protected]).ExchangeGuid -ResultSize 5000
Review the returned AuditData and UserIds for operations such as FolderBind, SendAs, SendOnBehalf, Move, SoftDelete, and MailItemsAccessed. FolderBind can indicate that a folder was opened, but it does not prove that someone viewed a specific calendar item. MailItemsAccessed is more useful for investigating actual access to mailbox items, when those events are available.
Also check the permissions separately, since audit records show activity while permission cmdlets show who was expected to have access:
Get-MailboxPermission [email protected]
Get-RecipientPermission [email protected]
Get-MailboxFolderPermission [email protected]:Calendar
This approach helped me retrieve useful records after finding the mailbox’s ExchangeGuid. The available audit history appears limited to roughly 180 days without additional licensing, so older activity may not be recoverable unless it was exported or retained elsewhere. I also tried filtering FolderBind by the GUID and received no results, which may simply mean there were no logged events for that period.
The audit settings appear to be enabled, but the permission change seems to be older than the available 180-day window. We are correcting unnecessary access now, although that may not let us reconstruct the original exposure.