As frequent readers of this blog may know, I made several Exchange-related scripts available to the community. Some of these scripts make use of what is called Exchange Web Services (EWS). I receive lots of questions via e-mail and through the comments about configuring impersonation or permission-related issues when running those scripts, which support delegated access as well as impersonation, against mailboxes. This blog shows how can configure delegation, why you should use impersonation, and how to configure impersonation on Exchange 2007 up to Exchange 2013 and Exchange Online in Office 365.
Introduction
EWS provides functionality to allow client applications, such as Outlook or OWA apps, tools, or in my case scripts, to communicate with Exchange server. Even Exchange itself makes uses of EWS when performing Free/Busy lookups by the Availability services for example. EWS was introduced in Exchange Server 2007 back in December 2006, which now seems decades ago.
Some of these EWS scripts or tools access or even manipulate mailbox contents. In the MAPI era, in order for you to access a mailbox thatâs not yours, you required delegated full access permissions. These permissions could be granted at the mailbox, mailbox database or mailbox server level. The latter would grant you access to all mailboxes hosted in that mailbox database. For example, to grant an account Archibald full access permission on the mailbox of Nestor, you would typically use something like:
Add-MailboxPermission âIdentity Nestor âUser Archibald âAccessRights FullAccess âInheritanceType All
Note: Specifying InheritanceType is sometimes overlooked. Not specifying it only configures an Access Control Entry (ACE) on the top level folder (InheritanceType None), resulting in symptoms like scripts not processing subfolders for example.
EWS enables you to use another access method besides delegation, which is impersonation. Impersonation, as the many online available dictionaries may tell to you, is âan act of pretending to be another person for the purpose of entertainment or fraudâ or something along those lines. In the Exchange world, this means you can have an account which has the permission to pretend to be the owner of the mailbox, including being subject to the same effective permissions. So, if for some reason the owner only has Read permission on a certain folder, so will the impersonator. Typical use cases for impersonation are for example applications for archiving, reporting or migration, but also scheduled scripts that need to process mailboxes could be one.
Before we dive into the configuration itself, first some of the reasons why you should should prefer Impersonation over delegated access:
- No mailbox needed for the account requesting access.
- Throttling benefits, since the operation is subject to the throttling policy settings configured on the mailbox accessed, not the throttling policy configured on the mailbox requesting access. To bypass these delegate limits, one had to configure and assign a separate throttling policy with no limits for the account. Of course, a bad behaving application could then run without boundaries from a resource perspective, something throttling policies try to limit.
- In Exchange 2010 and up, impersonation leverages Role Based Access Control, which is better manageable than a collection of distributed ACEs.
- Actions performed by the impersonator are on behalf of the impersonated. This may complicate auditing, as logging will come up with actions performed by the impersonated user, not the impersonator.
Note that where âuserâ is specified below with regards to granting permissions, one could also specify a security group as well unless mentioned otherwise.
Impersonation on Exchange 2007
On Exchange 2007, you configure impersonation by granting the following two permissions:
- The ms-Exch-EPI-Impersonation permission grants the impersonator the right to submit impersonation calls. It is configured on Client Access Servers. This does not grant the impersonation right, just the right the make the call through a CAS server.
- The ms-Exch-EPI-May-Impersonate when granted, allows the impersonator to impersonate selected accounts.
To configure these permissions in your Exchange 2007 environment, use:
Get-ClientAccessServer | Add-AdPermission âUser svcExchangeScripts âExtendedRights ms-Exch-EPI-Impersonation
Then, we can configure impersonation permission on the mailbox level:
Get-Mailbox Tintin| Add-ADPermission âUser svcExchangeScripts âExtendedRights ms-Exch-EPI-May-Impersonate
on the database level:
Get-MailboxDatabase MailboxDB1 | Add-ADPermission âUser svcExchangeScripts âExtendedRights ms-Exch-EPI-May-Impersonate
or mailbox server level:
Get-MailboxServer MailboxServer1 | Add-ADPermission âUser svcExchangeScripts âExtendedRights ms-Exch-EPI-May-Impersonate
Be advised that members of the various built-in Admin groups are by default explicitly denied impersonation permissions on the server and database level, and deny overrules allow. You will notice this when querying impersonation configuration settings, for example on the database level (in the screenshot example, olrik was granted impersonation permissions):
Get-MailboxDatabase | Get-AdPermission | Where { $_.ExtendedRights âlike âms-Exch-EPI-Impersonationâ} | Format-Table Identity, User, Deny, IsInherited, ExtendedRights âAutoSize
Note that permissions assigned on the mailbox may not immediately be reflected as you are administering them in Active Directory. Changes in Active Directory are subject to AD replication, and the Exchange Information Store caches information for up to 2 hours, so worst case it may take up to 2 hours and 15 minutes for new permission settings to be re-read from Active Directory.
Impersonation on Exchange 2010 and 2013
Exchange 2010 introduced Role Based Access Control, better known by its acronym RBAC. For a quick introduction to RBAC, see one of my earlier blogs here. There is a management role associated with impersonation, which is ApplicationImpersonation.
To enable a user impersonation rights, create a new assignment for ApplicationImpersonation and assign it to the user:
New-ManagementRoleAssignment âName 'AIsvcExchangeScripts' âRole ApplicationImpersonation âUser svcExchangeScripts
Note that if we want to assign these permissions to a security group, we need to use the SecurityGroup parameter instead of User, specifying the group name.
Now be careful, when used like this you will have granted that user or group permission to impersonate all users in your Exchange organization. Here is where RBAC comes into play, or more specific the RBAC feature named management role scopes. With write scopes for example, you can limit the scope of where you can make changes in Active Directory. For more information on management role scopes, see here.
Let us assume we want to limit the scope to a distribution group named âAll Employeesâ, using New-ManagementScope in combination with RecipientRestrictionFilter. Note that when specifying MemberOfGroup in the filter, you need to use the distinguishedName of the group:
New-ManagementScope âName 'Employee Mailboxes' âRecipientRestrictionFilter { MemberOfGroup âeq 'CN=All Employees,OU=Distribution Groups,OU=NL,DC=contoso,DC=com'}
We can then apply this scope to the assignment created earlier:
Set-ManagementRoleAssignment âIdentity 'AIsvcExchangeScripts' âCustomWriteScope 'Employee Mailboxes'
Be advised that in a multi-forest environment, impersonation doesn’t work when you assign permissions to cross-forest accounts. You either need to assign impersonation permissions to an account residing in the same forest as Exchange, or create a linked role group.
Impersonation on Exchange Online
Impersonation is available in most Office 365 plans, but currently not in the small business plans. To configure Impersonation in Exchange Online we need to connect anyway, so weâll first open a remote PowerShell session to Exchange Online:
$EXO= New-PsSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection -Authentication Basic
Import-PsSession $EXO
Provide tenant administrator credentials when prompted. You can then see if you have the ApplicationImpersonation role at your disposal using:
Get-ManagementRole âIdentity ApplicationImpersonation
If nothing is returned, you may need to resort to delegate access permissions.
Configuring impersonation is identical to configuring it in Exchange 2013. Nonetheless, some people may be more comfortable using the Exchange Admin Center. If so:
- Open up Exchange Admin Center.
- Navigate to Permissions > Admin Roles
- Now we canât directly assign a management role through EAC, so assume weâll create a role group for our application account by clicking New (+).
- Enter a name for your role group, e.g. ExchangeMaintenanceScripts.
- Add the role ApplicationImpersonation.
- Add the accounts which need Impersonation permissions, e.g. svcExchangeScript.
- Optionally, you can also select a Write Scope, which you need to create upfront through Exchange Management Shell.
- In Exchange on-premises, instead of a Write Scope you will have the option to select a a specific OU instead (scope filter RecipientRoot parameter) .
- When done, Save.
One word of caution: scopes are not automatically updated when objects referenced are relocated or change names. Now, for your own environment you may have this under control through some form of change management process. For Exchange Online however, your tenant might get relocated without notice. Therefor, should impersonation fail, verify any management scopes you may have defined for distinguishedName references, and check if they require updating, e.g.
Set-ManagementScope -Name 'All Employees' -RecipientRestrictionFilter { MemberOfGroup -eq 'CN=All Employees,OU=contoso.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR05A001,DC=prod,DC=outlook,DC=com'}
Final words
Note that many EWS-based scripts or tools do not natively support EWS but make use of the Exchange Web Services Managed API. This installable package consists of support files (e.g. DLLâs) which provide EWS functions to your PowerShell environment. You can download the current version of EWS Managed API here (2.2). You can read more on developing with EWS Managed API here, or you can have a peek at the source of code of one of my EWS scripts or the ones published by Exchange MVP-fellow Glen Scalesâ here.
With the speed of development in Office 365, it is sometimes hard to track which changes have been made to your tenant. Of course, there is the roadmap and message board which you can use to keep up to date, but those are in general high level descriptions. Sometimes you may want to see what are the changes at the cmdlet level in your tenant, between tenants, or Azure Active Directory module. And there is also the occasional gem in the form of a yet undocumented cmdlet or parameter which could hint at upcoming features.
EighTwOne (821) 