Identity protection describes concepts of securing identities for authN- (authentication) needs. Common identity provider offer federation or SSO (single sing-on) as known strategies. But all this is so much more, think of ways to secure this work flows with different signals that could be processed and lead into conditions or requirements, such as MFA (multi factor authentication) that are necessary to access company resources. Well, Microsoft calls that product conditional access.

Source: Microsoft

Conditional access operates with all the other identity protection tools that Microsoft offers and gathers information to process the login attempt. It includes access policies that are configurable for a variety of operations.

What can you protect?

In terms of information technology security, corporate resources or easier said data is always what needs to be protected. As cloud-native product, conditional access' job is to protect authentication for SAML (security assertion markup language) integrated cloud apps that use SSO and AzureAD as identity provider and usually works with oAuth2 (for authZ) and OpenID connect (for authN). In AzureAD we call these apps enterprise applications.

How do you protect?

Each login process provides some information about the client request we can work with. In conditional access these infos are the following signals:

• User risk (intelligence from AzureAD Identity Protection)
• Sign-in risk (intelligence from AzureAD Identity Protection)
• Device Platform (OS)
• Location (IP ranges/country)
• Client apps (Browser, mobile apps and so on)
• Device state (HAADJ, device marked as compliant from Intune)

Finally: access controls

Based on the signals collected, the next step is now to define the access control. We have three options:

• Block access
• Allow access
• Allow access, require
  • MFA
  • device to be marked as compliant
  • Hybrid Azure AD joined device
  • approved client app (see list of Microsoft approved client apps)
  • app protection policy (from Intune)
  • password change
    (referring to these settings you can require one or all of the selected controls)

Session control

Through conditional access, we also have the great opportunity to take control even at the session level.

• Use app enforced restrictions This only works with Sharepoint Online and Exchange Online and can create a limited experience within the apps.
• Use conditional access app control uses Microsoft Cloud App security where you can protect data with Conditional Access App Control by applying access and session controls.
• Sign-in frequency Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. You can set this from a few hours up to 365 days.
• Persistent browser session A persistent browser session allows users to remain signed in after closing and reopening their browser window. The option "stay signed-in" will also be skipped.

Some more thoughts from the field

Now that we are familiar with the theoretical material, I want to share some personal thoughts and my experience using this technology from the field.

The first thing to consider is which specific application groups are present and how they should be protected. For example: all users, personal user accounts (which only one employee has access to), general users and privileged accounts (admin roles). To create this groups I would recommend dynamic user groups in AzureAD based on user attributes or nested groups.

Creating a concept is my prioritized way to later create an access policy. I try to write down what should be enforced with which requirements and what the resources are. In my experience, almost every conceivable security concept can be implemented from the existing signals. Also use different access controls such as block access and allow access with requirements. To be honest, I like to go for all cloud apps, as it's just the simplest way and in the end each login attempt will be equal and secure. Although particular sensitive enterprise applications (if available) often need more strict access policies. This is the point at which the CISO or the business must decide which security policies to enforce.

Finally if everything is written down and the management approves everything it comes down to set this policies live. I tend to use pilot groups in advance to ensure correct behavior and maybe detect problems users encounter. Later on in a state where most of the difficulties are known and resolved, you are ready to switch the group to company.

One more important thing: always exclude your breaking glass admin from the policies!

Next

Here are two more recommendable posts of me on Conditional Access:

• Want to know which Conditional Access policies are a must-have? Read Conditional Access examples
• Step up your Conditional Access game. Some field thoughts from my experience.