Conditional access is getting better and better and better

Yeah, I know, I’ve been using similar blog post titles recently. And yes, it might sound cheesy. However, looking specifically at conditional access, it’s easy to say that the current evolution, in the Azure portal, is better than it is in the Azure classic portal, which is better than it is in the Intune Silverlight portal. Based on that, maybe  “The evolution of conditional access” would have been a nice title also. In this post I will go through a little bit of history of conditional access, followed by going through the enhanced capabilities of conditional access in the Azure portal.

Little bit of history

Let’s start by looking at a little bit of history of conditional access. No, I won’t put all the evolutions on a timeline, but I will try to show the biggest changes. Conditional access started as a feature in the Intune Silverlight portal only. In that time it was limited to a few Office 365 services. Later on conditional access also became part of the Azure classic portal and the functionalities got expanded to include other cloud apps and published apps. Very recently conditional access also became part of the Azure portal (still in preview) and the functionalities got expanded to include multiple policies and many, many configuration options. Now let’s go through these evolution in a bit more detail.

Intune Silverlight portal – The Intune Silverlight portal is the portal were it all started for the conditional access functionalities. In the Intune Silverlight portal it’s possible to enable and configure conditional access for the following Microsoft cloud services:

  • Exchange Online;
  • Exchange On-premises;
  • Exchange Online Dedicated (new and legacy);
  • SharePoint Online;
  • Skype for Business Online;
  • Dynamics CRM Online.

Within the conditional access policies it’s possible to configure the following conditions:

  • Platforms (all or specific);
  • Browser (all or supported only);
  • Groups (targeted and/or exempted).
IntuneSilverlight_Example

Azure classic portal – The Azure classic portal is the portal that started with providing more capabilities by making conditional access configurations available as part of Azure AD. In the Azure classic portal it’s possible to configure conditional access for the following additional apps (in addition to the Intune Silverlight portal):

  • Software as a service (SaaS) apps connected to Azure AD;
  • On-premises apps published via the Azure AD Application Proxy.

Within the conditional access policies it’s possible to configure the following additional conditions (in addition to the Intune Silverlight portal):

  • Multi-factor authentication (always, when not at work, block when not at work).
AzureClassic_Example

Azure portal – The Azure portal is still in preview for the Azure AD functionalities. However, the Azure portal is were conditional access becomes  a grown-up functionality. The Azure portal also supports all the mentioned apps from the Azure classic portal and the Intune Silverlight portal. On top of that, it enables the ability to create one policy for all apps, or a policy per app, or even multiple policies per app.

Within the conditional access policies it’s also possible to configure all the mentioned conditions from the Azure classis portal and the Intune Silverlight portal. On top of that, it enables to ability to make every available combination of the available conditions.

Note: The Azure portal even includes the capability to configure conditional access for managed apps. This is part of the Intune mobile app management configuration.

Azure_Example

Note: At this moment all three locations are still available for configuring conditional access. When a conditional access policy is configured at multiple locations, the end-user only gets access when all requirements are met.

Conditional access in the Azure portal

This section is about a preview of the Azure AD management experience in the Azure portal.

Now let’s have a look at the new conditional access experience in the Azure portal and why these changes are really interesting. Let’s do this by going through the different controls and condition statements that are available in the Azure portal.

Policies

The first thing that’s important to know, is that there is no limit anymore in creating conditional access policies for specific apps. The configuration in the Azure portal enables the administrator to create multiple conditional access policies. Not just one per cloud app, but it can even be multiple policies per cloud app. Before every sign-in, Azure AD evaluates all applicable policies and ensures that all requirements are met before granting access to the end-user. Now let’s have a look at adding a policy in more detail.

Policy – When adding a new conditional access policies there are the following 4 sections that can be configured:

  • Name: Every conditional access policy requires a name. That name will be used to identify the policy;
  • Assignments: With assignments the administrator defines the criteria that need to be met, for the controls to be applied, in the form of a condition statement;
  • Controls: With controls the administrator can either block access or allow access. And by allowing access the administrator can also add additional requirements;
  • Enable policy: Every conditional access policy will only be applied when it’s enabled.

Azure_NewPolicy

Assignments

The next thing is to have a look the different assignments that can be part of the condition statement. The assignments can be configured for User and groups, Cloud apps and additional Conditions. When there are multiple assignments configured in the conditional access policy, all assignments are logically ANDed. If there are multiple assignment configured, all assignments must be satisfied.

User and groups – In the User and groups assignment, the administrator can configure to who the conditional access policy must be applied. This can be done by including all users, or by  selecting specific users and/or groups. When specific users must be excluded, that can be configured by adding those users in the exclude section of this assignment. Azure_UsersGroups
Cloud apps – In the Cloud apps assignment, the administrator can configure to what the conditional access policy must be applied. This can be done by including all cloud apps, or by selecting specific cloud apps. When specific apps must be excluded, that can be configured by adding those apps in the exclude section of this assignment. Azure_CloudApps

Conditions – In the Conditions assignment, the administrator can configure how the conditional access must be applied. This can be done by configuring conditions in the following areas:

  • Sign-in risk: In the Sign-in risk condition, the administrator can configure to which risk the conditional access policy must be applied. This can be done by selecting the risk level of High, Medium, Low and No risk;
  • Device platforms: In the Device platforms condition, the administrator can configure to which platforms the conditional access policy must be applied. This can be done by including all platforms, or by selecting specific platforms. When specific platforms must be excluded, that can be configured by adding those platforms in the exclude section of this condition;
  • Locations: In the Location condition, the administrator can configure to which locations the conditional access policy must be applied. The location is identified by the IP address of the device used by the end-user. This can be done by including all locations, or by selecting specific trusted IPs. When trusted IPs must be excluded, that can be configured by selecting those trusted IPs in the exclude section of this condition;
  • Clients apps: In the Client apps condition, the administrator can configure to which apps the conditional access policy must be applied. This can be done by selecting Browser and/or Mobile apps and desktop app.
Azure_Conditions

Controls

Let’s end this post by having a look at the different controls. The controls can be used to either block or allow access. And by allowing access the administrator can, and also must, add additional requirements.

Grant – In the Grant control, the administrator can configure what must be done when the configured conditions happen. This can be done by selecting Block access or Allow access. When the control is used to allow access at least one of the following requirements must be configured:

  • Require multi-factor authentication: The multi-factor authentication requirement can be used to require strong authentication. This can be used in combination with Azure multi-factor authentication, or with an on-premises multi-factor authentication provider (in combination with ADFS);
  • Require compliant device: The compliant device requirement can be used to require a device to be compliant to an additional device compliancy policy. That compliancy policy can be targeted through Microsoft Intune (or any other MDM management solution);
  • Require domain joined device: The domain joined device requirement can be used to require a device to be domain joined to an on-premises AD. The domain join requires automatic registration of the domain joined device in Azure AD.

When multiple requirements are configured in the conditional access policy, the administrator can choose to require all the selected controls or just one of them.

Azure_Grant

Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.

More information

For more information about conditional access via the Azure portal, the Azure classic portal, or the Intune Silverlight portal, please refer to:

10 thoughts on “Conditional access is getting better and better and better”

  1. Hi Peter, Interesting article. One of the biggest issues we face is preventing email access on unauthorised devices. Whilst you can create a policy for Exchange Online to prevent non compliant devices or non domain joined machines. At the moment there is nothing stopping a user from enrolling their own personal device with Intune and then it will be complaint. They can then access email. I understand in the preview portal there is now a way to block enrollments unless the imei number matches a list. I believe it only works on iOS at the moment. Have you any experience with this issue? or overcome it?

    Reply
    • Hi Dale,

      Correct, at this moment it’s not pretty. However, you can also wonder how bad it is if a user has the email access. If you’re using conditional access you can still force the user to comply to your requirements and make sure that the user is only using managed apps. I would say, think about controlling the data instead of controlling the devices.

      Regards,
      Peter

      Reply
  2. Hi Peter,

    I’m curious about the quote below about use of MFA.

    “Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.”

    We are trying to use require domain joined device OR MFA. On Windows 10 devices all is well, if the device is registered the user goes through clean. On a Windows 7 PC that has the workplace join app and is registered properly, we get a MFA prompt every time when accessing via the portal but only get the MFA prompt the first time if going through the onedrive app. If you access the portal via Chrome you get MFA no matter the OS.

    Do you have a better view into MS and their roadmap of what they plan to work on? Our company is still primarily Windows 7 and I’d love to give our users a better user experience.

    Reply
    • Hi Matt,

      Keep in mind that pieces are still in preview and also note that my note came straight from the docs. Sadly I don’t know anything more about the roadmap as is publically available.

      Peter

      Reply
  3. Hi Peter, stumbled across this article today. You stated: “Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.”

    I notice you didn’t mention the domain-joined control. Does that mean you *can* configure the Conditional Access rules to bypass MFA if the device is domain-joined (and registered with Azure AD)?

    If so, why would that work but not the Compliant Device control?

    -Ben

    Reply
    • Hi Ben,

      That quote came straight from the docs. As it’s still using bits and pieces from preview features, this is something you must test to know. And even try again a couple of weeks later.

      Regards,
      Peter

      Reply
  4. Hi Peter,

    We have a Sharepoint 2013 On-prem. We would like to implement Conditional Access with MFA for the SP 2013 On-prem environment. Would this technically be possible? We have all the license requirements in place.

    Jurgen

    Reply
  5. Hi Peter,

    I am using conditional access policies from the new Intune portal. I’ve disabled all conditional access policies on the Siverlight portal.

    Current Policy:

    App selected – Exchange Online,
    Device Platform -macOS,
    Access control -Require device to be marked as compliant

    Is it possible to have MacOS Mail app to send out an email asking “enrollment is required before accessing data” ?

    Outlook app for MacOS is correctly asking for the device to be enrolled, but the Mail app is not affected at all from this. It can send and receive mail without any issues.

    Thanks,
    Egert

    Reply

Leave a Reply to Ben Hanson Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.