One of the scenario’s we can build with Conditional Access, is the scenario where we restrict access inside the web application itself. By doing so, you could for example limit the functionality of the web applications on non-managed devices, or when accessing the web application from a country where your company normally doesn’t operate. The web applications can be configured to behave differently if the user is applicable for a Conditional Access policy where App Enforced restrictions are configured.
Within the Office 365 suite of applications, the following web applications are supported for App Enforced Restrictions:
Outlook Web Access
SharePoint and OneDrive
In this post I will go into detail on how to setup these app enforced restriction and what the expected behavior will be from an end-user perspective.
One of the advantages of Microsoft having many customers using its services is that Microsoft can leverage data from those customers and apply some real fancy Machine Learning on that data, coming from Azure AD, Microsoft Accounts and even Xbox services.
Based on all that data the Machine Learning capabilities are able to identify identity risks. Based on the risk, automatic investigation, remediation and sharing of that data with other solutions able to leverage it is possible. The outcome of risk is expressed as either High, Medium, Low or No Risk. This outcome can later be used to define policies.
By leveraging Azure AD Identity Protection you are able to use the signals provided by Microsoft and trigger “actions” – the signals can also be leveraged in your conditional access policies.
discussed the baseline policies in part
5 of my blogpost series “Conditional
Access Demystified“, while they provided a welcome addition, one of
the main disadvantages of the baseline policies in its current preview form was
that there was no option to exclude accounts from the policy, which was in
contradiction with the best practice for break glass accounts and therefore
made the policies not usable in some scenario’s.
In my blog article series on Conditional Access Demystied I mentioned that Conditional Access can be used to route sessions toward Microsoft Cloud App Security (MCAS). In this article I will go into more detail on what MCAS is, and how to setup Conditional Access App Control.
Disclaimer: This article discusses the full option MCAS product, there are some other flavors providing partial functionality like Office 365 Cloud App Security and Cloud App Discovery (CAD). For information about licensing, see the Microsoft Cloud App Security licensing datasheet.
When you want to integrate other products into your Conditional Access
environment you can use “Custom controls” to include products from
other vendors into your Conditional Access conditions. If a custom control is
used the browser is redirected to the external service, performs any required
authentication or validation activities, and is then redirected back to Azure
Active Directory. If the user was successfully authenticated or validated, the
user continues in the Conditional Access flow. More information and some
samples can be found here: Azure AD + 3rd party MFA = Azure AD Custom Controls
– https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/. This feature is still in preview
but very promising for 3rd party vendors who want to integrate with Conditional
each conditional access policy created, we will create an exclusion group, so
that we can deal with exceptions in our environment. These exception groups
will be setup with Access review functionality (if available) to make sure that
the membership of these groups are evaluated on a regular basis.
When designing a Conditional Access strategy for a customer we first
need to start with an inventory of the environment, in the most ideal situation
you would design and implement conditional access in a green field scenario,
but I for sure never had that luxury before so it’s better to assume that the
customer is already using cloud apps and wants to implement conditional access
as an security measure.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.