Send-On-Behalf Permissions in Exchange Online

Posted on Posted in exchange, exchange online, Exchange Server, hybrid, permissions, send-on-behalf

This document is up to date as of March 2018 and is therefore unlike many earlier documents on this issue as this feature set is in the process of changing.

First, Send-On-Behalf is changing so that it is supported across a hybrid Exchange Server to Exchange Online connection. At the time of writing this is in the process of being rolled out, so it might well be in your tenant by the time you read this.

But even if the config for this is enabled in the cloud, there is config that is needed on-premises. In Exchange Server 2013 you need to be on the latest CU and then run Set-OrganizationConfig  -ACLableSyncedObjectEnabled $True (as mentioned in https://technet.microsoft.com/en-us/library/mt784505%28v=exchg.150%29.aspx). For Exchange 2010, this is not an option (and the ACL sync needs to be done manually) and for Exchange 2016 this cmdlet is enabled already. [Note, discovered April 2018 that this is not true, and Exchange Server 2016 needs treating in the same way as Exchange Server 2013 regardless of what the Microsoft article says at the time of writing]

So what does -ACLableSyncedObjectEnabled $True do – well it changes Exchange Server so that all MoveRequests completed after the change leave behind a RemoteMailbox object where msExchRecipientDisplayType is -1073741818. For reference before the change to the OrganizationConfig this value on a RemoteMailbox was -2147483642.

msExchRecipientDisplayType Value
SyncedMailboxUser

-2147483642

ACLableSyncedMailboxUser

-1073741818

An ACLableSyncedMailboxUser is one that can have Send-On-Behalf permissions set or maintained across on-premise and the cloud – that is once your tenant is  updated as well.

This though leaves a few issues – the main one is that the RemoteMailbox left behind by the MoveRequest is only set to -1073741818 where the RemoteMailbox is made by a MoveRequest. If once you have moved all your users you start provisioning users directly in the cloud, then New-RemoteMailbox or Enable-RemoteMailbox will not set msExchRecipientDisplayType to -1073741818.

Therefore provisioning of users directly into the cloud with –RemoteMailbox will need the addition of Set-ADUser to update the msExchRecipientDisplayType after the RemoteMailbox is created. The cmdlet for this is the same cmdlet that you need to run if you are using Exchange 2010. This cmdlet is Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

This  cmdlet would need to be added to your provisioning scripts, and if you don’t have scripts to provision users in AD and have a mailbox in the cloud, then now is the time to look at this as the number of moving parts is growing.

If you do not do the msExchRecipientDisplayType change then some of your remote mailboxes in Exchange Online will be able to be granted permissions for Send-On-Behalf and other permissions as they are added to the cloud, as they are ACLable (as in we can set them in Access Control Lists, ACLable!), and others users will not be. To make these changes you need to change the msExchRecipientDisplayType on-premises to -1073741818 and wait for this to sync to Azure AD and then wait for that to sync from Azure AD in the Forward Sync process to your Exchange Online directory.

2 thoughts on “Send-On-Behalf Permissions in Exchange Online

  1. Thanks for sharing and mentioning thus. Hopefullly Send As will follow soon as with folder/calendar permission.

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.