Azure AD Security Defaults arrived recently and make it easier to implement some of the most common security settings in your Azure AD directory, and Office 365 environment. They aren’t appropriate for everyone, but if you’ve not enabled multi-factor authentication yet, or haven’t disabled legacy authentication, then this might want to be something you consider.
Every Office 365 environment should be secure, and technically – they aren’t susceptible to vulnerabilities, are patched and up to date and regularly tested. But the default settings for an Office 365 tenant have been aimed at the lowest common denominator – organizations with legacy clients and with an expectation that organizations will buy add-on security features, like EM+S if they truly want security. This does mean that many, may Office 365 tenants are vulnerable to a number of attack vectors, including password spray attacks, because an attacker can repeatedly try and login to an Office 365 tenant using basic scripting to attempt a login, then if they successfully authenticate with a username and password, there isn’t an MFA mechanism in place.
Security Defaults replace Baseline Conditional Access policies, which do a similar job, and are offered free to all Office 365 subscriptions, whether or not you’ve paid for Azure AD Premium licensing. This is a change, as although per-user MFA could be enabled in Office 365, it didn’t include the Authenticator app, nor the straightforward enablement mechanism enjoyed by Conditional Access or service-wide Azure MFA.
Security Defaults enforces these settings:
- Multi-Factor authentication for administrators and end-users, required within 14 days of the next sign-in after enablement
- Legacy authentication will be blocked, restricting access from older clients, like Office 2010, IMAP, POP3, SMTP, ActiveSync clients that don’t support Modern Auth, and traditional methods of managing Exchange Online using Remote PowerShell.
- Immediate MFA protection for “privileged” Azure AD actions via the Azure Resource Manager API (such as Azure Portal Access, Azure PowerShell and the Azure CLI).
These defaults are more secure than the baseline policies. Baseline protection policies were (and are) provided using the Conditional Access portal settings, and allowed selective enablement of MFA for administrators, MFA protection for (what Microsoft determine as) risky sign-ins for end users, blocks for legacy authentication and MFA for service management. Baseline policies were not only hidden away, but also never left preview – so many people won’t be using them in production.
Microsoft plan to enable Security Defaults for all new Azure AD tenants within the “next few months” – which should mean by the end of January 2020, a new Office 365 subscription will come with MFA enforced out of the box, and legacy authentication enabled. That’s important to know as it’s a big change.
How this might affect new Office 365 migrations
If you sign-up for an Office 365 subscription over the next few months and Security Defaults are enabled then this might be a surprise – even if you don’t have older clients like Office 2010 or use IMAP and POP3 clients.
One example of this is Outlook clients. When you migrate a mailbox, the expected behaviour is that Outlook will automatically reconfigure and connect to Exchange Online. Even with the latest Office 365 Pro Plus, signed in using Modern Authentication to Office 365 for licensing, you could still see an issue with Security Defaults enabled.
This is because when a mailbox is migrated, it continues to use the legacy authentication process as it follows the Autodiscover bread-trail to Exchange Online, and then fails when attempting to sign-in. This can be solved, either by switching off Security Defaults during your migration – or if you have control over your Outlook clients, you can deploy the registry key in this article.
In general though, you shouldn’t expect many technical issues at all if you are using up-to-date Office 365 Pro Plus clients and the Office apps on mobile. You’ll also find ActiveSync clients on iOS devices, the Gmail app and Samsung Mail apps all support Modern Authentication too (however, you’ll need to reconfigure those clients).
The biggest factor though maybe the user impact of enforcing MFA from every location.
No replacement for Azure AD Conditional Access
The down-side with Multi-Factor Authentication is the inconvenience to users. This of course, is necessary from unknown devices in unknown locations, but most organizations invest significant time and expense in ensuring that their devices and locations are secure, and as such trust their devices.
This is where Azure AD Conditional Access remains important. Conditional Access allows different levels of security for different people, apps, managed and unmanged devices and locations. You can choose where and when to enable MFA or even block access.
For example, you might choose to remove the need for a user to confirm it’s them via the Microsoft Authenticator app when they are signing in from their domain-joined, Windows 10 PC, using Office 365 Pro Plus at their computer in the Office.
You might also avoid regular prompts for MFA on their company issued mobile, too – and instead manage the device properly using tools like Intune. However you might require them to sign-in every so often if they are working from home on their company issued laptops. You might even block sign-in altogether to services containing sensitive business data from random web browsers on unmanaged devices.
There’s a lot more to Conditional Access than the above snippet – a lot more – but those are some of the core scenarios that most companies look to achieve and Security Defaults doesn’t cover.
The greatest pity about Security Defaults is that the most basic functionality organizations need – to define locations where MFA isn’t necessary – isn’t included.
This will be especially frustrating for some organizations where they have simple use-cases, like shop-floor workers in manufacturing where employees are not allowed mobile devices and the uplift to Azure AD Premium for each user doesn’t provide enough value to justify it for those type of workers. In those cases, we’ll probably see those organizations left unprotected.
Perhaps Microsoft will do as they did with the Authenticator app, and bring the basic trusted IP address range for skipping MFA.
Enabling (and Disabling) Security Defaults
You can enable Security Defaults if you aren’t using Conditional Access today. If you do have CA policies, then you won’t be able to enable Security Defaults.
Before you do anything, make sure you perform user communications so people know the change is coming – and ensure you won’t prevent access from legacy clients or applications. It’s an all-or nothing switch; so you can’t put in place exceptions for users or legacy applications like you can with conditional access.
To enable Security Defaults, sign-in as a Global Administrator to the Azure AD Portal and navigate to Azure Active Directory and scroll down to Properties. From there, select Manage Security Defaults:
You’ll then see the option to enable Security Defaults. It’s an all or nothing switch – it’s either enabled or disabled:
The good news with Security Defaults is that should you decide you need Conditional Access policies, you don’t need to switch off Security Defaults before you define your CA policies. When you configure your CA policies, you’ll be informed you can continue to create them – once you’ve created your policies you can switch off Security Defaults and enable the CA policies you’ve defined.
Summary
Security Defaults are a good addition to Azure AD, and therefore Office 365 and will ensure many more organizations are secured by default. It’s a pity they don’t include all of the basic functionality most organizations should have – but they are a great start by Microsoft on helping all customers – not just those with Azure AD Premium licensing – to secure their identity.
Steve is a Microsoft MVP for Office Servers and Services. He enjoys getting hands-on, solving some of the more complex problems associated with migrating to the cloud or to newer versions of Exchange Server.
Hi Steve
We’ve found that in reality clients are very rarely (if ever) prompted for MFA, unless they are doing something like accessing sensitive information or logging on from another country. So not have trusted IP locations is not a huge issue. Admins get prompted every time which is good.
The main issue we have found (other than getting users to enroll can be very painful) is that we have found activesync clients getting randomly quarantined in Exchange, even when there is no quarantine policy. This has happened sometimes weeks after turning on security defaults, and for no apparent reason. Only fix is to delete the account, approve the device, then add the account again.
Yes I know that they should use Outlook on iOS but you can’t always force users to do that (they are the client at the end of the day).
I agree – for most workers with correctly configured machines there should rarely be MFA prompts and Security Defaults is also a very gentle on-boarding experience allowing the user to temporarily skip the process.
We do have scenarios like workers without handsets or phones using non persistent devices where this is troublesome and conditional access is useful. We may also find that users have become more used to MFA over the last few weeks especially those that never needed to use it before, so Security Defaults is potentially going to become much more used and there will be less resistance to rolling out MFA.