Understanding Azure Active Directory Conditional Access

Posted on by Russell Smith in Cloud Computing

12404760 – electric background

In this Ask the Admin, I’ll look at why user authentication isn’t enough in a cloud-first, mobile-first world and how Azure AD conditional access works with cloud apps and on-premises Windows Server Active Directory.

Regardless of whether users are accessing Office 365 or line-of-business corporate apps, by default users can register devices with Azure Active Directory (AAD Device Registration), which gives them the convenience of being able to access cloud resources by just logging in to Windows. There’s no restriction on which devices they can use or how those devices are configured, which could pose a significant security risk if a device is compromised.

You can stop users from joining devices to AAD, either by blocking the feature entirely or whitelisting specific users. Device Registration can be blocked or enabled but it’s an all or nothing setting. And Device Registration can only be blocked if you haven’t configured Intune or enrollment with a third-party Mobile Device Management (MDM) service.

For more information on the difference between AAD Join and AAD Device Registration, see 7 Ways to Authenticate Users and Devices in Windows 10 on Petri.

Conditional Access Policy

Conditional access gives organizations that have an Azure AD Premium subscription the ability to further secure their data by ensuring that users access resources (i.e. cloud apps) only from devices that meet certain standards.

Conditions

When configuring a conditional access policy, you need to select at least one cloud app and at least one user or group. Optionally, you can define one or more conditions that when met, trigger access controls. There are four categories that can be used to control access:

  • Device platforms
  • Locations
  • Client apps (preview)
  • Device state (preview)

Device platforms allows organizations to decide which operating systems can be used to access cloud resources. For instance, you can allow all OSes, including those that are unsupported, or include or exclude Android, iOS, Windows Phone, Windows, and macOS.

Locations can be used to block or allow access based on IP address. You can configure your own trusted locations with custom IP address ranges. Location policy is evaluated when a user signs in to an application. And if the mobile or desktop app uses modern authentication, when a new access token is token is generated, which is every hour by default. Apps that don’t use modern authentication request a new access token at different frequencies, so users could change their physical location and be granted access for more than an hour after the initial evaluation. The same applies to web apps.

A conditional access policy in Azure Active Directory (Image Credit: Russell Smith)
A conditional access policy in Azure Active Directory (Image Credit: Russell Smith)

Client app conditions allow you to restrict access from browsers, or mobile apps and desktop clients. For example, you could permit access from only mobile apps and desktop clients that support modern authentication.

The most interesting set of conditions are Device state. For instance, if you configure a policy to block access, you can exclude devices that are joined to both Windows Server Active Directory and Azure AD (Hybrid Join), and devices that are marked ‘Intune compliant’. Intune reports the compliance state of enrolled devices to AAD.

Access Controls

Access controls are applied when conditions are met. You can either block access or select additional requirements that need to be met, such as ensuring devices are joined to both Windows Server AD and Azure AD.

There’s also Microsoft Cloud App Security Conditional Access App Control (Session control) for granular control of what users can do in a given app. Conditional Access App Control requires a Microsoft Cloud App Security subscription. For more information, see Microsoft’s website here.

Conditional Access and Intune

Azure AD conditional access comes into its own when used with Intune. While the ability to control where users can log in from and the apps they use is welcome, the real power is in ensuring that devices are compliant with Intune policies.

You might not want users logging in from China if you know that’s not a location where employees are based or travel to but it’s even better if you can determine exactly which devices are being used to access corporate resources and whether they are secure. In a BYOD scenario, Intune and AAD conditional access together is the best way to secure access to your organization’s data.

 

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register