Conditional Access as an access control mechanism
In the previous article, I mentioned the transition to Intune Standalone, which allowed us to make more use of the capabilities of Azure Active Directory, namely, to work with Conditional Access. In this I will tell you more about how this can be done.
What it is?
Conditional Access (CA) is a mechanism for checking each connection process to the system based on the configured script and the decision that sets what to do with this connection. And it can be disabled, allowed without conditions, or allowed with conditions. It is a component of Azure AD.
This scenario is described by the following settings:
Assignments - in which cases the script should work.
Access controls - what to do.
The Assignments section contains:
- Users and groups - which users are subject to the policy. This can be all users in Azure AD or specific groups / users. Separately, you can specify exceptions. You can apply the policy to all users except for a specific group.
- Cloud apps - scripts can be applied to any application registered in Azure AD. That is, you are not limited to working only with Office 365 applications.
- Conditions - additional conditions.
- Sign-in risk - the possibility of using the authorization risk assessment mechanism. Estimated from where, at what time, with which client, how much this behavior is usually, etc. Azure AD Premium 2 license required.
- Device platforms - it is possible to specify to which platform the policy will be applied. For example, creating a policy for mobile clients only or for Windows machines only.
- Locations - implies network locations. You can use the list of trusted IP addresses.
- Client apps (preview) - evaluates the type of client. It is possible to use to create a policy only for the browser or EAS (Exchange Active Sync). For those who want to close the use of OWA on mobile devices, but leave the option for desktop computers.
- Device state (preview) - allows you to exclude devices in a certain status.
Next, you need to configure what exactly the policy will do or require.
There are two sections for this:
Grant - this is where the script is configured: blocking access or requiring additional security measures.
Session - control in the session itself. While it is possible to use only with Exchange Online and Sharepoint Online. More information here .
Now let's look at some usage scenarios.
Scenario 1: Access Azure AD applications only on Intune-managed mobile devices.
Suppose we need to restrict access to applications registered in Azure AD and give it only to devices that are controlled by Intune. And it should be applicable for all devices.
We choose to apply the policy to all users.
Next, select all applications.
IMPORTANT: The Azure Management Portal (portal.azure.com) is also regarded as an application, so be careful. There is a bike - if you create a policy for all users and all applications that will block any connections, then no one will ever fall into your tenant and even Microsoft support will not help you.
Now we need to configure the policy to apply only to mobile devices. To do this, go to Device Platforms and select mobile OS (iOS, Android, Windows Phone).
We have selected all the necessary conditions to apply the policy, now we choose the condition for allowing the connection. In this case, the necessary option is to require the device to comply with the security policies in the Intune (Compliance Policy). The device status is taken from Intune.
After creating and applying the policy, users with devices managed by Intune will continue to use the applications. Those who use devices not connected to Intune will see a message prompting you to register the device.
Scenario 2. Access to the corporate portal only from corporate computers.
You must configure synchronization between Active Directory and Azure Active Directory. Thus, computers from AD will exist as Hybrid Azure AD joined. The internal portal must be registered with Azure AD. You can even configure SSO.
Now it's up to the policy that will be applied to the right users and require connecting only with Hybrid Joined devices when connecting to the specified portal / application. It only works out of the box with IE and Edge. Chrome will require an extension.
And if something breaks?
At some point in time, you can find situations where the user cannot log in to the application and you don’t quite understand which policy is to blame.
In this case, Sign-in logs in Azure AD will help with filtering by policy enforcement status.
In the details of each event, you can see what policy has worked and why.
Conclusions
Conditional Access allows the flexibility to differentiate access to applications and services. The conditions and usage scenarios can be infinite. Best of all, this service is revealed with Microsoft services. For example, it can be integrated with the Azure Application Proxy to limit access to internal resources or integrate with endpoint protection when closing access to a corporate network.
What it is?
Conditional Access (CA) is a mechanism for checking each connection process to the system based on the configured script and the decision that sets what to do with this connection. And it can be disabled, allowed without conditions, or allowed with conditions. It is a component of Azure AD.
This scenario is described by the following settings:
Assignments - in which cases the script should work.
Access controls - what to do.
The Assignments section contains:
- Users and groups - which users are subject to the policy. This can be all users in Azure AD or specific groups / users. Separately, you can specify exceptions. You can apply the policy to all users except for a specific group.
- Cloud apps - scripts can be applied to any application registered in Azure AD. That is, you are not limited to working only with Office 365 applications.
- Conditions - additional conditions.
- Sign-in risk - the possibility of using the authorization risk assessment mechanism. Estimated from where, at what time, with which client, how much this behavior is usually, etc. Azure AD Premium 2 license required.
- Device platforms - it is possible to specify to which platform the policy will be applied. For example, creating a policy for mobile clients only or for Windows machines only.
- Locations - implies network locations. You can use the list of trusted IP addresses.
- Client apps (preview) - evaluates the type of client. It is possible to use to create a policy only for the browser or EAS (Exchange Active Sync). For those who want to close the use of OWA on mobile devices, but leave the option for desktop computers.
- Device state (preview) - allows you to exclude devices in a certain status.
Next, you need to configure what exactly the policy will do or require.
There are two sections for this:
Grant - this is where the script is configured: blocking access or requiring additional security measures.
Session - control in the session itself. While it is possible to use only with Exchange Online and Sharepoint Online. More information here .
Now let's look at some usage scenarios.
Scenario 1: Access Azure AD applications only on Intune-managed mobile devices.
Suppose we need to restrict access to applications registered in Azure AD and give it only to devices that are controlled by Intune. And it should be applicable for all devices.
We choose to apply the policy to all users.
Next, select all applications.
IMPORTANT: The Azure Management Portal (portal.azure.com) is also regarded as an application, so be careful. There is a bike - if you create a policy for all users and all applications that will block any connections, then no one will ever fall into your tenant and even Microsoft support will not help you.
Now we need to configure the policy to apply only to mobile devices. To do this, go to Device Platforms and select mobile OS (iOS, Android, Windows Phone).
We have selected all the necessary conditions to apply the policy, now we choose the condition for allowing the connection. In this case, the necessary option is to require the device to comply with the security policies in the Intune (Compliance Policy). The device status is taken from Intune.
After creating and applying the policy, users with devices managed by Intune will continue to use the applications. Those who use devices not connected to Intune will see a message prompting you to register the device.
Scenario 2. Access to the corporate portal only from corporate computers.
You must configure synchronization between Active Directory and Azure Active Directory. Thus, computers from AD will exist as Hybrid Azure AD joined. The internal portal must be registered with Azure AD. You can even configure SSO.
Now it's up to the policy that will be applied to the right users and require connecting only with Hybrid Joined devices when connecting to the specified portal / application. It only works out of the box with IE and Edge. Chrome will require an extension.
And if something breaks?
At some point in time, you can find situations where the user cannot log in to the application and you don’t quite understand which policy is to blame.
In this case, Sign-in logs in Azure AD will help with filtering by policy enforcement status.
In the details of each event, you can see what policy has worked and why.
Conclusions
Conditional Access allows the flexibility to differentiate access to applications and services. The conditions and usage scenarios can be infinite. Best of all, this service is revealed with Microsoft services. For example, it can be integrated with the Azure Application Proxy to limit access to internal resources or integrate with endpoint protection when closing access to a corporate network.