What You Need to Know About Securing Azure AD
|TLDR:||Microsoft has decommissioned Baseline Conditional Access Policies and has replaced them with the new Security Defaults as of the end of February 2020. If you have been using Baseline Conditional Access Policies, Microsoft advises that you move to the new Security Defaults policy or to custom Conditional Access Policies.|
Azure AD Security
Security within Azure is a huge topic covering a range of services offered by Microsoft. Everything from password protection, to data protection, to device protection, the list goes on and on. Our future posts will go into what you could be doing to protect your Azure instance. For this post though, we are going to go over what you can (and arguably should) be doing at a minimum to secure your Azure instance.
First, we will go over what the current system is and then what the new system will be.
Baseline Conditional Access Policies
Microsoft has recognized that customers of all licensing levels have security concerns. To help their customers, they released these free Baseline Conditional Access Policies. With this system, Microsoft basically said, here are some Conditional Access Policies that you don’t need to pay for that are going to help protect your Azure instance. There are four individual policies covering four important security vectors:
- MFA for Admins
- MFA for All Users
- Legacy Authentication Block
- MFA for Service Management
As you can tell by their names, the set of policies are largely focused around Multifactor Authentication. A recent blog by Melanie Maynes, Senior Product Marketing Manager, Microsoft Security, states over 99.9 percent of account compromise attacks can be blocked with MFA.
The remaining policy, governing Legacy Authentication, is also indirectly related to MFA in that the protocols that are used for Legacy Authentication (POP, IMAP, older Office desktop clients) can also be used to bypass MFA. The policies just don’t have the capability of utilizing more than a single factor for authentication, so it doesn’t provide as much security if you enable MFA for your users but then also allow them (or a bad actor) to bypass MFA with Legacy Authentication protocols.
What you should know about Baseline Conditional Access Policies is that the set of four policies can be enabled individually, independent from each other. This is important because you cannot modify the policies. If your organization has a use case for a single user, or small set of users, that needs a Legacy Authentication protocol you can’t just add exclusions like you would to a normal Conditional Access Policy. Instead you would have to leave the entire Baseline Conditional Access Policy disabled. Obviously, you would need to weigh the consequences of this action but at least you have the choice of keeping the other MFA related policies enabled and just keeping the Legacy Authentication policy disabled.
In a recent article, Alex Weinert, Director of Identity Security at Microsoft, goes over the reasons for adding in Security Defaults. In the article, he goes over some of the attacks Microsoft sees and why they have been evolving their base security levels for customers. He also briefly mentions the Baseline policies with an indication that they were just one attempt at trying to secure customers but that they ultimately moved away from the Baseline policies based on customer feedback and their other learnings. Whatever the reason for the switch, at the end of February 2020, they got rid of the Baseline Conditional Access policies and replaced them with a new Directory property called Security Defaults. Really, it is just the same Baseline policies with one catch: it is an all or nothing switch. You won’t get to choose which of the policies you enable and which you don’t.
The distinction is important for any organization that isn’t quite ready to invest in Conditional Access Policies for added security. If your organization has processes which utilize Legacy Authentication protocols (which include Basic Authentication for Remote PowerShell and SMTP for printers/scanners!) enabling the Security Defaults will break those processes. If you are a CSP using RPS with Basic Authentication for automated, non-interactive, connectivity to Exchange Online, you will need to make sure you have converted your processes to utilize Microsoft’s Secure Application Model. For your printers/scanners, you will need to utilize a relay capable of modern authentication or authentication via certificate or IP.
In lieu of paid for Conditional Access Policies, where you can customize policies and make exceptions, the new Security Defaults provide a simple and effective way of protecting your Azure AD instance. If you plan on enabling them, just be sure to understand that they block Legacy Authentication which could cause some issues with automated non-interactive connectivity or with your printers/scanners for those that utilize Basic Authentication with SMTP. If you utilize Exchange Online and have printers/scanners that fall into this category, consider setting up a relay with authentication based on certificate or IP (we will be going over this later as well).
If you are already using the Baseline Conditional Access Policies but picking and choosing among the four, be prepared to purchase licenses for Conditional Access Policies or be prepared to enable the entire set of them via Security Defaults.