This guide is an overview of the security implications of Eploy’s Microsoft Teams and Office365 calendar integrations, including the Eploy Application, the Microsoft services (APIs/Office 365) and the Application Access policy.

Once configured, the Eploy application communicates with the MS APIs, but the Application Access policy acts as a firewall, preventing certain permissions from being accessible, regardless of the application settings.

The Eploy Application

Eploy uses an enterprise application to communicate with Microsoft. For ease, we have a single application used for both Per User and Delegate communication with Microsoft.

Integrating the application Per User will require all users who wish to use the integration to consent, whilst integrating the application as a Delegate will give the integration to all users on a Microsoft Organisation, however an admin must consent to this.

Note - Because we use a single enterprise application for both Per User and Delegate access to a system, when setting up "Delegate" access, Microsoft will ask the admin to consent to the Per User access rules too, even though they are not used by the Eploy Application.

Access Per User

On an Eploy calendar page, if Corporate Calendar settings are not set up, single users can link their corporate calendar to Microsoft. When performing the linking process, the user is asked to consent for the Eploy Application to do things on their behalf. Each permission is detailed below:

• Sign in as you
  • This is legalese & means we can act on the user's behalf without the user actively being logged in.
• Maintain access to data you have given it access to
  • This is legalese & means we can store information about the user's account without the user actively being logged in.
• Read your calendars
  • Read the user's calendar details.
• Read your chat messages
  • Used to get meeting recording - We do not store the files, only the links
• Read and create your online meetings
  • Read Microsoft calendars on behalf of a user .
• Read all users' basic profiles
  • See basic information about other people in the organisation.
• View your email address
  • View the linked user's Email Address (we already have this).

Delegate Access

In the Security Settings Admin , when linking the Eploy Application via the Corporate Calendar settings, the admin is presented with the following permissions form.

Because we use the same Eploy Application for both Delegate and Per User access, we cannot do anything outside of these permissions, and this is why we have each below:

• Read User Chat Messages
  • This is the Per User permission Read your chat messages - we do not use this in Delegate Access.
• Maintain access to data you have given it access to
  • This is legalese & means we can do things without the user being logged in
• Read all users' basic profiles
  • See basic information about other people in the organisation.
• Read user calendars
  • This is the Per User permission Read your calendars - we do not use this in Delegate Access.
• Read and create user's online meetings
  • This is the Per User permission Read and create your online meetings - we do not use this in Delegate Access
• Read all users' full profiles
  • We use this to match Eploy Usernames to "User Principle Names" in the Microsoft Organisation
• Read all chat messages
  • Used to get meeting recording - We do not store the files, only the links
• Read calendars in all mailboxes
  • Read all Calendars in the Organisation - these never stored and only displayed if we have an Eploy username matching a "User Principle Names" in the Microsoft Organisation
• Read and create online meetings
  • Create Teams meetings on behalf of a user

Access to Teams APIs

Despite the above integration requesting specific permissions, Microsoft are enforcing that an Access Application Policy must be granted to a third party to communicate with the Teams APIs.

Without this Access Application Policy in place, the Teams functionality will not work, but the Calendar integration will.

Hint - You can learn more on the requirement for the Access Application Policy here, from Microsoft directly.

This acts like a firewall, in that no matter what the Eploy App requests, it will filter the scope of the API requests.

To begin, open Microsoft Powershell and run the following commands:

• Update to Windows PowerShell 5.1. If you're on Windows 10 version 1607 or higher, you will already have PowerShell 5.1 installed.
• Install .NET Framework 4.7.2 or later.
• Install-Module -Name PowerShellGet
• Import-Module MicrosoftTeams
• Connect-MicrosoftTeams

To create an "Access Application Policy", the following Powershell command is an example of what to run:

• New-CSApplicationAccessPolicy -Identity EployTeamsPolicy -AppIds 7d41920f-a928-45ee-b6eb-252e77a4f654 -Description "Example Teams Policy for Eploy"
  • The New-CSApplicationAccessPolicy is the name of the powershell script to run
  • The Identity is a unique name for this policy (EployTeamsPolicy in the example)
  • The AppIds is a list of third party applications that fall under this policy.
  • 7d41920f-a928-45ee-b6eb-252e77a4f654 is the code for the Eploy Application, and no other providers are included in the above. 
  • The Description is text to explain the point of the policy

Once an Access Application Policy has been created, it must be assigned to be considered active.

When assigning an Access Application Policy, the admin can choose between setting it as active for individual users, or all users within an organisation as the default.

Microsoft enforce that only one "Access Application Policy" can be set per user.  In order to grant an application policy to a single user, the following command should be run:

• Grant-CsApplicationAccessPolicy -PolicyName EployTeamsPolicy -Identity "7d41920f-a928-45ee-b6eb-252e77a4f654"
  • The Grant-CsApplicationAccessPolicy is the name of the powershell script to run
  • The PolicyName is the Identity of the policy we just created.
  • The Identity is the objectID of the user you wish to assign the policy to.

As our customers often have many users that they wish to assign the "Application Access Policy" to, we recommend assigning it to as the default for all users within an organisation.

Microsoft do not offer a way to assign an "Application Access Policy" to a group of users. 

To do this, the following command will be run:

• Grant-CsApplicationAccessPolicy -PolicyName EployTeamsPolicy -Global
  • The Grant-CsApplicationAccessPolicy is the name of the powershell script to run
  • The PolicyName is the Identity of the policy we just created.
  • The Global represents that the policy will be added to all users by default.

Once this has been set up, it will mean that Eploy only accesses information at the granularity needed for the use case required and you can control exactly what is exposed.

Backout Method

In order to back out the above, first you'll need to check the current access policies using the following command:

Get-CsApplicationAccessPolicy

Above you can see that the policy is called “EployTeamsPolicy”. So follow that up with this command:

Remove-CsApplicationAccessPolicy -Identity EployTeamsPolicy

Then the policy will be removed.