Azure Azure Active Directory

Azure Active Directory and Office 365: Conditional Access

When I talk about security within cloud services, I always like to start with identities. And within Office 365 that is not different. One of the most overlooked parts of security is making sure you have your authentication process set up correctly. We try to educate end-users to make sure they are not distributing their username and password, we implement password policies to support them in keeping their information safe. Sometimes we might even consider -and if we are lucky implement- multifactor authentication.

And that is it?! It doesn’t have to be. In this post, I am going to address conditional access in Office 365. To be able to setup this up you need Azure Active Directory P2 license, there are multiple ways to enable this, either standalone or as a part of a more extensive SKU. Microsoft even provides a 30-day trial you can spin up to test it and see if it is something you like/need or not.

Azure Active Directory is a part of the Azure Service Stack. So we will start by using the Azure Portal. You should see the service Azure Active Directory (AAD). Every Office 365 tenant comes with one. Within AAD, you will see the Conditional Access section where you can define your policies. When you create a policy you need to decide if you want to create a Grant or Block policyThe reason why I like to decide that in the beginning is because it will change your mindset through the process depending on which one you select. And here is where the first problem came to the surface. You can’t just say, for these users, I just want a Grant policy. If you want an explicit Grant policy, e.g. only people from the USA can login into Office 365, well, that is not possible with a Grant policy. The reason for that is when you create a Grant policy, you need to select one of the following controls, and that selection is mandatory.

  • Require multi-factor authentication
  • Require device to be marked as compliant
  • Require domain joined (Hybrid Azure AD)
  • Require approved client app

This limits the Grant policy functionality. Now the good news is that each Grant can be rewritten into a Block policy with exclusions. So that is what we will be doing in our example here as well. So if I only want to allow logins from the USA, I need to inverse it, meaning I need to block all logins from all the regions except the USA. So now I have the definition of my Block policy. We start by clicking the + New Policy button. Give it a meaning full name, I chose Allow USA Login Only since that is what I will be creating.

Screen Shot 2018-02-08 at 1.43.32 PM
Each policy has two sections, Assignments and Access controls. These two sections control the behavior of your policies. The assignments will define the conditions that need to be met before the policy will kick in and the Access controls will define what the behavior is when the conditions are met. What is very important to understand, is that the assignments conditions work as an AND operator. This can add some additional complexity when creating these policies. Just a fair warning here! In the second part of the post, we will see how you can test your policy in a very easy way.
Let’s take a look at the Assignments. You can create requirements based on Users and Groups, Cloud Apps and Conditions. Those conditions consist out of Sign in Risk, Locations, Device Platform, and Client Apps. In my example, I am going to exclude my administrators. That guarantees me that my admin can always be able to log in.

Screen Shot 2018-02-08 at 1.55.04 PMScreen Shot 2018-02-08 at 1.55.24 PM

For the cloud apps, I selected all since I want all my cloud apps authentication to behave the same way. If you want this policy to only apply to one cloud app, you might want to select it here. Next, we are going to define the conditions. Since I want to block authentication based on location, this is where I need to define it. But before you can do this, you need to define your region in the section Named Locations. This is an option under Conditional Access. Named locations can be created based on IP ranges and Countries/Regions. My definition is based on the country United States.

Screen Shot 2018-02-08 at 2.03.38 PM

Now we can use the region in our conditions. So my condition is Any location with the US Region excluded. This also protects me from any unknown locations or locations defined in Azure in the future. The last thing I need to do is define it as Block policy and enable the policy. Save, wait and you are ready to go.

Tip: remember that the conditions work under an AND operator, if I would define a device condition in here that would only allow Windows Platforms to connect, it would reduce the reach of my policy. If I would try to connect to connect from South Korea with a Windows Platform, the conditions concerning the Windows Platform would negate my location requirement.

Now how can you be sure if you policies are created correctly? Use the What If functionality.

Screen Shot 2018-02-08 at 2.13.39 PM

Define the different conditions you want to test and see if the policy is active or not …  I entered a South Korean IP address and you will see that it says Block Access as a result of that.

Screen Shot 2018-02-08 at 2.17.36 PM

In some of the next posts, we explore this functionality even more ..

%d bloggers like this: