- Microsoft Graph: A single (PowerShell) API for Microsoft’s cloud services - Tue, Aug 23 2022
- Exchange impersonation: Grant permissions to service accounts - Mon, Aug 8 2022
- Send Microsoft Teams meeting invitations in multiple languages - Thu, Jul 21 2022
An example of applications that require permissions to Exchange resources is dispatching used to plan the deployment and availability of personnel. The software in question should be able to write directly to the user's calendar for appointment management. Mail archiving solutions also have similar requirements.
Options for granting permissions
Basically, Exchange provides three options to grant users permissions to other users' mailboxes:
- Folder permissions, when you want to grant a user access to a folder, but you don't want that user to be able to "send on behalf of" another user.
- Delegation, when you want a user to perform work on behalf of another user (for example, an executive assistant handling the manager's calendar). This can also be done centrally using PowerShell.
- Impersonation in a service application that needs to access multiple mailboxes and act as the owner of the mailbox.
For our requirement, an impersonation role can be configured centrally on the Exchange Server. This works on both Exchange on-prem and Exchange Online.
For security reasons, the service account will not be authorized to access the entire organization. This would automatically affect critical positions, such as a CxO. Instead, you can use filters to adjust identity roles accordingly.
Use impersonation roles
Impersonation can be configured via Exchange PowerShell. Using the cmdlet
Get-ManagementRoleAssignment -Role:ApplicationImpersonation
you can first check to see if there are already any impersonation roles.
Display currently configured impersonation roles
To create a new impersonation role, use the following cmdlet:
New-ManagementRoleAssignment -Role:ApplicationImpersonation ` -User: ServiceUser@rolandeich.onmicrosoft.com
Creating a new impersonation role using PowerShell
Now you can further restrict the permissions of the service user with the RecipientTypeDetails parameter, in this example, to rooms:
New-ManagementScope -Name "ApplicationImpersonation-ServiceUser" `
-RecipientRestrictionFilter {RecipientTypeDetails -eq "RoomMailbox"}
Restrict service account permissions to room mailboxes
Further filtering would also be possible for all user mailboxes, for example:
RecipientRestrictionFilter "RecipientType -eq 'UserMailbox'"
The following example shows the restriction of permissions to the members of a group:
New-ManagementScope "ApplicationImpersonation-ServiceUser" ` -RecipientRestrictionFilter "MemberOfGroup -eq '$($GroupDistinguishedName)'"
More detailed information on the filtering options can be found on Microsoft Docs .
However, if you are planning to migrate to Exchange Online and have created on-prem filters at the organization level (OU) or directly for servers, they will not work in Exchange Online because there are no OUs there.
Basically, the configuration of an impersonation role is now complete. In practice, however, it often happens that different service users need to access calendars. In this case, it is more efficient to give permissions to a group that then contains the service users:
New-ManagementRoleAssignment -Name GroupImpersonation ` -Role ApplicationImpersonation -User ServiceUser@rolandeich.onmicrosoft.com ` -CustomRecipientWriteScope "ApplicationImpersonation-ServiceUser"
Grant permissions to service users via group membership
All users who are members of the GroupImpersonation group are thus allowed to access the users contained in ManagementScope.
Finally, if you want to check the filters set above, you can do so by using
Subscribe to 4sysops newsletter!
Get-ManagementScope
and
Get-ManagementRoleAssignment
