This article will walk you through the use of Microsoft Cloud App Security (MCAS in the rest of the article) to implement data protections in the Microsoft Dynamics product range. This includes Dynamics 365 (the CRM product), Finance and Operations, Talent, Marketing etc.
In this walk through we will block copy and paste from the Dynamics 365 data when the browser is running on an untrusted network. We will also integrate Dynamics into the Office portal so that you have an easy click through to start the Dynamics apps.
Licencing
First all your Dynamics users need a range of licences. We will make that easy to implement with Azure AD Group Based Licencing.
#1 Create a group in Azure AD (or AD if syncing from on-premises). We will call this Dynamics 365 Users. Add some test and pilot users to start with – don’t add all your users at this point. Add all your users to this group when you want to whole of the route through MCAS + policies to take effect at the end of this walk through.
#2 Grant this group the required licences. For this feature you need your Dynamics licences, MCAS (which is a stand-alone purchase or part of Microsoft Enterprise Mobility + Security [EMS] E5). You need an Azure AD P1 licence as, but that is part of EMS so if you have MCAS stand-alone licence you need a seperate AAD P1 licence as well.
You grant licences to groups via the Azure AD Portal (https://portal.azure.com > Azure AD > Licences > All Products > Select one of the above licences > Licenced Groups > Assign the above created group to this licence.
Repeat for each other licence you need.
#3 Ensure that your Dynamics instance as found in Azure AD Enterprise Apps is visible to members of the above group. This step has prerequisites deep inside the configuration of Dynamics that we are not covering here. Once Dynamics is set up there should be an Enterprise App in the Azure AD Portal > Enterprise Apps for your Dynamics instance. The following screenshots shows what this might look like in your tenant:
In the settings of this Enterprise App ensure that “Visible to users” is enabled on the Properties pane and the above group is added on the “Users and groups” pane. This will result in the Dynamics instance appearing on the Office portal (https://office.com) and the Office 365 App launcher to the top left of all Office web apps/SharePoint Online sites. Intune can be used to push these icons to the Windows start menu as well (also optional for this walk through).
If you know the Dynamics URL then you don’t need to do the above, you can just type in the URL – this just means its easier for all users to launch Dynamics as there is a launcher icon under Office.
#4 is to create a Conditional Access rule so that all logins to the Dynamics apps are routed via MCAS. In the Azure AD Portal > Security > Conditional Access create a new policy that uses Session Controls to route your traffic for Dynamics via MCAS. You need to set the “Users and groups” to the above group, the “Cloud Apps” to “Common Data Service” (not the Dynamics instance that you may be able to select and not the Office 365 app) and “Session” to “Use Conditional Access App Control” and then select “Use custom policy…”. Set the Conditional Access policy to on and wait about 5 minutes before testing it.
For the “Use Conditional Access App Control” I suggest “Use custom policy…”. This means you can set a complex policy in MCAS rather than a simple Monitor or Block Downloads here.
#5 is testing time. Wait five minutes from creating your new Conditional Access policy and then in an In-Private browser login to https://office.com and click All Apps (bottom left) and then the icon under Business Apps.
You need to login in an In-Private (Incognito) browser because you need to do a new login to Dynamics. If you have already got an active login token you are not routed via Azure AD and so the Conditional Access rule does not fire until your token expires within the hour.
You should find that when you click the icon for the Business App you are routed to Dynamics but via an MCAS URL (ending mcas.ms). If you try going directly to your Dynamics URL you will be routed via MCAS – you cannot avoid MCAS because Conditional Access routes you that way:
#6 MCAS Configuration is next. Now that you have routed one user through MCAS for Dynamics, the Dynamics app is configured in MCAS. If you had logged into the MCAS admin portal before now you would not have seen Dynamics inside MCAS. Now you will see from https://portal.cloudappsecurity.com/ > Investigate > Connected Apps > Conditional Access App Control apps > Microsoft Dynamics and a report on connectivity, locations, users, activity log and alerts.
Once you are in MCAS you can start to create the policies for this app. This is done from MCAS Portal (https://portal.cloudappsecurity.com/) > Control > Policies > Conditional Access tab. Create a Session Policy for Browser based apps and an Access Policy for apps that use full applications. So for Dynamics that will be a Session Policy
You can base the policy from a template, such as “block download based on real-time content inspection” or create your own. Each policy is composed of a Filter, optionally Content Inspection, then Actions and finally Alerts. Lets look at all these for the template “block download based on real-time content inspection”:
These are all fairly obvious as to what they do and so a simple modification for testing you might do would be as follows:
- Change the Filter to Device | Tag | Does Not Equal | AAD Joined
- or remove that filter and set IP Address | Category | Does Not Equal | Corporate so that you can block/restrict activity from outside the office location.
- Inspection Method to look for keywords or DLP data types that are built in or you have added (fingerprints and trainable classifiers)
- Block
- Optionally generate alerts
The above is all based on the “block download” template. You could for example create a policy with filters like above, but based on the Block Activities session control type as shown:
- Add a filter for Activity Type | equals | Cut/Copy item to stop copying data out of Dynamics when outside the corporate network (the previous Corporate IPs ranges filter needs to remain as well as the new Activity Type filter
The Corporate IP ranges (your external IPs that users connect to Microsoft Cloud App Security from) need to be added to MCAS as well. This is done from the Data Enrichment menu top right > IP address ranges:
Even if you have added Trusted Networks in Azure AD, you need to add these values here as well if you want MCAS rules based on location. Also you cannot route your users to MCAS via a cloud proxy as you will then be connecting via the proxy / cloud filter companies shared public IPs and not your own dedicated IPs. So ensure *.mcas.ms bypasses your hosted proxy and you can reach it directly from your device.
#7 Test your MCAS policies is the second last step. Once you have your policies in place (and we have only given a few examples, but there are more like labeling [and maybe encrypting] documents with Sensitivity Labels, or actions like uploading data or chat that can be filtered.
For the below screenshot I created a policy that blocked cut/copy outside the corporate IP range. From home, logging into Dynamics and then copying a field I get the following:
#8 Roll out your controls to all users. This is as simple as adding your users to the group you made in Step #1 and waiting until their access token for Dynamics expires within the hour.
Photo by Dziana Hasanbekava from Pexels
Leave a Reply