Conditional Access

Learning

To get the most out of this article, I would recommend building out a trial policy whilst reading. Do this on a test tenancy. If you don’t have one, sign up for a free trial on this link: https://portal.office.com/Signup?OfferId=B07A1127-DE83-4a6d-9F85-2C104BDAE8B4&dl=ENTERPRISEPACK&ali=1 

What is it?

Conditional Access (CA) is, as the name suggests, a way of controlling access to your Azure and Microsoft 365 data and services based on a set of conditions. These can be conditions such as “Sign-in risk”, “Device platforms”, “Locations” - which can be inside or outside the network or can be applied to a specific location, “Client apps” - what client apps are being used, and the “Device state” which can include states such a “non-compliant”/”compliant” and whether or not the device is “Azure AD joined”. 

You might think that it all sounds a little bit complicated. It can be, I will not lie, but I intend to take you through Conditional Access and demystify the process. Hopefully by the end, you will feel confident with this powerful tool. 

Where can I find it?

The first logical question is where can I find it? It has had some different homes over the last few years, and I am sure Microsoft will re-organise their thinking once more, and move it somewhere else. This can be frustrating, but it keeps you on your toes and forces you to stay up to date with Microsoft 365 and Azure changes, otherwise you get left behind. Some find this irksome. I love it – I always get to learn something new. Anyway, for now it can be found in the Azure Portal. 

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

This is the direct link, you also find it in the Azure Portal https://portal.azure.com/ click into the search bar at the top of screen and type “conditional” (without the quotes).

Click on “Azure AD Conditional Access”. 

What license is required?

Conditional Access requires an Azure AD Premium license. This means Azure AD Premium P1 or P2. Azure AD P1 can be purchased as a standalone license or as part of EMS (Enterprise Mobility + Security) E3. Azure AD Premium P2 includes the P1 functionality as well as more advanced features such as “User risk” policies and “Sign-in risk” policies and can be purchased as part of the EMS E5 license or as a standalone license. 

See https://azure.microsoft.com/en-gb/pricing/details/active-directory/#:~:text=Enterprise%20Mobility%20%2B%20Security%20E3%20licences,Azure%20Active%20Directory%20Premium%20P2 for more details.

Common use cases

There is a lot you can do with Conditional Access, but here are some most common use cases.

1. Require MFA for all administrators – highly recommended.

2. Require MFA if the device location is outside the network – also highly recommended.

3. Block Basic Authentication – highly recommended. See https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online for an explanation of Basic Authentications, it’s weaknesses and how to block it. 

4. Require an approved app – this means a Microsoft app at present. See https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-grant#require-approved-client-app for a list of approved apps.

5. Blocking Risky Sign-ins*. 

* Requires Azure AD Premium P2 licenses.

Naming policy

Naming policies for CA can be very specific to the company or they can be non-existent, however a good, descriptive name for your policies will make administering them a lot easier. I have given the policies a descriptive name to show what they do. That will get you some Brownie points, however a better way to approach it is to give it a naming policy which will absolutely distinguish it from anything else. I would recommend using something like this:

CA Pol - UK – MFA for administrators.

The first part clearly states what it is – a Conditional Access policy, the location to which it is applied. This could be a country, an office, or a region depending on your needs. The final part is a brief description of what the policy does. This should be as succinct as possible. 

How to setup Conditional Access

There are too many use cases to show step by step, but I will show you how to setup one of them – MFA for administrators. The hope is this guide will help get you familiar with Conditional Access and give you greater confidence to configure some of the other use cases. As always, start small and build outwards. What does this mean? Start applying a Conditional Access policy to one test user or start the policy in report-only mode, more on that later. Test it, make sure you know what the consequences are before applying the policy, once you are happy with your policy, expand the scope to a group or the whole tenant. 

A word of warning before we start: be very careful with policies that apply to the entire tenancy or large groups. It is easy to lock yourself out which means logging a call with Microsoft Support with your tail between your legs. See the “Break-glass accounts” section for more details. 

Open the Azure portal and Azure AD Conditional Access. 

Click “New policy”. 

Start by giving your policy a descriptive name, then go through the “Assignments” and “Access controls” sections in order, depending on what you need to configure. 

We start with “Users and groups”, the image is a little small, but I wanted to show the enormous array of directory roles that are available. In the search bar, type “administrator”. This will narrow the field down, but you will still have to do a lot of clicking tick boxes to select all the administrator accounts. I am hoping Microsoft will come up with a button to select all, which will work when you filter your list, or at least give you the ability to select all administrator accounts. I will not hold my breath. Once they have been ticked, click “Select”. Sometimes setting exclusions is just as important as setting your inclusions. For this policy I am going to select a GA (Global Administrator) account to be excluded. This account has been selected so if the policy is applied and users are accidently locked out, this account can be used to adjust the policy or turn it off as appropriate. These should be break-glass accounts. See the break-glass account section for more details. Click “Exclude”.

Click “Users and groups”, select the GA account you wish to exclude and click “Select”. I have chosen the MOD Administrator account. Ideally, this should be an account that is not used and has a strong and long password. 

Next, you must configure the “Cloud apps or actions” section. 

Click “All cloud apps” under the “Include” header. You will receive a reminder not to lock yourself out – these are powerful policies. 

Now we need to enable the MFA condition. Under “Access controls” click “Grant”.

Ensure “Grant access” is selects, select “Require multi-factor authentication” and click the “Select” button. Under the “For multiple controls” section you have two options. The default option is “Require all of the selected controls”, the other option “Require one of the selected controls” means that only one of the controls has to be met for the policy to apply. You may require multi-factor authentication OR require that the device be Hybrid Azure AD joined.  At the bottom of the window you will notice you have three options: “Report-only”, “On”, “Off”. Select what you require and click “Create”. I would hope “On” and “Off” are self-explanatory, “Report-only” may require a little extra explaining. 

 

Report-only mode

The “Report-only” option is the default selection when you create a CA policy. This is for good reason. When you create a new policy, you might want to see how it performs without turning it on. You can do this by looking at user “Sign-ins”. These can be found in the Active Directory portal under https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/SignIns or by searching for “Azure Active Directory” in the search bar at the top of the screen in the Azure Portal – https://portal.azure.com. 

Here you can see all the recent sign ins for this user. You can also open a user account from the “Users” tab in Azure Active Directory then click “Sign-ins”.

To check if a “Report-only” policy would have been applied click on a recent login. 

You can see the details section on the lower part of the window. Click “Report-only” to see what policies would have applied had the policy been enabled. In the picture above, you can see the policy which was created earlier. Under the “Result” header it states “Report-only: User action required”. This means the policy was applied, but because we are in “Report-only” mode the user was not prompted and logged in as normal. 

Other results can be “Report-only: Not applied” meaning that the conditions were not met to apply this policy. You can also see this status in the picture above for the “App Policy” policy. “Report-only: Success”, and “Report only: Failure” means either the policy would have been successfully applied had the policy been turned on, or it failed as one of the “Grant” or “Session” controls were not met. For example, this could be the requirement to use a compliant device which was not met.  

Once you have monitored the policy for a while, how long depends on the policy settings and how many users the policy is applied to, you can enable the policy. To do this click the policy, click “On” and “Save” and you are done!

Break-glass accounts

Break-glass accounts are those that are only used in an emergency. For example, a CA policy has been applied and has locked all the users out. It happens. These should be cloud only, meaning they are not synched or federated in any way. This means this account will not be affected by a sync issue or a problem with the federation mechanism. At least one of these accounts should be excluded from any given CA policy. They should also have a different MFA mechanism. For example, the account could be configured to use security questions instead of the mobile app or SMS mechanism. Break-glass accounts should have long passwords that are randomly generated. To do this, you could use something like KeyPass. https://keepass.info/download.html. This is a great piece of software to keep your passwords safe and help you generate strong password for your apps and logins. See https://keepass.info/help/base/index.html for more information. These passwords should be stored somewhere safe and the accounts themselves should never be used, except in an emergency. 

This are powerful accounts, and are not going to be used much, hopefully ever. How can you be sure they are safe? Set up an alert! To do this see this guide: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access#create-an-alert-rule. 

Other Best Practices

The “What if” policy tool

This is a fantastic tool and a useful step in your deployment life cycle. You can setup a policy and set it to report-only. From here you can examine the logins, but it is quite a big ask to test every conceivable situation. It may just not be possible. This is where the “What if” tool comes in so handy. 

Still in the Conditional access blade click the “What if” button. 

Click “User”, select your user, and click “Select”. Click “Cloud app and actions”.

Select your app or leave it as the default setting which is “Any cloud app”. Click “Done” or close the window if you have not made any changes. Enter and IP address or country if you are testing a location-based policy. Select your platform from the list if you are evaluating a platform-based policy. Select your apps.

“Modern Authentication clients” are any apps that support Modern Authentication. See https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online for more information. “Exchange ActiveSync client (supported platforms)” are mobile connections to Exchange Online. The supported platforms are:

1. Android

2. iOS

3. Windows Phone

4. Windows

5. macOS

“Exchange ActiveSync clients (unsupported platforms)” are platforms that are not supported in Intune.  Finally, “Other clients” are “Basic Authentication” clients, generally email clients such as older native Android mail clients.   

Select your device state if required. Choose from:

“Device Hybrid AD Joined” means the device is joined to both the domain and Azure AD. “Device marked as compliant” means the device has meant the condition required by the “Compliance” settings in Intune. See https://docs.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started for more information. 

Under “sign-in risk”, choose the required level if your policy includes settings based on sign-in risk. 

 Under “user risk (preview)”

Select the appropriate risk level if your policy specifies “user risk”. Finally, click “What if”. Scroll down you will see two headers:

1. Policies that will apply

2. Policies that will not apply. 

Under these headers you will be shown which policies would be applied, and which policies would not be applied respectively, you may have to click “Load more” if they are not shown automatically. 

Policies that will apply

Policies that will not apply

In the picture above, you can see the reasons the policies are not applied. 

Beyond “What-if”

This is where you get down to real testing. Get your test user loaded on an Android/iOS or Windows device and try different scenarios, make sure you thoroughly understand the impact of your users before expanding the scope to a larger group or before pushing it out to the entire tenancy if that is your intention. 

Feedback 

Any feedback would be gratefully received. How has this article helped you? Will you be more confident in using Conditional Access as result of reading this article? Is there anything you feel is missing, and are there any other EMS areas you would like covered in future articles?