Phew, another article about Conditional Access. That’s right, there a quite a few already. Fortunately, this topic never gets old. Here’s why:

In the cloud there are no traditional network perimeters anymore. On-prem appliances are rendered useless as cloud services can be accessed world-wide. All you need is a valid set of credentials to sign-in. Needless to say that you should implement additional security controls to counter attacks based on identity theft. Conditional Access does just that as part of Azure Active Directory.

Based on a set of criteria like…

• Source IP address
• Trusted devices
• Known applications
• Protected applications

… and filtered by users, groups, and cloud apps you can build a rule set based on which you allow users to access company resources or not. You can get even more sophisticated by leveraging Microsoft Cloud App Security Conditional Access App Control which uses a reverse proxy architecture to give admins real-time session control of browser access.

Note

This post is not a detailed technical walk through but focuses on different concepts on how you could use Conditional Access for criticality levels depending on your company policy.

I can’t give any advice on which scenario suits you best. Of course, scenario 1 is the most secure; however, there might be reasons to take a different approach.

Conditional Access scenarios

In the following scenarios I will talk about different levels of control you might want to enforce for clients and user. For each, every platform supported by Microsoft will be included (Windows 10, macOS, iOS, Android). However, I’ll leave Windows Phone out of the equation. Some points will be similar or the same for multiple platforms, however, I prefer to split those for granular adjustments and testing.

Please see the following references for some basic explanation of Conditional Access concepts:

Note

“Trusted device”:
corporate device that is either Intune-compliant or Hybrid Azure AD Joined. The latter can only be achieved by Windows 10. All platforms can be compliant if they are enrolled in Intune and match your compliance policies.

Scenario 1: maximum control

In this scenario we assume the following aspects:

• Only corporate devices can be used to access cloud apps
• Corporate use of private devices is forbidden
• Using public devices is forbidden

For Conditional Access that means:

• Windows 10 / macOS
  • Modern Authentication clients & browsers: Require trusted device
  • Legacy Authentication clients & Exchange ActiveSync: Block access
• iOS
  • Modern Authentication clients & browsers: Require compliant device (=> Apple DEP + Intune enrollment)
  • Legacy Authentication clients & Exchange ActiveSync : Block access
• Android
  • Modern Authentication clients & browsers: require compliant device (Android Enterprise COBO – “Corporate-Owned / Business-Only” + Intune enrollment)
  • Legacy Authentication clients & Exchange ActiveSync : Block access

To maintain full control as required in this scenario mobile devices (iOS / Android) must be under full company control. This can be achieved by Apple’s DEP program and by Android Enterprise COBO (“Corporate-Owned / Business-Only”). This is necessary to make sure that users can’t add personal Apple IDs or Google accounts.

To prevent unwanted software that might be used to leak data on Windows 10 and macOS you must take additional counter measures, e.g. Windows AppLocker oder Defender Application Control + a limited set of local administrative permissions. Unfortunately, this is no problem Conditional Access can fix.

Scenario 2: medium control

In this scenario we assume the following aspects:

• Only trusted devices can be used with Modern Auth clients like Office 365 ProPlus
• Browsers on desktop devices can be used on any device but the session must be protected
• company data on mobile devices must be containerized
• Mobile device enrollment to Intune is optional, personal use is allowed

For Conditional Access that means:

Windows 10 / macOS:

• Modern Authentication clients: require trusted device
• Browsers: Require MFA + Session Control (Block downloads, session expires after x hour(s) maximum) on unknown devices
• Legacy Authentication clients & Exchange ActiveSync : Block access

• All clients: require approved applications (protected by Intune App Protection)
• Legacy Authentication clients & Exchange ActiveSync : Block access

Android:

• All clients: require approved applications (protected by Intune App Protection)
• Legacy Authentication clients & Exchange ActiveSync : Block access

As you can see, iOS and Android rely on Intune App Protection to containerize and protect corporate data.

Please keep the following in mind: every mobile device scenario that is not built on full control as in scenario 1 has a severe problem in Europe and especially in Germany: If private use is allowed some very nasty legal problems might hit you. BUT please note: this information is just for reference. I am not giving legal advice. It’s just something to consider.

Scenario 3: minimum control

In this scenario we assume the following aspects:

• Only trusted devices can be used with Modern Auth clients like Office 365 ProPlus
• Browsers on desktop devices can be used after successful MFA
• Data on mobile devices must be opened with modern auth clients

Note

As you can see, even the minimum control scenario still contains some restrictions. That is because I wouldn’t recommend going any lower than that.

Windows 10 / macOS:

• Modern Authentication clients: require trusted device
• Browsers: Require MFA on unknown devices
• Legacy Authentication clients & Exchange ActiveSync : Block access

iOS

• All clients: require approved applications (protected by Intune App Protection)
• Legacy Authentication clients & Exchange ActiveSync : Block access

Android

• All clients: require approved applications (protected by Intune App Protection)
• Legacy Authentication clients & Exchange ActiveSync : Block access

Things to consider

• Get rid of legacy authentication and Exchange ActiveSync
• Cover all device platforms, it is fairly easy to change or spoof user agent strings
• IP-based conditions are “best effort”: they might be inaccurate
• Standard users should get as few prompts as possible; intrusive security is bad security
• Don’t lock yourself out: think twice before enabling Conditional Access policies; use break-glass accounts for emergency access
• Use the now GA “report-only” mode to evaluate your policies ahead of going live
• Depending on the scenario, it is possible to create Conditional Policies that cover more than one device platform. In projects, I usually split them up for more granular testing

Thanks for reading!

Chris

About the Author:
Hello there! My name is Christian Müller. I am working as an Senior Security Consultant at German Microsoft partner Skaylink. You can find me on Twitter and LinkedIn.

Reference:

Müller, C. (2020). Build a Strong Cloud Perimeter with Conditional Access. Available at: https://chrisonsecurity.net/2020/05/11/build-a-strong-cloud-perimeter-with-azure-ads-conditional-access/[Accessed: 19th May 2020].

Check out more great Azure content here