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.
Microsoft explains Conditional Access in the following way. Conditional Access consists of access scenario’s called Conditional Access policies. An Conditional Access policy follows the following pattern:
“When this happens” defines the reason for triggering your policy. This reason is characterized by a group of conditions that have been satisfied. With “Then do this” you define how users can access your cloud apps.
Technically this is translated to Conditions (When this happens) and Access controls (Then do this)
Microsoft describes Conditional Access as followed: “With Conditional Access, you can implement automated access control decisions for accessing your cloud apps that are based on conditions.” and “Conditional Access policies are enforced after the first-factor authentication has been completed. Therefore, Conditional Access is not intended as a first line defense for scenarios like denial-of-service (DoS) attacks, but can utilize signals from these events (e.g. the sign-in risk level, location of the request, and so on) to determine access.”
The way I see it, the best way to explain what Conditional Access does,
is by making the comparison to a firewall. A firewall determines what traffic
can access your resources, under what circumstances and Conditional Access sort
of does the same. Conditional Access describes under what circumstances users
can access your cloud applications.
In July 2016 Microsoft made Conditional Access generally available as a feature of Azure Active Directory (AzureAD). Since that time I had a love and hate relationship with this functionality of Azure AD. Mainly because it’s difficult to test scenario’s and some changes can have a really high impact. I even experienced being locked out of accessing the Azure portal during one of my tests.
Why this series of articles?
Some good documentation from Microsoft and blogpost by
fellow bloggers detailing Conditional Access scenario’s, but not really a
one-stop shopping overview. With this series of blog posts I hope to achieve