Conditional Access

Many customers that I’ve been advising constantly are challenged with how much access should be restricted without disruption to business operations.

Typically, when we’re approaching Zero-Trust a backbone of Azure is Azure AD that sits as the IdP.

In this I’m going to show some features that I find many customers unaware of in Conditional Access and ways to utilize this control to make more informed decisions on a rollout.

So for starters I’m going to be on the page of Azure AD Conditional Access as shown below

As you can see we have a few options I’ve included a Sign-in risk policy as an example this is a demo tenant exercise caution as Conditional Access can lead to some adverse consequences such as locking yourself out of your tenant if not carefully navigated this is why it’s recommended to have three global administrators (one is a break-glass).

We’re most interested in the +New Policy from template (Preview) this has been in preview for some time but serves as a good example following our secure best practices for a more out-of-box experience.

The wizard will prompt us with a few options as you can see the categories have two options we will select Identities and come back to devices later – hit next.

We’re prompted with a few options that have some descriptions along with a hyperlink that states View policy summary.

As we can see the first one is a requirement that every organization should have such as more stringent controls against elevated privileges let’s click the View policy summary

So a point of reference is I like to think of policies as reading code chronologically as we can see we have name reference along with assignments of include/exclude.

What are the roles Microsoft deems as Admin? As you can see roles especially in RBAC are a good portion but anything you could expect with the title of Administrator is referenced here as the roles (pre-built) again if your running custom roles you’ll have to tweak this as the template is including built-in.

Grant means after these conditions are met how are we treating the granting of this policy – as you can see MFA is required.

Most of the time I show customers this template feature to get them started on moving towards best practices as if they wanted a quick fix this a fast reference in the portal.

So now let’s take a look if we step back on what is expressed for Devices

Some more selections that you can see with description of what that enablement of the policy will be as you should be using a configuration manager to manage assets this has the implications of Azure AD Joined Devices for Admins

This includes as you can recall the same listing of the roles for administrators but as we can see the access controls differ in this circumstance

So if the device isn’t compliant by the policy you push to the Azure AD Joined device or Hybrid Azure AD Joined it won’t be granted, this is a good start and encompasses a compliance policy that can be used with Microsoft Intune.

So after we have a good understanding that we can reference templates out of the box what about actually implementing these policies and testing them prior to moving to production?

We have another feature to explore in the following image

As we navigate back to our first page of Conditional Access you can see the What If with the human tiny icon.

This is essentially allowing you to go through a policy configuration and evaluate the conditions.

I’ve chosen a Megan Bowen and I’m also showing where we can apply these applies to such as Cloud Apps (can be third-party if configured)

For the conditions I’ve chosen this as we can see Device State is being deprecated this wasn’t referenced earlier but should be known if you are planning on this capability.

So we’ve configured a policy but what’s next?

This allows a safe action at the bottom as we can see a What If statement

Again this isn’t meant to be a end all be all for your policy but rather you to evaluate how granular you can put conditional access along with the multiple options and run in a “What If” such as if you wanted to test this without creating the policy and assigning a group.

So I’m going to run through this with a configured policy so we can see how this can be applied to a group in my tenant in a “Report-Only” note if you put this to On this enforcement will happen.

A quick callout on what is Client Apps

You can see we have a few options for instance, do we want mobile apps and desktop clients and browser?

If your running legacy consider using Azure AD Application Proxy or refactoring to include modern authentication.

On the grant you can see that it you can’t use both MFA / MFA Strength so in this case I’m just testing and going to put a Passwordless MFA (the ideal) control if possible of FIDO2 Keys.

What is also offered is CAE as shown below

I highly recommend this but as we are running – report-only mode I won’t be using this but just to illustrate it’s control and information can be described by hovering over the information icon.

So what are the implications well we can see with the caution the experience may differ on the MacOS, iOS, Android and Linux because of the report-only mode.

I’ll hit the create button now, so what’s next?

Evaluate the conditional access control by accessing the sign-in logs and simulating the sign-in experience with a test group. You’ll likely fine tune policies as you determine what is feasible in regards to User Risk/ Sign-in Risk however, these controls should be applied in the CA Policy because this is additional protective controls that apply to your user such as impossible travel, anomalous token, and atypical travel. This list provides more context on the coverage of this https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks if you’d like to learn more.

Identity access is paramount in Cloud and only growing in nature as a entry point into your cloud environment is attack vector its important to exercise the efficacy of these policies rigorously.

Hopefully after this you’re more aware how Azure AD utilizes Conditional Access Policies to users/groups/workload identities and behind the curtains of this important feature.

I’d remiss to not note that this a feature that gets the most impact from Azure AD P2 (M365 E5 License) or EMS E5 Security Add-on.

https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies