In the ever-changing landscape of cyber security, relying solely on default security measures is no longer sufficient to protect your Azure environment. It's time to level up your security game by embracing the power of Conditional Access Policies. In this tech blog, I have curated a collection of highly secure and essential Conditional Access Policies that will not only bolster your security posture but also serve as the cornerstone for safeguarding your Azure Tenant against a wide array of potential attacks.
It’s important for any organization to implement strong Conditional Access Policies in their Azure Tenant, to make sure attackers are left behind without any possibility of compromising the infrastructure. Implementing Conditional Access Policies can be a hard task, due to the business needs throughout the organization. I often see that customers are not able to enforce policies due to legacy systems or inconvenience for end users. From a security point of view, convenience is not an option, when dealing with end users. It’s important that end users are aware of the possibility of attackers breaching an organization due to bad security best practices. Therefore, it’s highly recommended that any organization deal with security in the best manner possible to avoid bad configurations to be the downfall of the company.
Here is my list of Conditional Access Policies that should as a minimum be implemented, when going away from the “Security Defaults[1]”.
Ensure MFA is enforced for all administrative users
Ensure MFA is enforced for all users
Ensure blocking of Legacy authentication is enforced
Ensure a geographic exclusion of dangerous countries such as China, Russia, North Korea, etc. is implemented
Ensure that if a user is tagged as “Risky Sign-in” that MFA is required
Ensure Microsoft Entra ID identity protection user risk policy is enforced by blocking their sign-in or enforcing a password change
Ensure a Device Compliance policy is In place for Intune or Microsoft Entra Hybrid joined devices
Ensure a policy exists, to block “Unknown and Unsupported” devices
Ensure a policy is in place, to enforce “Trusted location” for MFA and Self-Service password reset registration.
Ensure a Conditional Access policy is in place, to enforce MFA when registering or joining devices to the domain
Above is my list of best practices regarding Conditional Access Policies.
A last policy to implement, when most of the security is in place, is a PAW[2] (Privileged Access Workstation) Policy. This policy will enforce, that only users using a PAW, will be able to log in using Azure CLI, Azure Portal, or Azure Powershell.
To enable conditional access policies, log into your tenant (Portal.azure.com). Navigate to Azure Active Directory and in the left menu under “Manage”, click on “Security”. Click on Conditional Access and then on Policies in the left menu.
This is where Conditional Access Policies are created and edited. There are multiple built-in templates, that I recommend you use, which would also help implement the above policies.
I highly recommend that you always set policies in Report Mode first. From here, you can enable them on a scope of users and then enforce when trusting the setting for your organization.
Ensure MFA is enabled for all administrative users
This Policy is providing a big security improvement since the MFA requirements for all privileged access are going to be required as a second authentication through the Microsoft Authenticator app for Mobile Phones. Be aware that this Policy does not affect Custom Roles[3] or Administrative Units scope[4].
Start by Creating a new policy from the top menu (+ New Policy) – You are now presented with the configuration of the policy:
This affects the login to the Management Portal and can disrupt your connectivity to the portal if you have not set it up properly. (Make sure to exclude your Administrative user and break-glass accounts). Before this policy is implemented, it’s also important that you might not want to enforce it on everything at once. Depending on the size of the company you are working in, and the awareness of security that each end-user has.
This can be done in the “exclude” option under “Users”.
Name:
Give it a name, that makes sense. This one I call MFA for all directory roles. There are 90 Directory roles you can choose from here; I enable it on all – Including the “non-administrative directory roles”.
Users
Select Users and Groups> Directory Roles > Tick all of them till you have 90 selected.
Target Resource
Under Target resource, we choose cloud apps and All cloud apps.
Now to enable the actual MFA, navigate to “Grant”.
Under Access Controls, choose grant. Then on the right menu, choose “Grant Access” and then put a mark in the “Require Multifactor Authentication” box.
At the bottom of the “Grant” page, choose “Require all the selected controls” and then click “Select” at the bottom.
This will make sure that ALL controls need to be met, for this to work. In our case, we only have MFA as an Access Control enforcement, but it will do the job for this specific policy.
Now the policy has been configured and set up correctly, you can create the policy either in Report-only mode, On mode, or Off mode. Either way, it will be created. So, depending on your current need for this Policy, you can set it in report mode to see if it acts as it should, or just enable it, if you feel comfortable that this is it.
At this point, the policy will warn you, that you might lock yourself out. This is important to look into, to understand why it is warning you. Basically, we specified all administrative users to be hit by this policy, this includes the “Privileged user” you are using at this moment to create the policy. Therefore, if you did not exclude yourself, or break-glass accounts in the “Users” exclusion phase. Then you will lock yourself out. Make sure that you know how to set up MFA and that you have a Break-Glass account that is excluded since break-glass accounts should not be enforced for MFA ever. Just in case, you somehow accidently lock yourself out of the tenant.
If you did exclude yourself, it will not give a warning – For example:
Click Create, and you have your policy created and will now be prompted to set up MFA for all administrative and directory roles. Make sure that you have the Authenticator App, so you can easily set it up when prompted. Scan the QR Code and type in the phone information etc. It’s an easy setup, and just follow the flow.
Ensure MFA is enabled for all users
This Conditional access policy is meant for everyone in your company, any end user who is logging into any Application, Office product, etc.
Before implementing this, it’s important that you make sure everyone in the organization is aware of this change, and that an instruction guide to set up MFA is sent out to all end-users about how this will take effect. This means that everyone in the organization needs to have a mobile device, with the Microsoft Authenticator app available. So as soon as the change has taken effect, they are ready to scan the QR code and set up MFA by the instruction sent out.
Create a New policy, and give it a name like “MFA Everyone”
Let us configure the assignments and access controls for this Conditional Access Policy:
Under users:
Click on users and select All users under Include.
Make sure to Exclude your Break-Glass Account, so that you will always be able to log back to the management portal in case you lock yourself out.
Under Target Resources
Choose Cloud apps, and select “All Cloud apps”
In the last setting, under “Grant”, we set up the MFA.
Click on Grant – Enable with Grant Access and choose “Requirement Multifactor authentication”.
Click on Select at the bottom of the grant menu.
To create the policy, make sure to click Create at the bottom of the page. Again, be aware that the policy can be in Report-Only mode, On Mode, or Off Mode. And that you will get a warning if no exclusions are met.
Ensure blocking of Legacy authentication is enforced
This policy is very important to implement, especially when you have configured MFA. If this policy is not enabled, an attacker can bypass Conditional Access Policies and MFA by exploiting older Microsoft Office apps or apps using mail protocols like POP, IMAP, and SMTP. This is because older applications do not support Modern Authentication, and therefore can log in without being prompted by MFA.
To enforce this policy follow these guidelines:
Create a new policy – give it a proper name like ‘Block Legacy Authentication’.
Let’s set up the Assignments and access controls for this policy.
Under Users make sure you Include everyone and exclude your Current User (if needed) and Break-Glass account.
Under Cloud apps, make sure “All Cloud apps” is selected:
To enable the legacy authentication block, go to Conditions:
Select Client Apps and set configure to “Yes”.
Under “Legacy Authentication clients” select “Exchange ActiveSync clients” and “Other Clients”.
Now we need to enforce whether to allow or block the access, in this case, we want to block access for all users who are using Exchange ActiveSync or other Clients with legacy authentication.
This is done under Access Controls > Grant and choose “Block access” – At the bottom, you can choose either since there is only one control.
Make sure to click Select, and then at the bottom, you can create the policy.
Ensure a geographic exclusion of countries is implemented (China, Russia, Morocco, and North Korea)
This policy helps prevent attacks targeting your Azure infrastructure from specific countries that we know attacks would typically originate from. Countries I would recommend are China, Russia, Morocco, and North Korea, but this can be extended to a larger or smaller list regarding what you see fit.
Be aware that if you have business relationships with customers in other countries that are on that list, this could break functionality and collaboration.
To be able to use these Countries in your policy, we need to create the Named Locations for them first. To do that, click on Named Locations instead of Policies in the Conditional Access blade:
Click on (+ Countries location) and give the location a name – an example could just be the country of what you want to make the location of. In this case, I want to make a location for China.
Type China in the search bar, and the location will appear – Make sure to set a check in the China Check box and then click on Create. (it’s possible to choose multiple locations in one if you don’t want them separately.
Do the following for each of the countries you want to block, so that they are ready to be used in our Conditional Access Policy.
Head back to Policies and create a new policy.
As the other policies, target all users, and all cloud apps. (For this policy, we don’t need to exclude our Break-Glass account – But you can do it if you just want that Account to never be hit by any policies whatsoever).
Under Conditions, choose Locations, and set Configure to “Yes”. From here select “Selected locations” and choose the countries that you created earlier under Named Locations.
Under Access Controls, make sure that you Block Access and Create the policy. This policy can be a good idea to put in report-only mode first if you have doubts about countries you collaborate with.
Ensure a risky sign-in policy is enforced
To enable this policy to be effective, the Azure tenant must be Microsoft Entra ID Premium P2 to include Identity Protection risk in Conditional Access Policies.
To use this feature, it’s also required that all users are Registered for MFA. For hybrid users, Password Writeback must be enabled.
There are two types of risk policies in Microsoft Entra ID. Sign-in Risk and User Risk – I will go through the Sign-in risk in this policy.
It’s important to note that, with these Automated Risk Policies, you must engage your end-users to be able to “Self-Remidiate” using MFA or SSPR (Self-Service Password Reset).
Create a new policy:
Make sure you have selected All users and excluded your own Current User and all Break-Glass Accounts. And make sure that the Target Resources is set to “All Cloud Apps”.
Under Conditions is where we configure the Sign-in risk – Make sure the Configure option is set to “Yes” and that the Sign-in risk level is set to “High”. Depending on your wanted security posture, you can enable this for Medium and Low also, but this will generate more “false positives”. It’s a good practice though, to include Medium – This can be tuned up and down, based on your experience going forward with this setup.
Under Grant, make sure you Grant Access and set Check in the “Require authentication strength”.
The last configuration for this is to set up session. This is how to enforce the sign-in frequency properly.
This means, that whenever this Condition happens for any user on any cloud app, and the Sign-in is “high” a user will be prompted with MFA for granting access. Should it be an attacker that tries this, they will not be able to meet the MFA, and thereby reduce the ability for an attacker to get a foothold and move laterally from here in the infrastructure.
Click Select in the Session setup and create the policy.
Remember you can test this out with 1 user to start with, where you enable it and try to trigger the Sign-in. When more and more users are hit by this policy, you can track if you feel like it should be used for medium-risk sign-in also.
Ensure a user risk policy is enforced
To enable this policy to be effective, the Azure tenant must be Microsoft Entra ID Premium P2 to include Identity Protection risk in Conditional Access Policies.
To use this feature, it’s also required that all users are Registered for MFA. For hybrid users, Password Writeback must be enabled.
Create a new policy:
Make sure you have selected All users and excluded your own Current User and all Break-Glass Accounts. And make sure that the Target Resources is set to “All Cloud Apps”.
Under Conditions is where we can configure the User Risk – Make sure the option is set to yet, and that the User-Risk level is set to high.
Under Access Control, we must set two requirements before we can Grant access. Since a high-risk user can be damaging to our environment, it’s important that the user can confirm their originality. Therefore, we require both an MFA and a Password Change to be able to continue with this account. (Pay attention to the fact, that if you want to put Password Change on, you must target “All Cloud apps” under “Target Resources”.
And finally, we need to set up a session to enforce that the sign-in frequency for this, is always! – No matter if the High Risk has just been triggered, and it triggers again.
Select at the bottom of the session and create the policy.
Ensure a Device Compliance policy is in place for Intune or Microsoft Entra Hybrid joined devices. (Android, iOS, Windows macOS)
Device compliance enables you to make sure that whenever any device is trying to connect to any of your resources, it’s required to be marked as compliant. If this is not the case, that device will not be able to connect to any resources of your organization.
Remember to make a Block uncompliant device when this policy is in place. To remove the possibility of bypasses of other device platforms than the ones we are going to choose. We will focus on Android, iOS, Windows, and macOS which are the most used devices for corporate use cases. If your company works around BYOD (Bring Your Own Device). This Conditional Access Policy can be tough to manage since the devices either must be managed by the organization through Azure registration or be part of an on-prem domain. (This is often not the case when it comes to BYOD).
Create a new policy,
Make sure that all users (Break glass accounts and your current user excluded), and all Cloud apps are selected.
Under conditions, choose Device Platforms and set Configure to Yes, make sure to include Android, iOS, Windows, and macOS.
Under Access Controls, we need to choose our compliance and Microsoft Entra Hybrid joined devices.
Select “Grant Access” and then mark the checkboxes “Require device to be marked as compliant” and “Require Microsoft Entra Hybrid joined device”. It’s important that we in this policy make sure to require one of the controls. (See picture below)
Finish by clicking “Select” and then create the policy – Remember to put this policy in report-only mode to start with, since this will block users from using apps if their devices are not compliant or Microsoft Entra Hybrid Joined.
Ensure a policy exists, to block “Unknown and Unsupported” devices
Since we have a policy now, that enforces compliance for Android, iOS, Windows, and macOS. We need a policy to block the rest of the device platforms that we do not support.
To do this, we create a new policy.
Make sure you have selected All users and excluded your own Current User and all Break-Glass Accounts. And make sure that the Target Resources is set to “All Cloud Apps”.
Under Conditions, select Device platforms and set Configure to “Yes”, make sure to check off “Any Device” under Include, and exclude our platform devices that you use in your Compliance policy. E.g., Android, iOS, Windows, and macOS.
For the last part of the policy, we need to set our Access Controls to block.
Under Grant, make sure to click on “Block Access” – Select the setting, and create the policy.
Remember to put it in report mode first.
Note: This policy will block all alternative devices that hackers potentially can use to bypass your policies.
Ensure a policy is in place, to enforce “Trusted location” for MFA and Self-Service password reset registration. (Register Security Information)
This policy is meant only for organizations that want to have their onboarding happening from a central location which is a trusted location. This policy will block the registration of MFA and SSPR if the location is not trusted.
Create a new policy, and make sure you choose all users and exclude the Break-Glass account.
Under target resources, we need to choose “User Actions” in the drop-down menu.
From here, select the “Register Security Information” checkbox.
This checkbox enforces MFA and SSPR registration.
Under Conditions, we want to choose Locations.
Select Locations and set configure to “Yes” and make sure under Include, that “Any location” is selected.
Go to “Exclude” and make sure you exclude “All trusted Locations”.
This setup might look confusing, but since we are going to block access for MFA and SSPR Unless they are on a trusted location, we need to make sure that any location is blocked, and that trusted locations are excluded from that block. This way, MFA and SSPR registration can be completed in trusted locations.
Under Access Controls, click on Grant and make sure that you select “Block Access”.
Click on Select, put the policy in report-only mode, and create the policy.
Ensure a Conditional Access policy is in place, to enforce MFA when registering or joining devices to the domain
For our final policy, we want to enforce MFA when joining or registering devices to the domain. This way, we won’t have any devices joined without being verified by trusted personnel. To increase security, we also want the registration to happen from a trusted location.
Create a new policy, and make sure you give it a meaningful name. Select All users and exclude your Break-Glass account and your current user.
Under “Target Resources”, we choose User Actions in the drop-down menu, and select “Register or join devices”.
To enforce trusted locations, go to conditions and select Locations. Set the configure options to “Yes” and then select “All trusted locations”
As a last thing for this policy, we want to enforce the MFA to trigger when registering or joining a device from a trusted location to the domain.
Go to Access Controls and select Grant. In the grant menu, make sure to select “Grant Access” and “Require Multifactor Authentication”.
Click on Select in the Grant menu and create the policy. Put the policy in Report-Only mode to start with, until you have seen the effect.
Ensure the use of a (PAW) Privileged Access Workstation, when utilizing Azure management as Global Admin
Whenever sensitive or mission-critical systems are accessed without the use of a PAW, the risk of credential theft and lateral movement from the system where the access is initiated against the sensitive or mission-critical systems is introduced.
Therefore, the attack surface of sensitive or mission-critical systems is increased, as compromise of the domain may lead to compromise of said systems.
To enforce PAW-only access to the Microsoft Azure Management application (which is the Azure portal, Azure CLI, and Azure PowerShell), I recommend creating a Conditional Access Policy targeting privileged users and utilizing device filters to accept only specific PAW devices.
To enforce a PAW for GA we need to create 2 policies
Create a new policy and give it a meaningful name like (PAW) Privileged Access Workstation for GA
Under Assignments, choose users and select Include> Select users and groups > Directory roles and find the Global Administrator role. Make sure to exclude your Break-Glass account.
Under Target Resources, make sure to only include “Microsoft Azure Management”. This can be done by choosing “cloud apps” in the drop-down menu, and then “Select apps”. In the search field search for “Microsoft Azure Management” and select it when it pops up.
Now that our users and resources have been chosen, we need to set a condition for them. We chose that all Global Administrators use Microsoft Azure Management (Portal, CLI, Graph).
Under Conditions, choose “filter for devices”, set configure to “Yes” and mark “Exclude filtered devices from the policy”.
Make sure you make a rule syntax that marks your “device.displayname” to contain what you will be calling your Privileged Access Workstations. In our case, it’s just “PAW”.
Under Access Controls, we want to “Block Access”, this means that if you are a GA, trying to use Management Portal, you will be denied unless you are coming from a device whose name contains “PAW”.
IMPORTANT: Don’t enforce this policy, unless you have a PAW ready, and that you’ve tested the functionality of it. Do exclude more Global Admins from this policy, to make sure that you can access the portal and edit the policy in case it blocks your “included” users. Always a good idea to test on 1 user first.
To follow up on this policy, we need to create another policy for Global Administrators, that ensures that they are using MFA and coming from a Compliant device before they can access Azure infrastructure.
To do that, create another policy, and name it something meaningful like PAW for GA – MFA + Compliant device.
As above policy, make sure we target Global Administrators and exclude our Break-Glass Accounts (+ additional GAs in this case, due to the severity of the policy if done incorrectly).
Under target resources, make sure to choose “select apps” and find Microsoft Azure Management.
And for the last settings to this Policy, we need to choose what happens under Access controls.
Click on Grant, and make sure to check the boxes “Grant Access”, “Requirement Multifactor Authentication” and “Require device to be marked as compliant”.
It’s also important that for this specific granting of access, both above Requirements must be satisfied – Select “Require All the selected controls” at the bottom of the “Grant blade”.
Again – Do not enforce this policy straight away, make sure that you have it in Report-Only mode to start with. Enforce it to 1 GA to start with, before pushing it for every GA.
[1] Azure custom roles - Azure RBAC | Microsoft Learn
[2] Assign or list Microsoft Entra roles with administrative unit scope | Microsoft Learn
[3] Providing a default level of security in Azure Active Directory - Microsoft Entra | Microsoft Learn
[4] Privileged Access Workstations (PAWs): How to Prevent Attackers from Sensitive Accounts and Tasks | Microsoft Learn