Table of Contents
Cleaning Up a Mess
Delegates are users granted access rights to another user’s mailbox or to a shared mailbox. Often, delegates receive full access permission to a mailbox to allow them to process inbound and outbound emails. The classic example is of an executive assistant supporting a senior manager. The assistant is the delegate with full authority over the manager’s mailbox and might even be able to send emails on their behalf or as the manager.
Delegate access is a well-known area of functionality for Exchange and Outlook. Despite different implementations in the various Outlook clients (here’s how it works for the mobile clients), things usually work without a hitch until some complexity arises. Dealing with emails encrypted using Microsoft Purview Information Protection (MIP) sensitivity labels is an example of that kind of complexity.
The good news is that Microsoft is enabling some control to how Outlook clients allow delegates to access and work with MIP-protected messages and their attachments. Differences exist between Outlook for Windows and the other Outlook clients interact with encrypted items and the controls Microsoft is now rolling out apply only to:
- Outlook Web App.
- Outlook for Mac.
- Outlook Mobile for iOS and Android.
- Mail App for Windows.
In their June 6 post, Microsoft acknowledges that “some inconsistencies” exist across the set of Outlook clients. Here’s what’s happening.
New PowerShell Cmdlets
The control is in the form of a set of three new PowerShell cmdlets in the Exchange Online management module. These are:
- Set-MailboxIRMAccess: Block a specified delegate from accessing encrypted messages in a user or shared mailbox.
- Get-MailboxIRMAccess: Check if a block exists for a specified delegate in a user or shared mailbox.
- Remove-MailboxIRMAccess: Remove a block from a user.
Full Access and Different Outlook Clients
Delegate access to encrypted messages depends on the type of mailbox and how the delegate receives full access permission:
- Outlook for Windows clients do not support delegate access to encrypted messages sent to user mailboxes. Delegates can only read encrypted messages if the sender includes the delegate as a TO or CC recipient. In this scenario, the delegate’s ability to read the message depends on the rights granted to them as a recipient. If the rights assigned to recipients include one applicable to the delegate, they can read the content. If not, they cannot.
- Outlook for Windows clients support delegate access to encrypted messages sent to shared mailboxes if the delegate has full access and auto-mapping is specified when the delegate receives permission to the mailbox. Auto-mapping forces Outlook for Windows to open the shared mailbox as part of the resources available to the delegate. It is the default used by Exchange Online and is assigned when granting full access to a delegate for a mailbox using the Microsoft 365 admin center or Exchange admin center.
- The other Outlook clients support delegated access to encrypted messages in both user and shared mailboxes if the delegate has full access to the mailbox.
Microsoft documents some restrictions that apply to delegate access for encrypted messages.
Blocking Access
To prevent delegates with full access to a user or shared mailbox from being able to view encrypted messages using clients other than Outlook for Windows, you can block their access by running the Set-MailboxIRMAccess cmdlet. For example, this command blocks the ability of Kim Akers to read any encrypted messages delivered to the Customer Services mailbox:
Set-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com -AccessLevel Block
To make sure that a block is in place, use the Get-MailboxIRMAccess cmdlet.
Get-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com Identity User AccessLevel -------- ---- ----------- Customer Services Kim.Akers@office365itpros.com Block
The time required to implement the block depends from client to client. OWA imposes the block within a few minutes, while other clients might take longer. It all depends when a client checks with the server to learn that a block is in place. When a block applies, delegates see that they don’t have the necessary permissions when they attempt to access encrypted messages (Figure 1).
A block placed on delegate access remains in place until an administrator removes it and only affects the ability of a delegate to read encrypted messages using clients that support the block. For instance, the block will stop a delegate reading encrypted messages in a shared mailbox using OWA or Outlook for iOS, but they can switch to Outlook for Windows to see the message content. In addition, blocking access does not hide message subjects, which can contain sensitive information, nor does it prevent a delegate from deleting or moving encrypted messages. The block exists for reading, and only works for clients that support the block.
To remove the block and restore the ability to read encrypted messages to a delegate, run the Remove-MailboxIRMAccess cmdlet:
Remove-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com
Good Block for Confidential Information
Microsoft is addressing a real customer need with these controls. There’s no point in protecting confidential messages with sensitivity labels if an unintended recipient (a delegate) can read the content. It would be nice if all the Outlook clients worked the same way. However, that’s probably too much to hope for until the One Outlook project delivers a common client across all platforms. Given the speed that Project Monarch is moving at, that might take some time yet.
Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.
One Reply to “Microsoft Introduces Control Over Delegated Access to Encrypted Email”