Conditional Access in the Field - Part 1

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 more or less involved.

As more and more organizations move to a cloud based IT infrastructure, security is becoming more of a concern. By definition, 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 this blog post, I’m going to demonstrate the configuration and use of Conditional Access for a specific user. I’m going to create a user called “John Tester” and configure a Conditional Access policy for that user. I’ll also test those policies to ensure they work properly in several different situations.

John Tester

To test out Conditional Access I’m going to need a user to test with. For this post, I’m going to create a user named “John Tester.” In this scenario John will be a salesman with MCSMLab. I’ll need John to be able to access Office 365 resources securely from various locations, while allowing John to authenticate from the office without additional requirements.

I setup John as a standard user with an Office 365 E3 license. Conditional Access does require an additional license, but currently an Office 365 organization only needs to have a single license assigned to one user to be able to access Conditional Access. I have an EMS E5 license assigned to my account, so I don’t need anything additional assigned to John’s account. I do expect that Microsoft is going to enforce the EMS licensing requirement at some point, but as of this writing that enforcement is not in place.

Configuring Conditional Access

Conditional Access is configured as a part of Azure Active Directory within the Azure portal. Below is a screenshot of my Azure AD portal. The arrow points to the Conditional Access link.

Clicking the link for Conditional Access brings you to the Conditional Access tool.

Under Conditional Access you can configureClicking the link for Conditional Access brings you to the Conditional Access tool.

• Named location
• Custom controls
• Terms of use
• VPN connectivity
• Classic policies

These “sub-tools” are in addition to the Conditional Access policies that are created in the root of the Conditional Access tool.

For this blog post I am going to ignore Classic policies. Those are pre-existing policies that were created under the old Conditional Access portal.

The Named locations tool allows administrators to define the IP ranges of specific locations. This is used to define different authentication behavior based on the end-users IP addresses.

The Custom controls tool allows you to upload JSON code from a third party to apply additional controls. I don’t have a third-party application I can use for testing this, so I’ll be skipping this section too.

The Terms of use tool gives organizations the ability to show a terms of use pop-up that users must accept before authenticating into Azure and Office 365. You need to provide your own terms of use document as there is no “default” terms of use provided by Microsoft. My only recommendation here is that IT departments should work with the organizational legal team to develop these terms of use. The terms of use tool does support displaying different versions of the terms of use in different languages.

The VPN connectivity tool works with Always On VPN. The docs.microsoft.com support page for Always On VPN defines the feature as:

“Always On VPN provides a single, cohesive solution for remote access and supports domain-joined, nondomain-joined (workgroup), or Azure AD–joined devices, even personally owned devices. With Always On VPN, the connection type does not have to be exclusively user or device but can be a combination of both. For example, you could enable device authentication for remote device management, and then enable user authentication for connectivity to internal company sites and services.”

For most Conditional Access customers, the Named location tool and the Terms of service are the only sub-tools that will come into play. That’s what I’m going to configure for John.

Wrapping up Part 1

That’s the back-ground information we’re going to use to setup and test Conditional Access for John. In part two of this blog I’ll walk through all the testing I have done with Conditional Access and show you how to verify that everything is working as expected. If there are specific scenarios that you are interested in seeing deployed, please let me know in the comments.