Azure AD Conditional access rules, how I design the secure way.

Azure Active Directory with Conditional Access Rules have been available for a several years, and every customer have activated some kind of rule during these years. We see multiple ways customer have started this journey, and if not done right you might not be as secure as you thought.

And recent years, conditional access have been developed with even deeper set of rules. Even to the point where IT Pros and consultants can struggle to grasp what to enable.

The most common setup of rules

The most common setup of rules we encounter is quite a jungle to navigate, because it has been developed over years without thinking ahead of the one rule you are tasked to implement.

The result makes is hard to understand which rules apply to who and which application. Especially when someone is blocked, but should have access.

It is also difficult to continue developing your rules, because you have to examine all previous in order to understand if your new rule will intertwine with previous rules.

The difficulty multiples if you lose your colleague responsible for current rules setup, and someone new takes over the responsibility.

The secure setup of rules

The more secure and better way to implement conditional access rules, is to agree on a set of common conditions for each user type aka personas (standard, guest and privileged).

These three rules apply to all applications, which makes it Zero Trust, and uses dynamic groups or built-in targets (guests, privileged roles) applied in the rules. This prevents nobody from being excluded by accident or out of convenience without manually exclude themselves from the rule they belong.

If someone exclude themselves it will be logged under audits, and traceable. It can also trigger an alert to monitor if someone exclude themselves from these rules.

A deeper dive into details will follow in a later article, but download this spreadsheet to make a visual documentation of your rules from my github repo.

Zero Trust

A key to understand conditional access rules is to understand Zero Trust, because when we set conditions we enforce it every time. This makes you verify your identity and meet the conditions enforced to your persona every time. We don’t automatically trust your sign-in attempt, just because you come from a specific office, or because you have been signed in before.

Never Trust - Always verify.

So when we design the standard rules, we always want them to apply and not make any exceptions.

Dealing with exceptions

We will always have exceptions from these standard rules, so we need to handle them in way we can effectively troubleshoot and scale to fit our dynamic organizations. So we introduce targeted policies, that for some groups will be exceptions from the standard policies.

There is three parts to address when making exceptions:

• Who/which standard rule are we making an exception from?
• Which applications are we making an exception for?
• Who are the exceptions applying to?

We can effectively understand each exception rule from the naming convention, but remember the standard rules should apply as long as it is technical possible. The standard rules should be generally agreed upon as the benchmark for the default security each user type/persona should apply.

Exceptions are only made when technically necessary or you require even stronger security due to the data kept in an application, or the severe risk it can have should you become compromised.

The elephant in the room

When I can’t use MFA? When this happens, mostly it is temporary access to get a task done. It isn’t necessary something we see as illegal, but it should follow a process to be governed when we need to make exceptions. If your already running with Change Advisory Board (CAB) it should be part of the presentation and assessment in the CAB meetings. Or at least run it by a colleague, before you allow the exception and follow-up to close the exception when the task is done.

Templates for rules

Microsoft have made a wizard to deploy different rules, and have them categorized into different type of categories. Currently in preview, but announced general available and documented here.

But it creates multiple rules for each condition you want to require. Often we want to protect with bought MFA and Compliant device status, but this template will create two rules for this. It is only necessary to have one rule, and when sign-in fails it will state the cause of failure for users. This is often enough to understand which rule and issue blocking you from accessing the application. It also creates sign-in logs in Azure AD, which can found when opening each user.

From experience this is usually enough, and makes for more detailed messages then the users receive. And so we don’t have to separate these two conditions into two rules, in order to understand which setting is blocking someone.

Monitor changes

We are humans, we are sometimes lazy or on the more serious note, we can be blackmailed and severe enough threats can persuade us into compromising our environments.

By monitoring changes to conditional access rules, we can be notified and help our colleagues should they experiencing a blackmail situation. Or perhaps need a slap in their face for being lazy.

Depending on your monitoring solution (SIEM), there is a multiple ways to stream audit logs from Azure Active Directory.

If you don’t have a monitoring solution, I can recommend getting started with Microsoft Sentinel which has built-in connectors to Azure AD and based on KQL queries can alert you on e-mail if any rules are changed.

Or without a monitoring solution, we can have an Azure Logic App fetch the audit logs using the Azure AD API with a managed identity. Then present the change for example in a Teams channel chat, or e-mail you or your support case system.

Backup

While we are at the topic there is no built-in tool to make backup of Azure AD configurations, but it is quite useful if someone accidently deletes a rule or even using CI/CD Pipelines to make version history of changes.

I can recommend this solution using PowerShell to extract configuration into JSON which is highly suited for Azure DevOps. In order to compare result and output the changes to your desired dashboard or e-mail.