Application impersonation and EWS with 3rd party applications in Office 365

Application impersonation and EWS with 3rd party applications in Office 365

I recently came across an interesting scenario where an application used Exchange Web Services (EWS) and an Office 365 account to access every user’s calendar in an organization. In this specific scenario, I had a hosted application outside of our organization which needed to add and remove events from any user’s calendar in Office 365. This blog post will give you details on one method for enabling this functionality using the tools available in the Office 365 Portal which are a bit different than in an on premise Exchange environment.

In Exchange environments, a service application is (usually) a background job built into an existing application that correlates data between the application and the Exchange store. Service applications typically do not have a user interface and use impersonation for authentication and access. Creating a service account to impersonate users is common in EWS service applications because you can grant a single account permission to impersonate a set of users and perform mailbox operations for those accounts.

Since I had a service application and Office 365, I needed to create a new service account in the Office 365 environment in order to delegate permission and access. Based on what the application needed to access within Exchange the service account needed to meet the following requirements in order to be successful:

  • Allow the service account to access EWS such as the XML data and services WSDL
  • Allow meetings to be published directly to a user’s calendar (or else the meeting will be owned by the service account)
  • Allow limited access to all calendars
    • Publishing Author permissions
    • No access to resource or shared calendars
    • Only access to calendar data

What is Application Impersonation?

Application Impersonation is a built-in role in the Role Based Access Control (RBAC) permissions model in Microsoft Exchange Server 2013 and Office 365. The members of the group can access the contents of a user’s mailbox and act on behalf of that user, even if the user’s account is disabled. Since the created service account will have elevated permissions to every mailbox, ensuring the service account is locked down with a secure password and minimal access is crucial.

Application impersonation is typically required because granting access to every calendar just isn’t enough, especially if the service is outside of your organization. The application needs access to EWS and possibly other metadata behind the scenes like application XML and WSDL.

URL for Exchange EWS:

https://outlook.office365.com/ews/exchange.asmx

To accomplish all of this in my scenario, I had to do the following:

1. Create a user in Office 365 with an Exchange Online License. (An Exchange license is required in order to access calendars.) I called this user Service_Delegate@domain.com

2. Grant the user Publishing Author permissions to all of the calendars in the environment.

2.1 This is performed via PowerShell and requires .NET Framework 3.51 installed.

3. There are some prerequisites required for the scripting portion of this process. (If you have all of the software prerequisites and are ready to connect to Office 365 skip this step)

3.1 Install Microsoft Online Services Sign-in Assistant fromhere: http://go.microsoft.com/fwlink/?LinkId=286152

3.2 Install the appropriate cmdlets using the links below:
              32bit: http://go.microsoft.com/fwlink/p/?linkid=236298
              64bit: http://go.microsoft.com/fwlink/p/?linkid=236297

4. Open PowerShell as an administrator and connect to Office 365 using a Global Admin account:

Import-Module MSOnline

$UserCredentials = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredentials -Authentication Basic -AllowRedirection

Import-PSSession $Session

5. Grant delegate account Publishing Author to all users in the organization. You can review the AccessRights parameters here: https://technet.microsoft.com/en-us/library/dd298062(v=exchg.150).aspx. Also notice the -recipienttypedetails filter only applies to user mailboxes, this filters out, resource and shared mailboxes.

(Get-Mailbox -recipienttypedetails usermailbox) | Foreach-Object {Add-MailboxFolderPermission $_”:\Calendar” -User Service_Delegate@domain.com -AccessRights PublishingEditor}

6. At this point we are done using PowerShell so I recommend removing the PSSession that we used to make changes. Removing the session stops any commands that are running in the PSSession and releases the resources that the PSSession was using. Since we are connected to Office 365 and obviously not on the Exchange server, this command closes the connection between the local computer and Office 365.

Remove-PSSession $Session

7. Now that the delegate has rights to edit calendars in the organization we need to create a new group in Exchange for any service accounts that need the ApplicationImpersonation role. Begin by logging in to the Office 365 Exchange Admin center as a Global Admin: https://outlook.office365.com/ecp/

7.1 Click Permissions in the left column
7.2 Make sure that Admin roles is selected across the top
7.3 Click the + across the top to create a new group and call it “Application Impersonation”
7.4 Enter a description (Optional but recommended)
7.5 Leave write scope as default
7.6 Click the + to add a new role and select ApplicationImpersonation
       7.7 Click the + to add the Service_Delegate account created in Step 1

Now that the users have been added to the group with ApplicationIntegration roles, the members of this group can impersonate users in the organization and access EWS metadata like WSDL and XML data.

To verify everything is working correctly go to https://outlook.office365.com/ews/exchange.asmx and login with the Service_Delegate account. You should see a page with the following information.

If everything is configured correctly then your service delegate account should be able to make the necessary changes to the Office 365 environment. Of course, you will also want to test the complete workflow from the service application before communicating to users that the functionality is available and “working”. This post should provide you with all the steps to get this type of functionality working an Office 365 Exchange environment utilizing the tools available to Exchange admins which are a bit different than the on premise implementations.

2 Comments

  • Adam Steinberg July 12, 2016 2:25 pm

    I’m looking for a 3rd party app that does calendar sync in the manner you describe above. Can you tell me which service you were using?

    • Tom Gould July 13, 2016 10:21 am

      The application that I was dealing with in this instance was actually a travel management vendor. When travel was booked trough their management site, the vendor would publish the travel details directly to their Outlook calendar.

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons