You can start here to begin configuring your Azure AD Conditional Access (AADCA) policy. Creating the Signal Portion of the Azure AD Conditional Access Policy Let’s walk through creating this part of the policy.
Luckily, you can now enable policies in report mode to evaluate the impact first. One thing you will learn in Azure is that you need to exercise an abundance of caution. Signals aren’t too complicated and it comes down to how you want to slice things up.
When we look at conditional access, we think about If then statements. Microsoft’s image below focuses on three main areas, which we can discuss briefly as we walk through creating a policy. I don’t plan on beating a dead horse around this considering there’s plenty of documentation out there on it. It’s in SUPER BETA, which isn’t really a thing but its a minimally viable product thus far that shouldn’t be used outside of testing. I will warn you that this is largely a work-in-progress at this point with its official introduction in WS1 2008. We are going to explore what Azure Conditional Access is, how the integration for Workspace ONE (WS1) “works” at this point, enrolling devices, and what it buys you as engineers. It’s a very desirable culmination, which doesn’t force you to switch MDMs (much harder than it sounds) and let’s you deliver best-in-class security to your enterprise. The concept is simple: use Workspace ONE’s Zero Trust Security concepts to feed Azure conditional access. I think it was a year or two ago when the long-desired integration between Intune and 3rd party MDMs was announced for VMware’s Workspace ONE.