Conditional Access in the Field - Part 2

Part 1 - Recap

Securing your data in Office 365 can be a challenging task. The problem is that using user names and passwords as the basis of our authentication protocols is not a very successful way to run our technology.

One of the major failings of the username and password system is that it does not include any awareness of the situation in which a user is attempting to authenticate. A user may be trying to authenticate from a new location or may be attempting to authenticate to access an unusual set of data. There are a lot of situations where it may be prudent for the authentication process to be involved.

As more and more organizations move to a cloud-based IT infrastructure, security is becoming more of a concern. Cloud-based IT resources are available to be accessed from anywhere on multiple device types. While this convenience is valuable, it can also be dangerous.

Conditional Access is a feature of Azure Active Directory that gives organizations an additional tool to help manage that balance between security and accessibility. With Conditional Access your organization can define specific conditions under which users can access specific data. With Conditional Access your organization can implement automated controls for defining which users can access which data under specific conditions.

In part 1, I talked about some of the basics for Conditional Access. In this blog post, I’ll walk through the technical settings to get it working for an example user I’ll call “John Tester”.

Configuring Conditional Access for “John Tester”

For the purposes of this blog post, John is an end-user who works both in and out of the Office. We’ll say John is on your sales team, and he needs to be able to access Office 365 resources from the road as well as from the office.

For this example, we’ll say that your security team has decided that users logging into Office 365 resources outside of the corporate network need to setup and use Multi-Factor Authentication, but that they don’t need to be bothered with the extra authentication steps of MFA when they are in the office.

I’ll also show how to setup CA so that John can ONLY log into Office 365 from the office.

First, we need to setup the office under “Named locations” in the CA section of Azure AD as covered in the part 1 blog post. I setup a “Portland Office” named location, and we’ll also configure the MFA requirements under “Configure MFA for trusted IPs.”

To configure the “Portland Office” location I went into “New location” and added the IP range used by that site as shown below. You do need to enter the IP range (or even single IP address) in CIDR notation. That’s 73.157.184.132/32 for my setup. You’ll want to make this location as trusted with the check box.

Under the MFA settings you also need to list that IP address in CIDR format, and I selected the box to skip MFA for authentication requests from this IP range.

Now that work is done, we move on to the actual Conditional Access policy.

1. Click the + to create a new policy. You’ll need to name your policy.
2. Under Users and groups, you’ll select the users or group to whom this policy should apply. I assigned mine to just one user for testing purposes.
3. For Cloud apps, I selected the radio button for “All cloud apps.”
4. Next, under Conditions I excluded “All trusted locations” as shown in the screenshot below.

This will exclude this policy for being enforced for authentication attempts from trusted locations.

Under conditions you can also select several other options to secure your end-users authentication process.

Sign-In risk allows you to select specific sing-in risks to which this policy will apply. The settings for risk evaluation are in Azure AD Identity Protection, and I’m not going to go into those settings here. For this blog I’ll just mention that you can apply any CA policy to an authentication attempt based on the evaluated risk of that sign-in attempt.

Device platforms allow you to choose which platforms will have this policy applied. The possible choices are Android, iOS, Windows Phone, Windows, and macOS.

Client apps (in preview as of the writing of this blog. Feature may change by the time you’re reading this) allows you to apply this policy to specific software accessing the app. For instance, you could block users from access SharePoint from the web, but allow them to access SharePoint from the SharePoint mobile app. In my testing this feature is still hit-and-miss, but I assume that is why it’s still in preview.

Device state (in preview as of the writing of this blog. Feature may change by the time you’re reading this) allows you to apply this policy based on if the client is Azure AD joined or marked at compliant.

For this policy, I just selected location and excluded all trusted location. The goal being that this policy allows John Tester to skip MFA from trusted locations.

To do this I selected: Grant access and require MFA under Access controls.

Now to test our new policy out. You’ll need a way to get a different IP address for your computer to test this. I was able to use my home internet service IP address as the trusted location, and then I connected from my work VPN to get a different IP address that I expected to require MFA.

As you can see, there are a lot of options for setting up these Conditional Access policies, and these options are being updated on a regular basis. I highly recommend testing your policies before you apply them to a large group of users. There is a “What-if” tool for testing Conditional Access policies, but I find it’s not a replacement for real live testing with a test account. The What-if tool does a good job of telling you which policy applies to a given authentication situation, but I still prefer to get the real live authentication experience with a test account before I assign a policy to end-users.

Gain Visibility into Your Office 365 Environment Today