Azure AD Conditional Access Policies have some of the most powerful capabilities within Azure Active Directory (Premium P1 feature). And you can scope these policies to meet just about any scenario required including (or excluding) users/groups, apps, and other conditions such as risk, device platform and state, locations, and client application (Browser, Mobile, Desktop).
Azure AD Conditional Access is widely used and highly recommended to enforce the use of Multi-Factor Authentication because of the granular assignment controls available. However, there are many additional access controls available. While enforcing MFA is a great way to significantly increase the overall security posture within your environment with strong user identity authentication, it is only applied to the user identity and a single piece of the Zero Trust model.
Organizations should also consider device identities as well. In Azure AD, a device identity can be either an Azure AD Registered, Azure AD Joined, or Hybrid Azure AD Joined device. With Azure AD Conditional Access, you can enforce the use of a trusted device identity. The device is the second piece of the typical first pillar in the Zero Trust model, along with the user identities.
In addition, Conditional Access can extend protection to mobile device usage with several application access controls for iOS and Android devices to protect data and prevent Shadow IT usage.
Currently, there are 8 access control grant options. You can choose one or more and enforce the use of either a single option or all selected options. These include:
- Block Access
- Require multi-factor Authentication
- Require device to be marked as compliant
- Require Hybrid Azure AD Joined device
- Require approved client app
- Require app protection policy
Blocks access based on Conditional Access Policy Assignment settings. Here are several items to consider before enabling a Block Access policy:
- !!!CAUTION!!! A Block Access policy that applies to all users and apps can lead to organizations being locked out of the Azure portal.
- I can personally attest that this works as advertised. So, there is no need for any organization to prove this notion.
- Always have at least a single exclusion account, such as an emergency administrative break glass account applied to any block access policy
- Use testing tools first, such as Conditional Access report-only modeand What If tool
- Policies apply to both user and administrative access. For example: Blocking Access to Exchange Online will also prevent administrators from accessing the Exchange Online Admin Center or Exchange Online PowerShell.
- When multiple policies exist, block access trumps all other policies
Require multi-factor Authentication
Enforces Azure MFA. This option is not meant for the use of any 3rd party MFA provider. Use Custom controls for any MFA other than Azure MFA
Require device to be marked as compliant
This is one of two options for Device-based Conditional Access policies.
Requires Microsoft Endpoint Manager (aka Intune). Device must be compliant. If the device is non-compliant, the user will be prompted to bring the device under compliance before access is granted.
Do not implement this control for any user that has not enrolled their devices yet. This will block their access, potentially including the Intune Portal to enroll a device. This policy can also block administrative access to Azure AD and/or Intune.
Users can use the Company Portal app to view reasons for non-compliance.
Require Hybrid Azure AD Joined device
The second option for Device-based conditional access. Devices must be Hybrid Azure AD joined. A hybrid Azure AD Joined device is simply a device that is domain-joined and registered to Azure AD with a valid Azure AD user. This control can be used to ensure only domain-joined PCs access Azure AD apps and data.
If you have not yet implemented Microsoft Endpoint Manager and compliance policies, this option does minimally suffice the classification of a trusted device in the Zero Trust model. That is assuming appropriate security controls and protection is applied appropriately to all corporate devices.
If you have not implemented Hybrid Azure AD Join yet, do not use this control as it can block access to all users and administrators.
Require approved client app
This control only applies to iOS and Android mobile devices. This option does not support assignment conditions of Browser and overrides the client app condition Mobile apps and desktop client apps. Each device must use these approved client applications. Also requires use of broker app (Microsoft Authenticator for iOS or Microsoft Company Portal for Android) and devices must register with Azure AD first. If not installed, user will be prompted to install. This option supports the addition of Intune Mobile Application Management.
The primary use of this control is to enforce the use of trusted/supported applications, such as Outlook, to combat Shadow IT, but also to implement supported application protect policies to ensure data protection tactics (DLP, Encryption, etc) can be applied.
Require app protection policy
Currently in preview as of this writing. This control has the same requirements as the previous control, Require approved client apps. The use of Require approved client app was intended to be used in concurrent with an application protection policy; however, was not enforced. Require app protection policy control now requires the use of an Intune application protection policy before application can be granted. There is minimal application support in preview including:
- Microsoft Cortana
- Microsoft OneDrive
- Microsoft Outlook
- Microsoft Planner
Custom controls are used to redirect users to a compatible external service to satisfy authentication requirements. This can include a 3rd Party MFA provider such as Duo or RSA. However, custom controls have never left a preview state. Microsoft announced that these controls are soon to be replaced with more intuitive, seamless solution to work alongside other CA features.
As you can see, there is a wide variety of controls to implement to ensure secure access to your Azure AD environment. Any application, including non-Microsoft apps, that is integrated into Azure AD can have a conditional access policy applied to it. If an organization does not already have MFA enforced, that should be the immediate focus to implement organization wide. However, if you do already have one or more conditional access policies enforcing MFA, consider extending your requirements to continue the implementation of a Zero Trust model to both Microsoft and non-Microsoft applications.
The next article will review the other type of access controls, session controls. Enabling Technologies can help you properly prepare for moving to the cloud based on Microsoft Best Practices and utilizing a secure and productive environment. You can check out more in the Security section of our website.