What are access controls in Azure Active Directory conditional access?
With Azure Active Directory (Azure AD) conditional access, you can control how authorized users access your cloud apps. In a conditional access policy, you define the response ("do this") to the reason for triggering your policy ("when this happens").
In the context of conditional access,
"When this happens" is called conditions
"Then do this" is called access controls
The combination of a condition statement with your controls represents a conditional access policy.
Each control is either a requirement that must be fulfilled by the person or system signing in, or a restriction on what the user can do after signing in.
There are two types of controls:
Grant controls - To gate access
Session controls - To restrict access within a session
This topic explains the various controls that are available in Azure AD conditional access.
With grant controls, you can either block access altogether or allow access with additional requirements by selecting the desired controls. For multiple controls, you can require:
- All selected controls to be fulfilled (AND)
- One selected control to be fulfilled (OR)
You can use this control to require multi-factor authentication to access the specified cloud app. This control supports the following multi-factor providers:
Azure Multi-Factor Authentication
An on-premises multi-factor authentication provider, combined with Active Directory Federation Services (AD FS).
Using multi-factor authentication helps protect resources from being accessed by an unauthorized user who might have gained access to the primary credentials of a valid user.
You can configure conditional access policies that are device-based. The objective of a device-based conditional access policy is to only grant access to the selected cloud apps from managed devices. Requiring a device to be marked as compliant is one option you have to limit access to managed devices. A device can be marked as compliant by Intune (for any device OS) or by your third-party MDM system for Windows 10 devices. Third-party MDM systems for device OS types other than Windows 10 are not supported.
Your device needs to be registered to Azure AD before it can be marked as compliant. To register a device, you have three options:
For more information, see how to require managed devices for cloud app access with conditional access.
Hybrid Azure AD joined device
Requiring a Hybrid Azure AD joined device is another option you have to configure device-based conditional access policies. This requirement refers to Windows desktops, laptops, and enterprise tablets that are joined to an on-premises Active Directory. If this option is selected, your conditional access policy grants access to access attempts made with devices that are joined to your on-premises Active Directory and your Azure Active Directory.
For more information, see set up Azure Active Directory device-based conditional access policies.
Approved client app
Because your employees use mobile devices for both personal and work tasks, you might want to have the ability to protect company data accessed using devices even in the case where they are not managed by you. You can use Intune app protection policies to help protect your company’s data independent of any mobile-device management (MDM) solution.
With approved client apps, you can require a client app that attempts to access your cloud apps to support Intune app protection policies. For example, you can restrict access to Exchange Online to the Outlook app. A conditional access policy that requires approved client apps is also known as app-based conditional access policy. For a list of supported approved client apps, see approved client app requirement.
Custom controls (preview)
You can create custom controls in Conditional Access that redirect your users to a compatible service to satisfy further requirements outside of Azure Active Directory. This allows you to use certain external multi-factor authentication and verification providers to enforce Conditional Access rules, or to build your own custom service. To satisfy this control, a user’s browser is redirected to the external service, performs any required authentication or validation activities, and is then redirected back to Azure Active Directory. If the user was successfully authenticated or validated, the user continues in the Conditional Access flow.
Custom controls are a capability of the Azure Active Directory Premium P1 edition. When using custom controls, your users are redirected to a compatible service to satisfy further requirements outside of Azure Active Directory. To satisfy this control, a user’s browser is redirected to the external service, performs any required authentication or validation activities, and is then redirected back to Azure Active Directory. Azure Active Directory verifies the response and, if the user was successfully authenticated or validated, the user continues in the conditional access flow.
These controls allow the use of certain external or custom services as conditional access controls, and generally extend the capabilities of Conditional Access.
Providers currently offering a compatible service include:
For more information on those services, contact the providers directly.
Creating custom controls
To create a custom control, you should first contact the provider that you wish to utilize. Each non-Microsoft provider has its own process and requirements to sign up, subscribe, or otherwise become a part of the service, and to indicate that you wish to integrate with conditional access. At that point, the provider will provide you with a block of data in JSON format. This data allows the provider and conditional access to work together for your tenant, creates the new control and defines how conditional access can tell if your users have successfully performed verification with the provider.
Copy the JSON data and then paste it into the related textbox. Do not make any changes to the JSON unless you explicitly understand the change you’re making. Making any change could break the connection between the provider and Microsoft and potentially lock you and your users out of your accounts.
The option to create a custom control is in the Manage section of the Conditional access page.
Clicking New custom control, opens a blade with a textbox for the JSON data of your control.
Deleting custom controls
To delete a custom control, you must first ensure that it isn’t being used in any conditional access policy. Once complete:
Go to the Custom controls list
Editing custom controls
To edit a custom control, you must delete the current control and create a new control with the updated information.
Session controls enable limited experience within a cloud app. The session controls are enforced by cloud apps and rely on additional information provided by Azure AD to the app about the session.
Use app enforced restrictions
You can use this control to require Azure AD to pass device information to the selected cloud apps. The device information enables the cloud apps to know whether a connection is initiated from a compliant or domain-joined device. This control only supports SharePoint Online and Exchange Online as selected cloud apps. When selected, the cloud app uses the device information to provide users, depending on the device state, with a limited or full experience.
To learn more, see:
If you want to know how to configure a conditional access policy, see Require MFA for specific apps with Azure Active Directory conditional access.
If you are ready to configure conditional access policies for your environment, see the best practices for conditional access in Azure Active Directory.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.