Understanding Azure Active Directory Conditional Access
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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
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.
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
- 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.
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 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.