Onboarding new users can be cumbersome when managing each user's access individually. Users must go through the process of accepting invites to the platform and authenticating with their individual accounts before they are granted access. Backstory Team Access enables administrators to set up their team seamlessly, with minimal effort required from the end user.
User Impersonation
Backstory connects directly to Microsoft Exchange On-Premises (also known as Exchange Server) to capture email and calendar activity information for users via User Impersonation.
Note: The Impersonation feature is available on MS Exchange Server 2007 and above. All Microsoft Office 365 plans that include Exchange Online only support the Impersonation feature through Exchange Web Services (EWS).
User Impersonation is ideal for providing access to a large number of mailboxes across an entire organization using a single service account. Backstory uses the designated service account to read mailboxes and calendars of all users set up and approved for impersonation.
Tip: Users may read more about Connecting Backstory and Microsoft 365 in Backstory and Exchange Impersonation vs Delegate Access in Microsoft.
Security Considerations
Impersonation enables the service account to assume the identity of a specific user account. Please consider the following facts and recommendations:
Only accounts that have been granted the Application Impersonation role by an Exchange Server administrator can use Impersonation.
The "Full Access" permission grants read-only access to users covered by the management scope.
Create a management scope that limits Impersonation to a specified group of users, such as sales and marketing teams. If you do not create a management scope, the Application Impersonation role is granted to all accounts in an organization by default.
Prerequisites for Connecting Backstory to Exchange On-Premises
Backstory makes API calls to on-premise Exchange servers from specific cloud-based IP addresses. Ensure that your network equipment (E.g., Firewall, Security Gateway, etc.) is not blocking incoming connections to EWS from the following IP addresses:
Production: 35.174.76.124/32, 34.206.190.238/32, 34.236.123.133/32 (subject to change)
Backstory also leverages the EWS API to pull data from Exchange servers, so remote access for the EWS API should be enabled. To enable EWS API for all applications, use this cmdlet in the Exchange Management Shell console:
Set-OrganizationConfig –EwsApplicationAccessPolicy EnforceBlockList
Read more from Microsoft: Control access to EWS in Exchange
Backstory requires certain access and credentials for Exchange servers:
Administrative credentials for the machine running your Exchange Server that has the Client Access server role installed.
Credentials of a user who is a member of the Organization Management security group and has proper permissions to assign roles in Exchange.
Access to the Exchange Management Shell to run the required cmdlets for setting up Impersonation.
Configuring Backstory <> Exchange On-Premises
Follow the steps below to set up Impersonation for the service user to manage access to users’ accounts and allow Backstory to read mailboxes and calendars.
Service Account
Create a service account using the New ADServiceAccount cmdlet.
If you already have a service account ready for use, proceed to the next step.
Security Group
Use the Active Directory security group to manage access to mailboxes for easy user management after the initial setup.
To associate a management scope with a specific security group, use this cmdlet (please specify your domain in the DC parameter):
New-ADGroup -Name Peopleai_Group -GroupCategory Security -GroupScope Universal -Path "CN=users,DC=mydomain,DC=com"
Be sure to use the Universal scope for the security group, as the Global scope will not work with Exchange.
You can also assign users to the security group by name using this cmdlet:
Add-ADGroupMember -Identity "CN=Peopleai_Group,DC=mydomain,DC=com" -Member "CN=Some User,DC=mydomain,DC=com"
Limited Scope
Management scope limits the targeted recipients based on given criteria, and is required for Impersonation configuration. We recommend using a security group within the limited scope for easier management.
Create a limited scope of users for the integration using the New-ManagementScope cmdlet.
This example cmdlet creates a scope by filtering users based on their Title. If a user’s title contains the word “sales”, then add the user to the scope:
New-ManagementScope -Name Peopleai_Scope -RecipientRestrictionFilter {MemberofGroup -eq "CN=Peopleai_Group,DC=mydomain,DC=com"}
Grant Impersonation Permission
Assign the Impersonation permission to the service account for the newly created scope using the New-ManagementRoleAssignment cmdlet.
This cmdlet assigns Impersonation permission to your newly created “Sales” management scope (from the previous example):
New-ManagementRoleAssignment –Name Peopleai_Impersonation" –Role ApplicationImpersonation –User peopleai@yourdomain.com –CustomRecipientWriteScope Peopleai_Scope
Throttling Policies
Microsoft Exchange Server uses client throttling policies to manage the performance of your Exchange organization. We recommend creating a custom throttling policy to ensure the application adheres to its dedicated limits without interfering with other applications or users.
There are three types of throttling policies that Microsoft supports: user-level, organization-level, and service account policy. The service account policy is not supported for Application Impersonation. We highly recommend creating an organizational-level policy, as handling user-level policies is time-consuming and error-prone.
To create a new throttling policy, use this cmdlet:
New-ThrottlingPolicy -Name Peopleai_Policy_Updated -EWSMaxConcurrency 100 -EWSMaxBurst 600000 -EWSRechargeRate 900000 -EWSCutoffBalance 3000000 -ThrottlingPolicyScope Organization
You can find more information on throttling policies supported by Exchange Server here.
Recommendation for Exchange Server 2013+:
EWSMaxConcurrency: 100
EWSMaxSubscriptions: Unlimited
EWSMaxBurst: 600000
EwsRechargeRate: 900000
EwsCutoffBalance: 3000000
ThrottlingPolicyScope: Organization
Connecting Backstory <> Exchange On-Premises
Your onboarding team will work with you to authorize Backstory using the service account. After integrating, we will add users and begin ingesting their email and calendar data.
Troubleshooting Tips to Consider
Restart the Exchange Server or install the latest server updates. See here for the latest updates from Microsoft: Exchange Server Updates: Build numbers and release dates
Troubleshoot connectivity issues: https://testconnectivity.microsoft.com/
Troubleshoot performance issues: Troubleshooting Microsoft Exchange Server Performance
Testing Impersonation
To test the newly created impersonation account, run this cmdlet in the Exchange Management Shell console.
Need some assistance? Reach out to our Technical Success team at support@backstory.ai!