Office 365 Conditional Access

Since the dawn of time, or at least the dawn of computers, logging into our computer resources has been all about username and password. The username and password model has worked pretty well considering the simplicity of this model, but now it’s time to move on to better thought out authentication and authorization systems.

In this blog post I’m going to look at the current state of Conditional Access in Azure and Office 365. We’ll look at what Conditional Access is, how it works, and some of the other authentication and authorization systems interact with Conditional Access. In this blog post, I’m not so much going for a technical explanation of what buttons to click to make this or that feature work so much as a higher-level discussion of the reasons and theories behind Conditional Access.

What’s Wrong with Passwords?

As computers came into fashion, we needed a way to authenticate and authorize individual users to specific resources. We needed to know who was accessing each system and the resources on that system, and we needed a way to verify that the person hitting the keys was who they say they are. Usernames and password were a very simple way to achieve that goal.

Usernames give us the ability to assigned different authorizations to different users. This means that some people can have “admin” rights, and other can have “user” rights. Usernames give us the ability to create different “classes” of users who are authorized to read and modify different sets of resources.

Passwords give us the ability to have a “secret” bit of information that should only be known by the owner of a specific username. For passwords to be effective they need to be complex enough that someone else cannot guess them, but simple enough that the person who legitimately owns that account can remember them. This is the first problem with passwords, and a classic struggle for all IT departments.

The second problem with passwords is that users tend to think of a password they like, then reuse that same password as much as they can. If one system is compromised, then this makes it much easier for bad guys to gain access to other systems. If “John” has his password for Facebook compromised, then whom ever gets that password probably has easy access to information about where “John” works, and they are going to try that same password on that companies computer systems to see if they can get access to “John’s” account.

How does Conditional Access help solve these problems?

As computer systems have evolved over time, this username and password model has been shown to have multiple weaknesses, some of which I have pointed out above. So, what can we so to improve the username/password model?

As it turns out, there is a lot more information available that can be used to authenticate and authorize a user session beyond just a simple username and password entered by the user. Some of the other information that can be used is…

• The IP address the user is trying to log in from
• The geographical location of that IP address
• The time the user is trying to log in
• The last time the user tried to log in
• The type of device the user is on
• The protocols the user is using to authentication
• The specific application the user is trying to access
• Other applications the user has tried to access recently

This is just a short list of information that can be used as part of the authentication and authorization process.

Taking these individual pieces of information into account, we can probably identify a significant number of authentication attempts that should not be allowed. Say we know that “John” works from 8 AM to 5 PM, and he only accesses company resources from the office. If John’s account tries to log in at 7 PM and we can see that the IP address that this log in request is coming from is owned by an ISP in China, we can feel pretty good about denying that log in attempt. If John only has a Windows 10 PC, we should never allow anyone to access John’s email from a MAC, right?

Adding Conditional Access to other services

The more information we have about a “typical” authentication attempt for each user, the more secure we can make out authentication process. We can also use Conditional Access to trigger additional authentication requirements for users when they try to authentication in atypical situations.

Say John typically access his email from the office on his PC, but he may need to access it from other computers in other locations sometimes. You don’t want to completely prevent John from accessing email from other computers, but maybe you want John to take some additional steps to prove his identity when he tries to log in with these atypical situations. Conditional Access can is configured to trigger additional authentication steps like Multifactor Authentication.

Conditional Access within Azure and Office 365 makes it possible to trigger several other high-value security features to either block or allow authentication sessions in specific situations.

Wrap up

As I said above, this isn’t a technical how to post but more of a philosophical look at what Conditional Access is, what it can do for your organization, and why IT needs to move beyond the username and password model.

I make strong recommendations to all my customers that they take a good look at the identity security features within Azure and Office 365 and start thinking about moving into a post-password authentication model. Microsoft is making that possible now, so there is no reason to keep using that old and outdated model.

Monitor Your Hybrid - Office 365 Environment with ENow