New rich Conditional Access features with the Intune Ibiza Portal


Microsoft has started migrating Intune from the old Silverlight to the new Azure Ibiza portal which is HTML5 and PowerShell capable. The new Ibiza portal has lots of new features and one of them is Conditional Access!

How do I see Conditional Access in one sentence?

It’s the gatekeeper for giving you access to corporate resources or keeping you out!

Conditional Access in the Ibiza portal?

 

 

 

What can Conditional Access protect?

  • On premises and IaaS (Azure/AWS/etc.) hosted resources connected via Azure Application proxy
  • Office 365 apps hosted by Microsoft
  • Azure AD SaaS applications such as Salesforce which can be connected directly to Azure AD for Authentication.

For the full Conditional Access possibilities, you require an Intune license and Azure AD Premium.

Conditional Access Overview

Current supported operating systems for conditional access

  • iOS
  • Android
  • Windows Mobile
  • Windows

Applications require Modern Authentication to participate in the Conditional Access policies. More information can be found at: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-supported-apps

More info on supported browsers and applications: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-supported-apps

Note: If you connect an on premises or a SaaS application directly to ADFS instead of Azure AD, only some Conditional Access options are available. The most and enhanced options are only available when you connect your application via the Azure Application Proxy or directly to Azure AD. In both scenarios ADFS can still be used, but the application is first redirected to Azure AD so the enhanced Conditional Access features are checked first. Azure AD will forward the authentication requests to ADFS if you federated with Azure AD.

Some Conditional Access policies are still possible with an application connected directly to ADFS:

  • Claims based (such as only allow authentication from internal, require MFA from external etc.)
  • Use isregistered claims (with device writeback).
  • Devices registered with Intune and/or Azure AD will be written back to AD. Iscomplaint attribute is available in the device writeback as well.
  • Third party smartcards.

Enhanced conditional Access policies are only available if the application is connected directly to Azure AD in combination with Azure Application proxy:

  • Risk based access
  • Dynamic group based policies
  • Different Conditional Access settings per application
  • Limited Experience (SharePoint Online only at this moment)
  • Access based on MAM capable apps only*
  • More to come

*Not yet available.

As you can see ADFS is great for authentication, keeping passwords on premises and Single Sign-on support for domain joined machines, however to get the rich Conditional Access policies connect the app to Azure AD with Azure Application Proxy.

The advanced Risk based conditional Access policies are only available with an EMS E5 license. Unfortunately, I don’t have an E5 license so I will describe what could even more enhance the Conditional Access before going into the demo.

With Risk-based Conditional Access, a new layer of security has been added. EMS has machine learning techniques to track and monitor billions of log-ins, and identify accounts that may have been compromised. Risks are than evaluated on the following points:

  • Impossible Travel
    If a user signs in from the Netherlands and then signs in 10 min later in Asia. This would be impossible to travel so it will raise a flag.
  • Unfamiliar Locations
    Risk-based Conditional Access creates a baseline of all the locations a user might login from during the first few weeks of activity. If there is an abnormal behavior it will flag the user.
  • Suspicious IPs
    For example, the TOR IPs are suspicious and will raise a flag.
  • Leaked passwords on the web

All those learnings will create warning levels:

  • Low
  • Medium
  • High

You can set specific actions for the user when they receive a warning. For example:

  • Block access when the risk is High
  • Require password reset if risk is High
  • Require MFA is risk is Medium
  • Grant access when risk is low

Azure MFA or MFA authentication server on premises:

If you have a MFA service on premises you can leave the MFA control to ADFS. You can configure MFA for users logging in from external networks, use hardware tokens, use MFA for Radius etc. The MFA requirement can only be set per relying party and not for every O365 service separately. There is another option to let Azure AD decide if the service/application requires MFA. In that case, you can configure this for each application separately. Azure AD forward the MFA request to your on premises MFA server.

Note: If you have internal applications running through the O365 relying party on ADFS without connection to Azure, those won’t receive a MFA request anymore. Best is to create a new relying party for those services if MFA is mandatory.

Azure MFA is a service in Azure AD and can be used for second factor as well. This doesn’t require any on premises installed services , but is limited in functionality such as no hardware tokens. For on premises Radius there is a connector available https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-nps-extension

In my test lab, I let Azure AD decide when MFA is required and forward the MFA request to my on premises MFA servers. All my internal websites are connected via the Azure Application Proxy.

Let’s test the Conditional Access features

I used the following setup in my test lab:

  • ADFS + ADFS proxy
  • MFA Server
  • AD on premises + AD Connect
  • Azure AD
  • EMS E3 License*
  • Android tablet
  • Intune
  • Azure Application Proxy

Example scenario:
Salesforce (connected to Azure AD for authentication and user provisioning)

Access to Salesforce is only allowed when:

  • Users that have the AD attribute Title set to Marketing (Azure Dynamic group)

From external networks:

Have a Complaint Mobile device* + require MFA OR have a Domain joined and workplace joined device + MFA

From internal networks:

All devices coming from internal network are excluded from the MFA and Compliancy requirements. Just username/password or SSO is enough.

*Example of complaint mobile device:

– Minimal OS level set (for example Android version 7.0)
– Encrypted OS
– Is enrolled in Intune
– Has a password complexity of 6 and is not jail broken.

If you have a 3rd party solution for malware based protection such as Lookout and Sky secure, you can use this to check for malware on your mobile device. If it reaches certain levels low, medium or high, it will change the state of your mobile to “not complaint”. For these 3rd party solutions you need separate licenses.

Create a new Conditional Access policy:

Start with blocking other users and groups or create policies for those as well. If a user doesn’t have any Conditional Access policies it will be granted access by default. The same goes for compliancy policies. If no compliancy policies are targeted to a device/user it will mark it as complaint.

I use the name “Salesforce Marketing Secure Mobile” and select the Dynamic Group “GG_O365_license_marketing2” which is a dynamic group existing of users which have the Marketing title.

If needed you can exclude any security groups/users. All my other users are in a separate group “Others” and set the policy for Salesforce to “Deny Access” always.

Select the cloud app you want to protect. Azure Application Proxy connected apps will show here as well. You can select multiple apps within one policy, select all cloud apps or select just one app.

In my case I just choose the Salesforce App.

Select the device platforms for which these policies will apply. At start I will select all platforms to be sure no app is left behind which doesn’t respect the policies.

I will configure the Internal IPs to be excluded from the requirement for these rules as all my internally located devices are on trusted networks and have other security mechanisms. This is especially good for VDI, Citrix and domain joined devices which are not workplace joined with Azure AD. All my mobile devices cannot connect to my internal networks.

All IPs you add in the trusted locations are not targeted by the policies which means that they don’t have to do MFA, not require to be enrolled and complaint nor have to be domain joined + Azure workplace joined. So, because you skip all these checks make sure to only add public IPs which are yours and on protected networks. It is also possible to create a new policy for internal networks.

You can configure Trusted locations with public IPs and IP ranges by clicking on “Configure all trusted locations”.

Select that the policy is required for both the Browser and or Mobile and Desktop applications. Note that you need to block legacy authentication on you ADFS server as Legacy auth is not working with these Conditional Access policies.

Important Note: If a mobile app isn’t supporting the ADAL library with all the functionalities such as Multifactor Auth and Device claims/Intune enrollment certificates, it can result in a failed login with the app. This means only access is available via the browser.

The specific ADAL library is a Microsoft implementation for Modern authentication with Azure AD. So if you implement ADAL for your LOB application this will not be an issue. The 3rd party apps will mostly develop their own Modern Auth into the app so that the app is capable to login to multiple Identity Providers.

In my case during testing if I activated the policy and includes “all the mobile platforms + unsupported” and selected the “Mobile apps and desktops” option the Salesforce app on Android was not able to authenticate and login. Expecting that this has to do with the app not supporting pkey or client tls which is a requirement for device based ca. This is the process where the app/browser will look into the certificate store on the device send the Intune device certificate up to Azure to be able to identify the device and check if it is complaint. I hope to get an answer on this and will update the blog post when if have more information.

In that case, you have two options. Leaving the policy in place and know that the app is not working or make the policy less strict and give the Salesforce app access without the device complaint security controls. Third option would be to contact Salesforce to include the Azure AD conditional Access functionalities within the app.

For the Grant access policies you need to check if you can create one policy for all your requirements or create a separate policy to meet all the requirements for different platforms.

In my case the requirement is to have an Enrolled and complaint device and require MFA if you are not on the internal network. Windows devices can be enrolled as well.

As we want to use MFA + complaint devices we cannot select the “Require domain joined device” at the same time. This would block mobile devices such as android and IOS as they cannot be domain joined. Normally for Windows devices you will also choose to enroll in Intune or do domain join + workplace join instead of doing both (if that is even supported). I will create a separate policy for the requirements for our domain joined Windows devices. This will also allow users with domain joined + workplace joined devices to connect from external network with an MFA enforcement.

If you select the “Require one of the selected controls” and select MFA and Complaint device my experience is that the MFA will be used first. Even I had a complaint device it will still ask me to do the MFA instead of first trying to give my enrolled certificate to login and skip the MFA.

Make sure you enable to policy and select Create.

Summary:

Conditional Access can be used with all apps which support Azure AD/Azure application proxy and more options are coming in the future. One side note is that all (mobile) apps need to support Modern Auth + pkey auth/client tls, otherwise they would fail to work with device based conditional access policies or the policy requirement needs to be adjusted to the lowest supporting app which will result in lower security.

When will my tenant be migrated to the new portal?

The “old” current portal is Silverlight and it’s not very browser/user friendly. When you will be migrated to the new portal depends on how you configured Intune.

If for example, you are using Intune groups with exceptions this cannot be migrated directly to Azure AD groups. The Intune groups itself will be migrated totally to Azure AD groups which work the same as traditional Security groups. And new Dynamic groups are available in the Azure Ibiza portal.

Most important changes you need to be prepared of before migration can start:

  • The Ungrouped Users and Ungrouped Devices Intune groups won’t be migrated.
  • The option to Exclude specific members from a group that currently exists in the Intune console does not exist in the Azure portal
  • The All Exchange ActiveSync Managed Devices group that’s built-in to the Intune console will not be migrated to Azure AD
  • You won’t be able to filter reports by groups in the classic Intune console.

Tenants which are prepared are currently (or in the near future) on the migration list. If you are using the described features above, you will be expected to be delayed after April 2017.

More information on how to prepare for the new Portal with lots of new features : https://docs.microsoft.com/en-us/intune/deploy-use/migrating-groups-to-azure-active-directory

 

Leave a Reply