Conditional Access

Azure AD Sign-in via Google Chrome and Conditional Access

While testing MFA, Conditional Access and all the other good stuff Azure AD provides, I came across this scenario:

Conditional Access configured to require MFA if the user wasn’t on an Azure AD Hybrid PC, or coming from an internal IP.

User on an Azure AD Hybrid PC, but on an external IP.

User uses Chrome to access a Microsoft resource, and gets challenged despite being on the Azure AD Hybrid PC.

It seems that the sign-in process isn’t aware of the state of the computer when using Chrome- but there is an easy fix: deploy Windows 10 Accounts extensions for Chrome.

This is really easy to do via Group Policy.

  1. If you don’t already have them, get the ADMX Group Policy files for Google Chrome and deploy into your environment
  2. Under User Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions, configure the policy ‘Configure the list of force-installed apps and extensions’:

3. Change the radio button to enabled, click ‘Show’ and enter the value for the add-in

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

4. Do your normal process of configuring the Group Policy object to target the users you want, run a gpupdate and see the addin silently turn up in Chrome. The only user impact will be a visible Windows logo to the left of the Google Accounts area in the top bar of Chrome.

Peter van de Woude has documented how to do this via registry, so read his post if you want info on how to do that –  as well as how to then deploy via Intune and PowerShell script.

Worth doing if you use Azure AD connect, and highly recommended if you’re using Conditional Access. 

Conditional Access Makes MFA Migration Easier

Microsoft Azure’s Conditional Access is a really great way to get a company using Multi-Factor Authentication. The old argument of not wanting MFA to get in the way of logins constantly goes away with this solution, because it lets you set the rules and scenarios where MFA will and won’t trigger.

To be more accurate, the access controls that Conditional Access can use lets you use more than just MFA to log in (username/password/token style). You can set the rules so a trusted device negates the need for MFA.

This isn’t new anymore either. Here’s a video from Microsoft back in March 2017 talking about how all this works:

What this means is that someone with a username and password on a device that is either InTune enrolled, or set up for Azure AD Hybrid is trustworthy enough. Of course this is less secure than asking for MFA every time, but do you really need to do that when someone is using their work laptop?

Another condition to choose from is ‘Locations’. You can decide that MFA won’t kick in if the login is coming from inside your corporate network. You can also target different applications with different rules that stack – so maybe the payroll system will always ask for MFA, but a less sensitive one will only ask when not on a managed device.

Security wise, there’s also a ‘Sign-in Risk‘ option where each authentication attempt is evaluated and given a risk ranking, and access can be granted or blocked based on the results. Note that this one needs Azure AD Premium P2 which isn’t part of the Microsoft 365 E3 subscription – E5 or separate licensing is required.

Because Conditional Access works like a bunch of Outlook rules, you can slowly build up and adjust what kicks in when. It’s really easy to do, and there’s really no excuse (once you have licensing!) to stop you setting it up ready to demo to staff. 

Combine Conditional Access with Azure AD App Proxy where you can externalise any internal web based app, while forcing auth on it and you’ve got an easy way of enabling workers to do their jobs remotely, while being happy about the security around it – and NOT just poking a hole in a firewall, exposing your IIS box to the world.

Conditional Access Stuck on “Loading…”

There’s currently an issue with configuring Conditional Access via Azure Active Directory. There’s an open ticket with Microsoft Support, with no ETA at the time of writing.

The issue:  When trying to configure a new policy for Conditional Access against an Azure Active Directory application, the ‘New’ page gets stuck loading. I’ve tested this on multiple browsers, tenants, internet connections, computers, and had Microsoft support confirm.

The path to doing this is from the Azure portal – Azure Active Directory > Enterprise Applications > choose your application > Conditional Access > New policy:

The Workaround: Thankfully it’s not a showstopper, as there’s another way to get to Conditional Access and it works fine. Instead of going via a specific app first, you can just go via Azure Active Directory > Conditional Access > New policy. Also Azure Active Directory > Enterprise Applications > Conditional Access > New policy works, it’s just an extra click to the same screen.

Points to take note of – if something’s broken, try accessing the same function from a different route of click-through links and it might work another way. Also, log these issues with Microsoft Support as overall the support is pretty good and often the issue won’t be anything to do with you. Test different scenarios wherever possible too, and also asking the question on Twitter can get some extra attention!