Prepare Office 365 Exchange Permissions for Riva Connections

Article ID: 1114
Last updated: 12 Mar, 2019

Requirement for Riva EWS connections that use impersonation: The Riva connection user must be assigned permissions that enable impersonation access into the "target" user mailboxes.

Office 365 supports both Exchange Application Impersonation and Delegate Full Access options, but they depend on which Office 365 edition the customer is subscribed to:

Contents:

Exchange Application Impersonation Permission

Enterprise Office 365 subscriptions support

  • assigning the Exchange ApplicationImpersonation role to a single user and
  • defining a scope (list of users) that the permission can be used against. With most customer environments, the scope will be all user mailboxes.

There are two methods to assign the Exchange "ApplicationImpersonation" role:

Assign Exchange Application Impersonation Role in the Exchange Admin Console. (Recommended.)

Follow this procedure in the Office 365 Exchange Admin Console to assign the Exchange user mailbox (service account for the Riva connection) to an admin role that will grant the impersonation access permissions.

In the following example, Rivasvc@mycompany.com is the Riva Cloud EWS connection user.

To create and assign a role with ApplicationImpersonation:

  1. Log in to Office 365 as an Admin user. You should be working in a blue and white minimalist theme.

  2. On the menu bar, select Admin; and on the drop-down, select Exchange.

  3. In the left column navigation pane, select permissions. Under admin roles, in the tool bar, select the + icon.

  4. In the Role Group window, provide a name and optionally supply a description, select the ApplicationImpersonation role, and add the Riva connection user to the Members list.

  5. Select another role, and then select the role that was just created, and confirm that the description information looks correct.

Assign Exchange Application Impersonation using Powershell

Administrators can use Windows Powershell and connect to their Exchange Online subscription to issue PowerShell cmdlets to assign Application Impersonation role to the Riva connection user with a default scope of all user mailboxes except the admin user.

  1. Connect to Exchange Online by using remote PowerShell. For instructions, go to this Microsoft webpage: Connect to Exchange Online using remote PowerShell.

  2. Enter the following command to execute the cmdlet to assign the ApplicationImpersonation role.

    Create a new PowerShell session with Office 365:

    $cred = Get-Credential
    $proxy = New-PSSessionOption –ProxyAccessType IEConfig
    $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic –AllowRedirection -SessionOption $proxy
    Import-PsSession $session

    Allow configuring Microsoft Office 365 settings:
     
    Enable-OrganizationCustomization

    Allow impersonation in Microsoft Office 365:
     
    New-ManagementRoleAssignment -Role ApplicationImpersonation -User rivasync@mycompany.com

    Finally, close the PowerShell session:
     
    Exit-pssession
    Remove-pssession $session

Using a more granular RBAC Management Scope

Full support using Windows Powershell to assign Exchange Impersonation using RBAC steps described previously in Configure Exchange Impersonation using Exchange Management Shell - Exchange 2013 and 2010. Some customers have reported difficulties with RBAC roles and Exchange Impersonation. Office 365 Enterprise also supports assigning Delegated Access using Powershell.

References:

  1. "Connect Windows Powershell to the Service": http://technet.microsoft.com/en-CA/library/jj984289%28v=exchg.150%29.aspx.
  2. "Allow someone else to manage your mail and calendar": http://www.utexas.edu/its/help/office365/2340.
  3. "Reference to available PowerShell Cmdlets in Exchange Online": http://technet.microsoft.com/en-us/library/jj200780%28v=exchg.150%29.aspx.
  4. "Built-in RBAC roles for Exchange Online": https://support.office.com/en-ie/article/Permissions-in-Office-365-da585eea-f576-4f55-a1e0-87090b6aaa9d.
  5. "WinRM client cannot process the request" error when you connect to Exchange Online through remote Windows PowerShell - https://support.microsoft.com/en-us/kb/2905339.
  6. Office 365 Technical Support: Call 1-866-865-9408.

WARNING: During recent work with a Riva client and Office 365 support, we have been warned against using group membership as the basis for a Management Scope's RecipientRestrictionFilter property with Exchange Online/Office 365, because the MemberOfGroup attribute relies on distinguished names and Microsoft does not currently guarantee that a cloud-hosted organization's distinguished name will remain static. (For example, the forest may change, as in our case.) Microsoft recommends using custom attributes instead.

How to prevent similar issues in the future

The Microsoft Office 365 support engineer advised:

"As we discussed together about the issue related to the break of EWS synchronization, here is a summary of what we talked about:
  • Customer has EWS synchronization set up in CRM.
  • EWS synchronization suddenly stopped last week due to impersonation suddenly stopping to be active for the users.

Set-ManagementScope had the recipient filter scope set to RecipientFilter: MemberOfGroup -eq 'CN=Riva Sync Users,OU=mycompany.com,OU=Microsoft Exchange Hosted Organizations,DC=eurprd07,DC=prod,DC=outlook,DC=com'

Customer resolved the issue by fixing the opath filter for the RecipientFilter to use the new forest where the user is located (DC=EURPR07A002)

In this specific case, the problem surfaced due to a recent change we had in the backend related to the user's organization and relocation in a different forest.

Speaking about this specific change we had in the backend, it was a change that was not supposed to cause any harm to customer infrastructures; we already consolidated the accounts in the forest for the majority of the users and we had no issue.

The problem for this specific case is that the customer is using a hard-coded value in the RecipientFilter, for an attribute that customers have no control over.

What I mean here is that for attributes that are authoritative or cannot be controlled (in this case, it is the distinguished name of the Organizational Unit where the customer configuration is located), we cannot guarantee not to change them again as per our configuration needs, as long as they are not causing issues to customers.

When working with custom code and customization, we don't suggest customers to use these attributes, but we have some specific ones that can be used for the purpose.

These attributes are the ones that are marked as custom attributes on the object, namely these:

PS C:\o365> Get-DistributionGroup | fl *cust*,name
CustomAttribute1 :
CustomAttribute10 :
CustomAttribute11 :
CustomAttribute12 :
CustomAttribute13 :
CustomAttribute14 :
CustomAttribute15 :
CustomAttribute2 :
CustomAttribute3 :
CustomAttribute4 :
CustomAttribute5 :
CustomAttribute6 :
CustomAttribute7 :
CustomAttribute8 :
CustomAttribute9 :
ExtensionCustomAttribute1 : {}
ExtensionCustomAttribute2 : {}
ExtensionCustomAttribute3 : {}
ExtensionCustomAttribute4 : {}
ExtensionCustomAttribute5 : {}
Name : dev
Get-mailbox user | Set-mailbox -CustomAttribute5 "EWS Impersonation"
Set the management scope to RecipientFilter: CustomAttribute5 -eq "EWS Impersonation"

Assign Delegate Full Access Permissions

There are two methods to assign these permissions:

Assign Delegate Full Access Permissions in the Exchange Admin Console. (Recommended.)

Follow this procedure in the Office 365 Exchange Admin Console to assign the Delegate Full Access permissions from the user being synced by Riva to the Exchange user mailbox for the service account used in the Riva EWS connection.

In the following example, Richard Mao is the target mailbox and Aldo Zanoni is the Riva Cloud EWS connection user.

To assign Delegate Access Full Access permissions:

  1. Log in to Office 365 as an Admin user. You should be working in a blue and white minimalist theme.

  2. On the menu bar, select Admin; and on the drop-down, select Exchange.

  3. In the left column navigation pane, select recipients.

  4. In the list of mailboxes, select the Riva target user mailbox that will grant delegate access, and select the pencil icon at the top of the mailbox list.

  5. In the User mailbox window, select mailbox delegation.

  6. In the Full Access section, above DISPLAY NAME, select +.

  7. In the Select Full Access window, select the mailbox to grant access to (the Riva connection user), select add ->,and select ok.

  8. In the User mailbox window, select Save.

  9. For each target user that the Riva will sync data for, repeat steps 4 to 8.

Use Powershell to Grant Delegate Full Access Permissions

Administrators can use Windows Powershell and connect to their Exchange Online subscription to issue PowerShell cmdlets to assign permissions.

Apply permissions to a single user mailbox

When security policies dictate that full access permissions can be granted only to specific mailboxes, use the Add-MailboxPermission cmdlet. This is an Exchange permission that is restricted to mailboxes.

  1. Connect to Exchange Online by using remote PowerShell. For instructions, go to this Microsoft webpage: Connect to Exchange Online using remote PowerShell.

  2. Enter the following command to execute the cmdlet to assign the permission and disable the AutoMapping feature.

    Add-MailboxPermission -Identity "targetmailbox" -User "Riva Connection User" -AccessRights FullAccess -AutoMapping $false

    Add-MailboxPermission -Identity “isample” -User “rivasvc@example.com” -AccessRights FullAccess -AutoMapping $false


    To confirm which permissions are assigned to a mailbox:
     
    Get-MailboxPermission -Identity "targetmailbox" | Format-List

    Get-MailboxPermission -Identity “isample” | Format-List
     

Apply permissions to all user mailboxes

When security policies dictate that full access permissions can be granted to all users, use the Get-Mailbox | Add-MailboxPermission cmdlet to bulk assign the permission to all target user mailboxes except the admin mailbox.

  1. Connect to Exchange Online by using remote PowerShell. For instructions, go to this Microsoft webpage: Connect to Exchange Online using remote PowerShell.

  2. Enter the following command to execute the cmdlet to assign the permission and disable the AutoMapping feature.
     

    Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User <user, role group or security group> -AccessRights fullaccess -InheritanceType all -AutoMapping $false

    Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User rivasvc@example.com -AccessRights fullaccess -InheritanceType all -AutoMapping $false
     

This article was:   Helpful | Not helpful Report an issue


Article ID: 1114
Last updated: 12 Mar, 2019
Revision: 8
Views: 11967
Comments: 0
Also read
item Migrate User Mailboxes in Batches to Office 365 by Using the Hybrid Migration Method

Also listed in
private Riva Cloud - CRM Sync -> Get Started -> Configure Your Email -> Prepare Your Email System -> Corporate Mode -> Prepare Exchange

Prev     Next
Impersonation Test Error: Riva Cannot Resolve Mailbox of Target...       IBM Notes (Lotus Notes)


Back to Top