Azure Conditional Access policy is one of the most important tools or services in the Azure Active directory. I’m describing that services as the following:

When you are using Azure Active Directory and its services, keep in mind that every user can log in whenever and wherever. It’s highly important to secure the login with enforcements and to protect your organization’s assets.

Azure Conditional Access is the perfect tool to archive the requirements from above. It’s included in the Azure Active Directory Premium P2 license and that’s one reason why I recommend that license to all of my customers.

How does Azure Conditional Access working? Think about the tons of signals which are available in the Azure Active directory.


  • Which user is login
  • From where the user log-in
  • From which device the user log-in
  • Which application want the user to open
  • and much more

That’s the base from Conditional Access policies, and based on those signals you can define conditions and enforcements. Here an excellent picture from Microsoft about the process:

Conceptual Conditional signal plus decision to get enforcement

Okay, what are common signals? Signals aren’t based only on user sign-ins. The current signal types are:

  • User or group membership
  • IP Location information
  • User device
  • Application (built-in or custom)
  • Real-time and calculated risk detection (requires Azure Active Directory P2)
  • Microsoft Cloud App Security

Okay, now we know the options of signals that we have, it’s time to make a decision. There are two decisions available but the second one has many sub-options:

  • Block access (most restrictive way)
  • Grant access (least restrictive way) but with the following sub-options:
    • Require multi-factor authentication
    • Require device to be marked as compliant (Intune managed device)
    • Require Hybrid Azure AD joined device (AD and AAD joined)
    • Require approved client app (Apps approved by Intune app protect policies)
    • Require app protection policy (preview) (Apps protected by Intune app protect policies)
    • Require password change
    • Require terms of use

At the end you have the decision to:

  • Require all the selected controls
  • Require one of the selected controls

Optional, you have the ability to define the user session settings. For me, that option isn’t optional, it’s highly important and many of my conditional access policies are using that section. The options that you have here are:

  • Use app enforced restrictions (Currently only Office 365, Exchange Online, and SharePoint Online are supported)
  • Use Conditional Access App Control
  • Sign-in frequency (control the frequency in Days or hours)
  • Persistent browser session (what happens when the customer closes and reopens the session?)

Conclusion about the options above: you have many options, so think about your requirements and what you want to archive. Here another cool picture to describe the decision process:

Conceptual Conditional Access process flow

Okay, now let’s talk about troubleshooting and more. When I’m starting with a new Conditional Access policy, I always think about the requirements and what I want to archive.

When I‘m implementing a new Conditional Access policy, I always follow the following principles:

  • Always start with “Report only” policies
  • Always define exclude groups
  • Using the „WhatIf“ functionality to see what happens when…
  • Starting with a small (key user) group
  • Document the current configuration and what I want to archive
  • BACKUP the policies!

In my YouTube video I describe the Azure Conditional Access policies in a short theory session and also demonstrate a default policy (implement MFA for all users outside the company network). So take a Look and reuse the Demo.

In my requirements, and my YouTube video, I‘m describing the backup options. Microsoft have developed a really cool solution with much more functionality to archive that. It includes the following processes:


You can find the source code and installation steps in the following GitHub repo.

A really cool solution with a huge amount of functionality, but in some situations, it‘s only required to have a backup solution only on place. For exactly that requirement, I‘m currently developing a solution based on the following PaaS services:

  • Azure Web App (.Net 4.8)
  • Azure LogicApp (Consumption mode)
  • Azure Storage Table
  • Azure KeyVault
  • Azure LogAnalytics
  • Azure Monitor

The backup (daily) and the on-change as well the restore LogicApps are ready (without monitoring) at the moment, now it’s time to develop a simple web interface to see

  • The backup state (the last backup, the failed backup)
  • A simple restore option

When the interface is done, I‘ll implement a backup solution including notification options. When everything is in place, I‘ll update that blog post.

At the end, here a short architecture overview about my backup solution.