Conditional Access Policy Hell

When I started in dealing with Conditional Access policies, I started with the concept of a firewall as my foundation. However, once I realized you could create conflicting policies, I had to look deeper into how they functionally work and de-conflict. It turns out they aren’t firewall rules at all.

So, then I craft a strategy around managing CA policies in terms of controls. You make a policy the enforce controls on all applications/users and let exception based management take over. You get the power of a “deny all” policy and the advantage of articulating exceptions as needed.

• Multi-Factor Authentication? Required for all the things.

• Trusted, Compliant Device? Required for all the things.

• Locations? Narrowed down.

See a problem? No? Let me help.

Locations are _not_ a control. They are a condition, and when you craft an exception based on a condition, you have to rebuild all your controls. *sigh*. And, for what it’s worth, I agree with that and it’s not the locus of my ire today.

Travel Scenario

An employee gets permission to work abroad, and you want to create a limited scope solution that limits access to applications. You assess they that need basic access to Microsoft 365, but all other apps are off limits and make three changes: exception to the existing geo-location policy, a new geo-location policy tailored for the trip, and a final policy to block all apps not explicitly approved.

Now, when you setup the Traveller App restriction policy, you configure something fairly innocuous like the following:

You can see that it aligns with the visual, and you’ve met your least access requirement goals. Touchdown for the security team! Until…

The traveller arrives on scene

Your traveller arrives, they go to log in and fail to pass your CA policy stack. Their device is not compliant because it hasn’t checked in for too long. You scramble to go look through the access logs, and you see the failed logons. There’s two applications for device management that you need to add to the policy. “No big deal” you think…except it’s about to be.

You go to edit your CA Policy filter and those apps are nowhere to be found. You search by guid, by name, by desparation and still there are no indications that you can make an exception for the device to call home and validate compiance. Oh the humanity!

It turns out, buried in Microsoft documentation, that if you’re going for a strict approach for your abroad travelers, you’ll need to add two new service principals to Azure, so you can then add them to conditional access policies as a cloud application. These new service principals are:

1. Xplat Broker App ( a0e84e36-b067–4d5c-ab4a-3db38e598ae2)

2. TVM app (e724aa31–0f56–4018-b8be-f8cb82ca1196)

To add them, you’ll need to head to your favorite terminal emulator and run the following commands:

Import-Module Microsoft.Graph.Applications

$xplat = @{
 appId = "a0e84e36-b067–4d5c-ab4a-3db38e598ae2"
}

$tvm = @{
  appId = "e724aa31–0f56–4018-b8be-f8cb82ca1196"
}

New-MgServicePrincipal -BodyParameter $xplat
New-MgServicePrincipal -BodyParameter $tvm

And with that in place, your end user can now confirm compliance and sign on to their needed applications. Hopefully.In the event that your user runs into additional unexpected service dependencies while traveling abroad, the following steps will help:

1. Find the user’s failed sign log(s).

2. In the sign on log, look for the application id that was being requested.

3. If the application id is a sub-service for an application you approved for use, then use the same approach as above to add a new service principal and add that to your CA policy.

Fun right?…..right?

Come On Microsoft

Now, as I was pouring through the docs and checking my assumptions, Microsoft has littered their policy recommendations around not blocking all cloud apps. They know, and point out repeatedly, that doing so will result in undesired behavior and break of accounts. Like the ability for devices to check-in for compliance. I want to challenge their stance, and I’m open to push back.

I don’t think blocking “all apps” should be as archaic as this process is. Even knowing what I was looking for, it took a good 10–15 minutes to find the right document…and I knew it existed. Imagine being an overburdened security engineer who doesn’t have the foreknowledge or time to make that investment. It’s a pain.

ALL Microsoft Applications that are inscope to be impacted by a CA policy MUST be added to the list by default. Hiding services and dependencies only makes things harder for defenders and easier for attackers who can take advantage of Microsoft’s own reticence to commit to blocking all cloud apps.