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. The concept is simple: use Workspace ONE’s Zero Trust Security concepts to feed Azure conditional access. 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.

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. I will warn you that this is largely a work-in-progress at this point with its official introduction in WS1 2008. 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.

What is Azure Conditional Access?

I don’t plan on beating a dead horse around this considering there’s plenty of documentation out there on it. Microsoft’s image below focuses on three main areas, which we can discuss briefly as we walk through creating a policy.

Azure AD Conditional Access Signals

When we look at conditional access, we think about If then statements. Signals are the “If” in that statements, which are essentially the “what/who” we are evaluating. Signals could be:

• The Users or Groups entitled to the policy
• The Network the traffic originates from
• Devices or Apps
• Risk Scores or Microsoft’s Cloud App Security (MCAS)

Signals aren’t too complicated and it comes down to how you want to slice things up. One thing you will learn in Azure is that you need to exercise an abundance of caution. Luckily, you can now enable policies in report mode to evaluate the impact first. Let’s walk through creating this part of the policy.

Creating the Signal Portion of the Azure AD Conditional Access Policy

You can start here to begin configuring your Azure AD Conditional Access (AADCA) policy. First, we will enable it for administrators for initial evaluation. You will notice one of the very cool things that they do is let you scope policies to external users, specific Azure roles, or AAD groups.

Once you have build that portion, you can specify what cloud apps or actions you want to apply the policy. The most common one will be seen below, with applying the policy to Office 365.

Additionally, you could create a separate policy to enforce registrations with Azure AD to only be on secure networks with the “user actions” section:

The last part of signals are the conditions, which we are all familiar with. I think it’s pretty nice that you can exclude out Hybrid Azure AD joined devices and just focus on compliance.

Device Platforms	Locations	Client Apps	Device State

Azure AD Conditional Access Decisions

The other part of AADCA are decisions. This is the compelling aspect to conditional access. We focus on allow/block decisions based on various criteria. Some of the popular options are:

• Device in Compliance
• Multi-factor Authentication
• Requiring App Protection Policy
• Require Approved Apps

Creating the Decision Portion of the Azure AD Conditional Access Policy

Now, we can complete the other half of our AADCA policy. You can see the visuals below, but overall it’s really interesting.

Grant Controls	Session Controls

The Grant Controls are simple. I focus on the requirements to “Grant Access” because that’s the goal. This example says my WS1 device must be compliant, have App Protection Policies (read more about those here), and requires approved client apps. That portion is straight-forward. Things get more interesting in session controls.

Session Controls will let you implement the MCAS integration (I’m not focusing on that here as not everyone has E5),sign-in frequency, and app enforcement restrictions. App Enforcement Restrictions is a major focus I’m hitting on. One of the great use cases is to limit access to Exchange/SharePoint if devices are non-compliant. I won’t cover the setup as its simple, which you can read about here.

Once done, you can click “Create”. Make sure you select “Report-only” as you want to evaluate the policy carefully.

Setting up Azure AD Conditional Access in Intune

The setup is super simple to get Intune ready for working with Workspace ONE.

You navigate to Partner Compliance Management and click new, select the compliance partner and platform:

Assign it to your users, click next and create:

Now, you will see your WS1 compliance partner is set, assigned, and in sync:

Setting up Azure AD Conditional Access in Workspace ONE UEM

The setup is fairly easy. It’s good to point out the pre-requisites: UEM 2008 and opted into WS1 intelligence. That’s outside of your Microsoft licenses of course. You can start by navigating to Settings > Enterprise Integration > Directory Services and configure the Azure AD integration as seen below.

Once you click “Enabled” on the iOS and Android AADCA section, you will be prompted to authenticate and set things up.

WS1 Intelligence, which powers this journey will flip it over and the Azure Enterprise App will get setup for WS1 Conditional Access as you can see.

Once its done, you get this little page which you can close.

It finishes up by clicking the “Complete” button and you are all done with the WS1 side of things.

Enrolling WS1 Devices in Azure Active Directory

BIG UPDATE!!!

A piece of good news, after having a few discussions and doing some additional testing I was able to get this working seamlessly. It appears that if you set your AADCA Policy to “Report Only” it will NOT seamlessly enroll your device in Azure AD.

I learned that if you turn the policy to “ON” that it will give you an amazing and seamless flow. Check out my video below:

The Manual Way

This is the hard part. I struggled for this a bit and then I got lucky. I found this nice article here from awhile back by one of the SEs at VMware. Basically, they discovered to register a device with Azure AD for AADCA you use this for iOS or Android:

iOS: airwatch://conditionalaccess?partner=microsoft

awagent://com.airwatch.androidagent?component=conditionalaccess&partnertype=microsoft

One would expect once this is ready for prime-time, the Hub will do this in the background. Let’s walk through the flow after I hit the URL in my browser.

It will ask you if it can open the page in the Hub.

Next, you are prompted to select an account inside of the Microsoft Authenticator.

Once authenticated, you click “Register” for your device to be registered with Azure AD.

The Hub confirms your successful enrollment of the device in Azure AD.

The question is: “Did this actually work?” I can now see my device in Azure AD listed and enrolled as an Intune device despite not being inside of Intune itself.

AADCA User Experience

As far as the user experience, you can watch the video that VMware already published on this as a nice example of how it all works. There’s no major reason to do this myself at his juncture until the offering becomes GA.

Update: Known Issue around Azure AD Conditional Access and Azure AD Join

One issue that I was asked about recently is around issues with Azure AD Join when AAD-CA is in place.

In your Conditional Access Policy, you must exclude the cloud app “Workspace ONE Conditional Access” otherwise you will not be able to Azure AD Join. It’s the epitome of a chicken and egg issue where you cannot Azure AD Join and become compliant because you are not compliant:

That comes into play specifically when you have a “Grant Access” rule that requires a device to be marked as compliant in order to access the specified resource. You don’t see this EVERYTIME, but it mainly comes into play when a company is enforcing AAD-CA on all cloud apps:

Final Thoughts

I wanted to share a few final thoughts when looking at this. The thing that worries me is that VMware has a public article on this offering here. Personally, I wouldn’t be putting anything public on this for user consumption. I can’t imagine how many tickets this is creating for VMware’s EUC support.

I know people are dying for this functionality, but it’s not even remotely ready and the information isn’t out there for people to actually test this. It’s an incredibly exciting feature that I personally am dying for. We will get there soon, but let’s do things responsibly. This is BETA and should be hidden. My hope is with getting more information out there that people may “try” to test it. The continued steps forward are very exciting and I am optimistic for this offering once it gets mature.