Using Exchange Impersonation

Exchange Impersonation is a mechanism that allows a single Windows Active Directory account to act on behalf of other users on a Microsoft Exchange mailbox, as if they were performing the action themselves.

To implement Exchange Impersonation, the System Administrator:

1. Adds the Active Directory Account for the Service Account. See Creating the Service Account.
2. Applies permissions. See Applying Permissions.

Note: Be aware that Exchange Impersonation works only via the Exchange Web Services API. This means that although the account is able to act on behalf of another user, it only works if it is done as an Exchange Web Service call; it does not work through Outlook, Outlook Web Access, or any other Exchange client.

Active Directory Accounts and Mailbox Accounts

The user has two accounts:

• The Active Directory account that gives the user permission to log on to the domain. This is referred to as the user's Active Directory Account (or AD Account);
• The Exchange Server Mailbox that is used to pick up email and change the calendar. This is referred to as the user's mailbox account.

The AD account has to have access rights to a corresponding mailbox account in order to receive mail, etc., but an AD account can exist without a corresponding mailbox account.

Creating the Service Account

The System Administrator creates an account that is referred to as the service account because it is used by the service to act on behalf of the user accounts. For example, you could name this account ewsproxy to help identify it as the service account. However, any valid user account can be used.

The System Administrator gives this service account Exchange Impersonation privileges for users. The service account will be assigned some permissions on both the service and the user accounts that allow the service account to act on behalf of the user accounts. The service account can then perform any action that users can perform on their mailboxes.

The service account does not need to have a mailbox account. Instead, it has only an Active Directory account.

Even if you have large, complex networks with multiple domains, one impersonation service account should be sufficient if the domains are configured on the same Exchange deployment. The application supports one impersonation account which needs access to the mailboxes of users of the Reservations application. They don't have to be on the same domain, but they must be part of the same Exchange 'forest.‘ The Exchange Client Access Server will route requests to the correct mailbox server containing the user's mailbox.

Adding the Active Directory Account for the Service Account

Adding the Active Directory account for the Service Account is equivalent to simply adding a normal user in the domain.

The steps are:

1. The System Administrator logs on to the Active Directory server and adds an account with the user name of the Service Account.
2. On the next page of the wizard, you are prompted for the password for this account. It's important to make this a strong password, and it's also recommended to set the 'Password never expires' flag. As this is intended to be a service account, changing the password will affect the service as well as the account.

Applying Permissions

Exchange Server 2010 has improved the application of permissions over the design used by Exchange Server 2007.

Exchange Server 2007: makes use of Access Control Lists (ACL) to apply permissions. There are only two rights; one that authorizes the Service Account access to Exchange Impersonation rights on the Client Access Server (CAS), and the other that is applied to either an Active Directory account, or an entire mailbox database. This is somewhat limited because this is either done on an account-by-account basis, or done on an entire mailbox database.

Exchange Server 2010: enables much finer-grained control of the application of permissions because it makes use of Role-Based Access Control (RBAC) to apply the permissions. Instead of applying the tokens to an account or a mailbox database, the System Administrator can define a scope to which the permission applies. This means that the administrator can get all the users in a group, for example, and set the permission for that group as a scope.

Applying Exchange Impersonation Permissions on Exchange Server 2007

For Exchange 2007, you can configure impersonation for an entire mailbox store. A mailbox store is like a database on the Exchange server that contains the mailboxes of all users on the server. In large organizations, user mailboxes can be divided across different Exchange servers and thus mailbox stores.

Exchange 2007 requires that the System Administrator applies the following rights to get Exchange Impersonation working:

• ms-Exch-EPI-Impersonation – the Manager sets up a service account in active directory and then assigns it the EPI-Impersonation right to impersonate users on an Exchange server. This right is applied to the Client Access Server and grants the Service Account permission to function as an Exchange Impersonation account on that CAS.
• ms-Exch-EPI-May-Impersonate – the Manager needs to specify which users it may impersonate by assigning the EPI-May-Impersonate rights. The Manager needs to add the EPI-May-Impersonate for each user of the reservations application, or to allow impersonation for the entire mailbox store. This right is applied on either a user-by-user basis for each of the users that require impersonation to be enabled, or it can be applied on a mailbox database.

With the release of Exchange Server 2007, Microsoft released the Exchange Management Shell (or Powershell) that allows the System Administrator to perform most administrative functions from the command line. This is described in the following procedure.

To apply Exchange permissions:

1. Set the Impersonation permission on your Client Access Server:
   1. Log on to the Exchange Server machine, and launch the Exchange Management Shell from the Microsoft Exchange Server 2007 program group in the Start menu.
   2. At the command line, type the following command:

      Add-ADPermission -Identity (Get-ExchangeServer -Identity <exchange-server>).DistinguishedName
      
      -User (Get-User -Identity "EWS Proxy").Identity
      
      -extendedRight ms-Exch-EPI-Impersonation

      Note: The identity of the Client Access Server is the name of the machine that hosts it, and the identity of the user is the full name of the user. The user's full name can be retrieved typing Get-User at the command line. This will return a list of all the known user names.

2. Set permissions on each user to enable Exchange Impersonation by running the Add-ADPermission commandlet from the command line. (This time you are running this command to add the user permissions). Below is the command that is used to set these user permissions.

   Add-ADPermission -Identity (Get-User -Identity <user name>).DistinguishedName
   
   -User (Get-User -Identity "EWS Proxy").Identity
   
   -extendedRight ms-Exch-EPI-May-Impersonate

Note: Although the System Administrator can set the ms-Exch-EPI-May-Impersonate permission on a mailbox store basis, it is not recommended doing that unless the system has segregated users in a way that makes sense to do so.

Applying Exchange Impersonation Permissions on Exchange Server 2010

Setting up Exchange Impersonation for Exchange Server 2010 is a simpler process than it is for Exchange Server 2007. The Role-Based Access Control mechanism enables you as the System Administrator to define groups of users and assign those groups of users the ApplicationImpersonation role. Once that is done, any new users that are added to the group are automatically assigned the ApplicationImpersonation permission.

To set up permissions on Exchange Server 2010:

• Create the service account. Reservations need one service account with the ApplicationImpersonation role.

• Define the users for this service account. The System Administrator can define a group of users that this service account can impersonate based on Active Directory properties. This ensures the service account can impersonate new users in that group without additional configuration.
• Define a management scope

  The next step is to assign the ApplicationImpersonation role to a ManagementScope.

  A management scope is a logical group of users that are defined by a common set of criteria. It is not necessarily an Active Directory Security Group. The System Administrator can define the scope to consist of users who meet a certain criteria, such as having a common manager.

  The System Administrator defines a management scope by using the New-ManagementScope commandlet. The RecipientRestrictionFilter parameter enables the System Administrator to define the criteria that select a list of users. The following command creates a management scope that will include only members of that group.

  New-ManagementScope -Name:"<group name>"
  -RecipientRestrictionFilter {memberofgroup -eq
  "cn=Sales,cn=Users,DC=procosgroup,DC=internal,DC=com"}

  The string at the end of the command line is a distinguished name string from the Active Directory that represents the security group. There are a number of different filters that can be applied to create a management scope. If the System Administrator adds or removes a user to or from the security group, the scope defined here will ensure that the permissions for the user are affected accordingly.

• Assign Roles

  Once the management scope exists, one or more management roles can be applied to the management scope. In this case, the System Administrator will assign the ApplicationImpersonation role for the service account user (such as ewsproxy) to the management scope that the System Administrator just created.

  New-ManagementRoleAssignment -Name:"<role name>"
  -Role:ApplicationImpersonation
  -User:"ewsproxy@procosgroup.com"
  -CustomRecipientWriteScope:"<group name>"

  So, in the command line above, the <role name> refers to the name of the management role assignment that is being created, while the <group name> refers to the name of the management scope that was created in the Defining a management scope section.