I had a session about protecting all your cloud applications with Azure AD and Cloud App Security from unmanaged devices in Nordic Virtual Summit 2021 on 10.2.2021. I wrote this article to carry out pretty much the same content than that session.
There are many reasons to centralize your cloud identity to one place for example:
- End-user authenticates only to one place (one password or other authentication mechanism)
- Don’t have to care the identity authentication of cloud app
- You have centralized security actions (Conditional Access, MFA, Identity Protection)
- You have centralized logging
- Single-sign-on capabilities
You can use what identity provider (later on IdP) that you want, but in this case I will use Azure Active Directory, because it has many capabilities that I need. One capability that we are focusing in this article is access control forwarding to Microsoft Cloud App Security.
Application publishing types
Applications have been published for a long time for end users using centralized authentication e.g. Active Directory Federation Services or something else. Btw. It’s more clever to migrate authentication services towards Azure AD. There is a great article of it in Bloggerz.cloud!
When using Azure AD to publish applications for users you probably want to control their access to them with a Conditional Access that is a great tool for fine grained access control for any cloud applications integrated with Azure AD. You can find out more about Conditional access from our other articles.
This article focuses on applications that can be used with a browser and centralized identity in Azure AD.
Traditional application publishing
Traditionally we publish applications for end user with or without a multi-factor authentication. End users can access applications with browser from managed or unmanaged device. When accessing the application from an unmanaged device there is always a risk of data leakage when users downloads files or copies out the company data out a managed application. You do not have any control or monitor for anything that is happening in the session itself.
Secure application publishing
For a more secure application publishing you do not allow browser sessions to the application from unmanaged devices. This is a secure but not as productive scenario as it could be. Also this does not support any BYOD or Zero Trust scenarios.
Modern application publishing
When publishing your applications in a modern way, you give a productive but a secure access to your cloud applications with a browser even from unmanaged device. This is accomplished with a Microsoft Cloud App Security Session Control policies. You can monitor the session and if necessary, restrict actions such as Copy, Paste, Print, Download files etc.
You can start to control session in your cloud applications, when you forward the session control of browser applications to Cloud App Security with a Conditional Access Policies. Just turn on a Session Control with a custom policy.
When you redirect your authentications towards the Cloud App Security nothing happens yet. You have to first onboard applications and create policies for it.
Access Control and Session Control
Cloud App Security provides two different control methods for its conditional access application control. Access Control controls the access to the cloud application from a native or browser client and session control provides a deeper control for actions in a browser client side.
This article focuses on the session control, but the same application onboarding that is described later in this article is the same for Access Control side. You don’t have to do on-boarding twice. Access control and session control uses the same application list.
Session Control in Cloud App Security
When you have applications redirected towards a cloud app security, you first onboard those for a session control. There are three types of applications that you can onboard:
- Session control supported applications
- Featured applications
- Unlisted applications
Session control supported applications
Session control supported applications are already ready to onboard for session control. There are URLs that the application is using in place and you just have to turn on the session control with a policy. You recognize these apps from a Session control text under a column called Available controls.
Featured applications are already available in Cloud App Security, but there is not a tested session control support available from Microsoft side. It can work and mostly it does, but you have to just add URLs that the application is using to enable the session control. You can recognize a featured application without a session control support from a blue plus circle and a text Request session control text under a column Available controls.
You can place a request to Microsoft that they provide the session control support by clicking the text or you can implement the session control yourself. To do it yourself, select three dots from the right hand side and select Edit app…
Add all URLs that the application is using if you know to the User-defined domains field (you can view the list of domains that someone has visited from the View app domains… text above the domain field). If you do not know those yet, just go forward, you will discover those URL’s next.
Then you have to test the application. DO NOT SELECT Use with Conditional Access App Control yet. When ready select Save.
Testing the application
Under Cloud App Security settings the last item in the list is App onboarding /maintenance. Add your account to the included users for testing the session control.
Try now access the application that you are testing. You find an information that this application needs to be on-boarded for session control. Install provided CA certificates (Current CA and Next CA) to your Trusted Root Certificate Authorities store in Current User or Local Machine and restart the browser. Go to the same app and click Continue to <app name>.
Browse the application around to discover all URLs that the application is using. Test same time that the app works correctly. In the bottom of screen you will see the Cloud App Security on-boarding toolbar. It is discovering domains that the application is using. You can export discovered domains domains from the Discovered domains section and add them to the application as you added the first URL above.
When the application works you can select Use with Conditional Access app control from the Edit App. And you it will be onboarded as a session control supported application.
The application is now ready for a session control in policy section.
If you have an unlisted application that is not recognized by Cloud App Security, the procedure is almost same as above.
You see that you have new unlisted Azure AD apps for a Conditional Access App Control from the yellow bar above the featured applications.
Selecting the link you see a list of unlisted applications that are not already available in Cloud App Security catalog. Select a plus icon to add an unlisted application to the app control.
If you know that the URL where the unlisted application is pointing to is already in Cloud App Security App Catalog, but the URL is not just recognized to it, select the application from list under standard apps and continue process of featured application on-boarding. If the app is not available in Cloud App Security, select This is a custom app and Next.
Fill the information about the app to the windows and select Add app. It will add the app to the list of applications available for Microsoft Clodu App Security’s conditional access application control. Now you can continue adding a session control support for it with the same process as a featured application above.
Session Control policies
You can manage session control for you end users through Cloud App Security policies. Create a new Session policy under policies.
Give a descriptive name for policy and select the Session control type. There are four types:
- Monitor only – Monitors only sessions, do not restrict any actions
- Block activities – You can block Copy/Cut/Paste/Print etc.
- Control file download (with inspection) – Block e.g. file downloads
- Control file upload (with inspection) – Enforce Microsoft Threat Intelligence scanning for files that user is uploading to your app
From the activity source select filters and conditions to which devices you want to apply the policy (Device tag).
Which applications this policy is applied to (App). You can select Office 365 also. Office 365 includes all current and future Office 365 end user applications.
Next you define your filters for activity types.
Select the mode of policy Test or Block and save the policy. In block mode, you can specify a custom message that is showed to user when blocking the activity.
If you want just limit the access without creating an alert, clear the check box about the creating an alert.
After saving the policy, end users will be monitored and activities will be blocked when accessing applications that you have chosen.
Control file download
When controlling the file download activity you can use for example Microsoft Information Protection label as a filter in policy.
You can block the download or enforce a Microsoft Information Protection encryption to the file while downloading it.
Control file upload
When adding an upload policy to your apps, you can enforce a malware detection scan to files by using Microsoft Threat Intelligence as a method.
End user experience
When end user is accessing the session controlled app they will see a different URL than the original one and an information that the access is monitored.
When continuing to the application all of your session control policies are in place and controlling the session. If user tries to copy (and you have restricted it), she gets the message that the action is blocked and your custom message.
Notice also the URL for the app that it is proxied through the Cloud App Security.
What I should have done always
Of course when implementing a session control there are several ways to accomplish it correct way. Here are my TOP 5 points that you should take care of. Perhaps I have not done some of those and learned that I should do them in next projects 😀
- Test applications before onboarding to session control
- Monitor used applications and prepare before pilot
- Take with enough large pilot group
- Do not use Cut, Copy and Paste actions in every app
- Inform your users
You will lose the productivity in apps if you block Cut / Copy / Paste actions. Use those carefully in highly confidential classified applications only. User can always write the text out or take a photo with a phone of it…
Prodip K Saha · 30.07.2021 at 03.24
Nice and thorough article on Azure AD and MCAS and how to connect the dots.
I am able to get all those done and integrated Azure AD CA with session control policy in MCAS. Not sure if you come across this behavior, after all the redirections mcas is routing the users to top level domain! Users are losing the context, meaning if I want to go to site /sites/abcxyz, mcas is always taking the user to my-domain.mcas.ms. It’s losing /sites/abcxyz.
Have you come across similar url redirection issues?
Markus Lintuala · 30.07.2021 at 09.58
Some sites might have internal redirections and code bugs, so you can not proxy it with the current code. You can try to find issues with browser’s developer mode and point those out for the site developer. Another way to get it working (on MCAS side) is under advanced settins of application in MCAS to specify exact logon url and switch the redirection configuration (checkbox) if the site starts working. At the end those are only workarounds for bugs and internal redirections in the applications that you are trying to access.