Conditional Access Policies
The course is part of this learning path
This course covers conditional access policies in Azure. You’ll learn what Conditional Access is, why you use it, and what it offers. We’ll then explore how to build a Conditional Access policy, and you'll see a demonstration of how to create a conditional access policy.
- Understand the fundamentals of conditional access policies
- Learn how to build a conditional access policy
This course is intended for anyone who wishes to learn about conditional access policies.
To get the most out of this course, you should already have some experience with Azure AD.
Hello and welcome to Conditional Access.
Conditional Access is an Azure AD feature that allows you to decide who can and can’t access data or other assets, based on conditions that you specify. It’s an added layer of security. Conditional Access policies, which are created and managed in Azure AD, look at things like user, location, device, application, and risk in order to automate access to apps and data.
For example, you might configure a Conditional Access policy so that if a user belongs to a particular group, they're required to provide multifactor authentication to sign into a specific application.
The image on your screen shows how Conditional Access policies work.
Conditional Access relies on several signals to control who can access what data, and from where.
Conditional Access Signals include User or Group Membership, Named location information, Device, Application, Real-time sign-in risk detection, Cloud apps or actions, and User risk.
The User or group membership signal allows the admin to create policies that target specific users and groups. This provides fine-grained control over access to apps and data.
Named location information can be created using IP address ranges and used when making policy decisions. Admins can even block or allow traffic from an entire country's IP range.
The Device signal allows the admin to create a policy that targets users with specific devices or with devices in a specific state.
Using the Application signal, admins can ensure that users who are trying to access specific applications will trigger different Conditional Access policies.
Real-time sign-in risk detection allows a Conditional Access policy to identify risky sign-in behavior, and to force users to perform password changes or multifactor authentication. If a user fails to take one of these actions, the user can be blocked from access until an admin investigates and takes action.
Using the Cloud apps or actions signal, an admin can include or exclude certain cloud applications or user actions that will be subject to a policy.
User risk is available to customers that have access to Identity Protection. User risk refers to the probability that a particular account is compromised. It can be evaluated as part of a Conditional Access policy.
So, the signals I just mentioned determine who or what gets targeted. Access controls determine what happens when the conditions of a Conditional Access policy are met. They determine whether or not access should be granted, or if extra verification should be required. For example, a policy might reach a decision to Block access to a resource, or it may Grant access.
Depending on how a policy is configured, it might also require addition conditions to be met before granting access. It might, for example, require a user to complete multifactor authentication, or it might require a device to be marked as compliant before access is granted. You can even configure a policy to ensure a user is using a hybrid Azure AD joined device before granting access to apps and data.
I should mention that Conditional Access is a feature that’s only available in the paid editions of Azure AD.
So, the key takeaway here is that Conditional Access is an Azure AD feature that allows you to decide who can and can’t access data or other assets, based on conditions that you specify. Conditional Access policies, which are created and managed in Azure AD, rely on several signals to control who can access what data, and from where.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.