Many IT Pros will attest that there is a constant push/pull between security and ease-of-use and I have personally seen many instances of IT Pros struggling with this push/pull over the years within their own organizations. Often times its resistance from the organization itself in implementing changes that would positively affect their own security posture, not the inability or desire on the part of the system admin or IT department. Even focusing on something as simple as multi-factor authentication (MFA), it is common to see push-back from management or certain departments.
In this article, we are going to talk about common reasons for this push-back, and ways that Microsoft’s Conditional Access feature can allow you to tread the line between security and ease-of-use.
Conditional Access, when paired with Azure Active Directory, is a tool used to provide next-generation identity services in the cloud age. No longer do administrators have to simply worry about the four walls of their building. Employee workforces today are dynamic and are working on several devices from several different locations. The needs of authentication and trust now must exist outside of those four walls of the business, and Azure AD and Conditional Access play an important role in this process.
Conditional Access uses a three-step process in determining if a user or device’s access should be allowed.
Figure 1 – Conditional Access
A conditional access signal acts as a trigger for a Conditional Access policy. A signal could be something like:
As part of the Conditional Access process, once a signal is triggered, a decision has to be made by the service based on the configuration of the conditional access policy. This usually boils down to the user/device simply being provided access (or not) but can also include varying levels or access as well. For example, you’ll be given access to the resources you’re trying to reach, but because you are using an administrative account, the service will force you to provide additional login information (such as MFA). Or, because you’re signing in using a legacy authentication mechanism, access will be denied, and you’ll be directed towards using the current (accepted) authentication mechanism being used within the organization.
These are just a few simple examples, but there are many other granular options along this vein that are provided by Conditional Access.
This is what I like to call the “Make-It-So” phase. Basically, Conditional Access will take the Signal from step one, look at the configured policy for that situation, and then enforce it. Combined, these three steps within Conditional Access serve to provide tightly control access mechanisms when access company resources in a cloud/mobile world.
So, how does this help you sell the idea of MFA within your organization? Let’s dig into that question.
NOTE: This was something of a crash course on the concept of Conditional Access. Much more information on this feature can be found in the official documentation.
Many organizations have tried multi-factor authentication with varying degrees of success. The more mature ones found a way to persevere through those challenges and their security posture was all the better for it. Others likely failed and rolled things back. Whether you’re using MFA today or haven’t yet looked at it, conditional access to help with the process. Let’s get into some concrete examples.
A business owner or manager complains that his/her department is constantly getting prompted for MFA. After all, they just want to do their work….
This is likely the most common complaint I see around MFA within organizations. Users get “annoyed” with the extra sign-on step, especially if it’s excessive or difficult. Conditional Access can improve this situation. As mentioned above Conditional Access can be configured to action on IP location. In this case, you can essentially white-list the IP for your primary office location(s) and tell conditional access that if a login attempt is coming from that location, that it’s trusted and does not require MFA. This step alone greatly reduces the amount of MFA “Chatter”, and will only prompt users for MFA when physically outside of the office.
An Administrator is concerned with knowing when to force password resets for users and what to do with accounts that are potentially suspicious.
Password hygiene is something that has been in flux these past few years where best practices are concerned. Did you know that new NIST recommendations state that there is no need to change a password unless there is evidence of breach?
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
Knowing this, one question many admins will ask themselves, is “On top of MFA, when will I have the time to monitor for compromised passwords?” The answer is you don’t have too! Conditional Access can do that. When paired with Azure AD Identity Protection, Conditional Access can check to see if the user’s username/password combination has appeared on any known credential sharing sites. If so, conditional access will force a password reset prior to allowing access.
Additionally, you can configure conditional access to force an MFA prompt (even within an otherwise known safe IP range) if certainly other “risky conditions” have been identified.
Paired with MFA, the policy of forcing password changes in conditional access serves to supplement user authentication hygiene and requires very little administrator work in doing so.
A CIO may be concerned that security requirements for administrator accounts are too lax.
This is a pretty common concern, Conditional Access can be used to force an MFA requirement on any account that has administrative access. I highly recommend this; due to the sensitive nature of the access, these types of accounts have. The added bonus here is that conditional access takes all the work out of enforcing it amongst your admins.
I’m interested in hearing about any of your other security and access concerns. Do you see a positive use for these Conditional Access policies? Is there a specific issue you’ve been trying to solve? Let us know in the comments below and we’ll be sure to get you an answer!
Thanks for reading!