Cross-forest delegation troubleshooting for Office 365 Dedicated/ITAR customers (vNext)

Symptoms
Microsoft Exchange Online vNext customers have problems in the functionality of their "full access" permissions, "send as" permissions, and delegate access for objects in different environments.
Cause
For cross-forest delegation (including "full access" and "send as" permissions) to work as expected, multiple requirements must be met.
Resolution
Cross-forest delegation requires a specific configuration in the cloud and in the on-premises Active Directory Domain Services (AD DS) environment. The following are common troubleshooting scenarios:
  • Delegate/Delegator
  • Full user access and "send as" permissions to shared mailbox

Delegate/Delegator

Overview

In this scenario, the delegate can view certain folders in the delegator's mailbox. The delegate also has "send on behalf" permissions to the delegator's mailbox. The delegate is added to the publicDelegates attribute(also known as the GrantSendOnBehalfTo attribute in Microsoft Exchange Server)on the delegator's mailbox and is granted folder-level permissions to the mailbox folders. This scenario requires the following:

  • The ability to add a user from another forest as a delegate.

    Objects for each user must exist in both the cloud and the on-premises environment. The user will be a mailbox object in one environment and a mail-enabled user in the other environment. To add a mail-enabled user to a delegate, the value of the msExchRecipientDisplayType attribute must be set to -1073741818. This value makes the object ACLable. That is, it lets the object be added to an Access Control List (ACL). Outlook recognizes this object, and the object is added as a delegate even though it's not a mailbox in the delegator’s Exchange environment. 

    By default, this value is configured in the cloud. However, the customer must configure a process to update this value for all mail-enabled users in their on-premises Exchange environment (representing cloud mailboxes). Starting in Microsoft Exchange Server 2013 CU10 (on-premises Exchange installation), all mail users will set the appropriate msExchRecipientDisplayType attribute.

    Legacy Dedicated customers moving to vNext

    Mail users in the legacy Dedicated environments will be ACLable. Individual mail users in vNext can request to be manually updated. For more information, see KB 3187967 Can’t add another mailbox in Outlook after migration to Office 365 Dedicated/ITAR (vNext).

    Exchange 2010 and Exchange 2013 (before CU10 release)

    Users can update provisioning scripts or processes to configure any newly provisioned remote mailbox as ACLable. A cmdlet that resembles the following example should be integrated into the provisioning processes. This cmdlet is run against the on-premises AD DS for the RemoteMailbox object. This object is represented as a mail user object. 

    Example:
    Get-ADUser $User| Set-ADObject -Replace @{msExchRecipientDisplayType=-1073741818}
    Exchange 2013 CU10

    When Exchange Server 2013 CU10 is publicly released, you'll find new functionality that lets an administrator run an organizational change to set synched objects as ACLable in Outlook. After that, calls that are made through the Mailbox Replication Service (MRS) will enable on-premises MEUs as ACLable.
    Set-OrganizationConfig -ACLableSyncedObjectEnabled $true
  • The ability to access the mailbox folders cross-forest in Outlook.

    This functionality is available in clients that are running Office Outlook 2007 SP1 or a later version.

  • The ability for the delegate to send on behalf of the delegator.

    The "send on behalf" permission exists in the environment that hosts the delegator mailbox when the delegate is added in Outlook. This permission is granted when the publicDelegates attribute is set in one environment and is synchronized to another environment that uses Azure AD Sync (AAD Sync). The name of the attribute in Exchange is GrantSendOnBehalfTo.

    By default, the value of this attribute is synchronized from the on-premises environment to the cloud. However, the value doesn't sync from the cloud to the on-premises environment. The customer must create manual transformations in AAD Sync to flow this attribute to their directory. These transformations must be configured by the customer in their installation of AAD Sync.

    • Incoming new sync flow from cloud AD to the local metaverse:
      FlowType = Direct
      Target Attribute = publicDelegates
      Source = cloudPublicDelegates
    • Outgoing sync flow from the local metaverse to the on-premises AD:
      FlowType = Direct
      Target Attribute = publicDelegates
      Source = publicDelegates

    This means that a delegate is removed from the delegator's mailbox in the cloud, and then the change is synchronized to the on-premises environment by AAD Sync.

    Note By default, future versions of AADConnect will flow this attribute down from Azure AD.

Feature responsibilities

For the customer:

  • AAD Sync manually transfers the publicDelegates attribute from the cloud to the on-premises Azure AD. 
  • Mail-enabled users in on-premises AD must set the value of the msExchRecipientDisplayType attribute to -1073741818 (this is the default value in Exchange 2013 CU9 and later versions). Therefore, they are ACLable.
For Microsoft:

  • Forward Sync from Azure AD to Exchange Online

    When an attribute is synchronized with AAD Sync to Azure AD, the forward sync process synchronizes the appropriate values in Exchange Online.
  • Mail-enabled users in the cloud must set the value of the msExchRecipientDisplayType attribute to -1073741818. Therefore, they are ACLable (Office 365 dedicated customers only).
  • BackSync transfers the CloudPublicDelegates attribute from Exchange Online to Azure AD. This enables the customer AAD Sync transformation to flow the value from Azure AD to the on-premises AD (Office 365 Dedicated customers only).

Troubleshooting

If users report problems when they try to complete delegate-related tasks, follow these steps: 

  1. Scope the case appropriately.

    • Who is reporting the issue: Delegate or delegator?
    • What is the problem they’re seeing? For example, users cannot add a delegate, cannot remove a delegate, or the delegate cannot use "send on behalf" or access a particular folder.
  2. Review the publicDelegates attribute (also known as GrantSendonBehalfTo attribute in Exchange) from the on-premises AD DS and Azure AD to confirm that the permissions are configured correctly.

    1. On-premises Active Directory attributes can be exported by using the Windows PowerShell Active Directory Module.

    2. Azure Active Directory attributes can be exported by using the Azure AD module (download file and instructions are available at Manage Azure AD using Windows PowerShell).
  3. Based on the information that's provided, review the Overview and Feature responsibilities to determine where the misconfiguration may exist.

Full user access and send as permissions to shared mailbox

Overview

Objects for each user must exist in both the cloud and on-premises environment. The user will be a mailbox object in one environment and a mail-enabled user in the other environments. Send as and full access permissions are stored in the Access Control List (ACL) in the user object and are not replicated by AAD Sync. Send as permissions are checked in the environment of the mailbox of the sender or delegate. This can add complexity to scenarios that involve delegates and shared mailboxes in different environments. The full user access permission that enables access to the mailbox isn't affected by mailboxes in different environments. In a hybrid environment, it's expected that send as permissions may have to be managed on two objects.

Send as permissions in the cloud are managed by using the Exchange Online cmdlet, Add-RecipientPermission. Send as permissions on-premises are managed by using the Exchange cmdlet, Add-ADPermission.

Full access permissions are managed by using the Add-MailboxPermission cmdlet.

There are two scenarios that involve permissions:

  1. Delegate mailbox is on-premises, and the shared mailbox is in cloud.

    When the shared mailbox is moved to the cloud, the Exchange MRS copies the full access and "send as" permissions ACLs during the migration. All permissions that are already set on the mailbox are transferred and remain on the mail-enabled user in the on-premises environment. The delegate will continue to be able to send as and access the mailbox because the permissions exist on the object in the on-premises environment. If the delegate is later moved to the cloud, no additional change is required. Users will continue to be able to send as the mailbox because the permissions also exist on the mailbox in the cloud. If permissions are changed after the mailbox is moved, additional steps may be required.
  2. Delegate mailbox is in the cloud, and the shared mailbox is on-premises.

    "Send as" permissions

    The "send as" permissions must be added to the mail-enabled object in the cloud that represents the shared mailbox. The customer can prepare for a migration by completing a one-time scan of the mailbox permissions in the on-premises environment and by manually adding these permissions to the objects in the cloud. Any "send as" permissions that are changes after the mailbox move must be manually updated on the shared mailbox objects in both environments.

    "Full access" permissions

    The "full access" permissions remain on the mailbox on-premises after the migration. Additional steps may be required when you add new permissions.

Feature responsibilities

For the customer:

  • Management of permissions in on-premises and cloud Exchange environments

Troubleshooting

  1. Scope the case appropriately:

    • Which users and shared mailboxes are involved?
    • What environment hosts each mailbox?
  2. Request a copy of AD DS permissions from the on-premises AD DS and Exchange Online:

    1. On-Premises AD DS attributes can be exported by using the Windows PowerShell Active Directory Module:

    2. Exchange Online permissions can be exported by using Remote PowerShell (RPS):

  3. Based on the information that's provided, review the Overview and Feature responsibilities to determine where the misconfiguration may exist.
Properties

Article ID: 3064053 - Last Review: 11/14/2016 21:55:00 - Revision: 8.0

Microsoft Business Productivity Online Dedicated, Microsoft Business Productivity Online Suite Federal

  • vkbportal226 KB3064053
Feedback