Mailbox and mail sending permissions

  • Article

I recently had a case where we encountered an "issue" where users granted full mailbox access and send-on-behalf-of to a shared mailbox were able to use OWA to send as the shared mailbox.

First, let's take a step back and review permissions. I've summarized it in a table here:

Type Permission Description How to Grant
Mailbox Folder-level permissions allows a user to access particular folders (e.g. Inbox, Calendar, Tasks, etc.) inside a mailbox Add-MailboxFolderPermission -Identity manager:\Inbox -User delegate -AccessRights Author
Mailbox Full mailbox access allows a user to do a secondary logon and browse the contents of a mailbox (read messages, edit the calendar, add new items, etc.) Add-MailboxPermission -Identity manager -User delegate -AccessRights FullAccess
Mail sending Send as allows a user to spoof a manager Add-ADPermission -Identity manager -User delegate -AccessRights ExtendedRight -ExtendedRights "Send As"
Mail sending Send on behalf of allows a user to send an email on behalf of a manager Set-Mailbox -Identity manager -GrantSendOnBehalfTo delegate

If a manager grants a user full mailbox access, they'll be able to log onto the mailbox (OWA -> Open mailbox, Outlook -> Open these additional mailboxes). If a manager grants a user delegate access (using Outlook), they'll have to use Outlook's File -> Open functionality and choose a particular folder. If it is a special/default folder like the Calendar, the delegate will be able to use OWA's calendar view to view/edit the manager's calendar. In both these cases, the delegates won't be able to send as or send on behalf of the manager because mailbox and mail sending permissions are of two different types.

Also something else to note: there are many ways to grant these permissions and I've only put down the Exchange PowerShell version. You can use Outlook, Exchange Management Console, Exchange Admin Center, and a host of other GUI tools to achieve the right permissions as long as they modify the appropriate data structures.

As it turns out, the "issue" I described earlier is a by-design behavior of Exchange and is documented here: https://blogs.technet.com/b/ehlro/archive/2012/04/06/full-mailbox-access-rights-send-on-behalf-send-as.aspx. Basically, full mailbox access + send-on-behalf-of rights = send as permissions. Even if you add an explicit deny for the send as right, delegates will still be able to send as the manager or shared mailbox. Usually, this issue surfaces with delegates because organizations grant delegates access to their manager's mailbox using 2 sets of permissions:

  • The manager uses Outlook to grant a delegate access to their mailbox so the delegate receives copies of meeting requests and other delegate-y features. What's happening under the covers is that Outlook is performing a variety of configuration changes, including granting folder-level permissions and send-on-behalf-of rights.
  • The Exchange administrator then grants the delegate full mailbox access to the manager's mailbox so the mailbox is automapped into the Outlook profile (what's really happening is that Autodiscover is returning an additional mailbox for Outlook to open).

I hope this adds some clarity to the different types of permissions used in Exchange and Outlook as I know it is a frequent source of confusion, even for me.

Edit on 7/27/2015: As of Exchange 2010 SP3 RU8, the Exchange Product Group acknowledged that a delegate that has full mailbox access should not be able to send-as the manager but only on-behalf-of. The previous behavior is a bug (https://support.microsoft.com/en-us/kb/2987104) and is fixed in 2010 SP3 RU8 and future versions.

Edit on 3/23/2017: TechNet has a good page summarizing these permissions as well: Manage permissions for recipients [Exchange 2016]

Cheers,

Matt