Goodbye Baseline Policies, Hello Security Defaults

.

Goodbye Baseline Policies

Baseline Policies in Azure AD Conditional Access were introduced in preview last year. They provide an easy way for customers to configure the recommended basic security options:

• Require MFA for all users assigned to an admin role
• Disable legacy authentication
• Require MFA for risky sign-ins for all users.
• Require MFA for access to Azure management (portal, PowerShell, CLI)

These Baseline Conditional Access policies, when enabled, apply to all users – even if they don’t have the Azure AD premium licensing usually required for Conditional Access. However, the Baseline Policies never made it to general availability (GA) and have remained in preview. Now they have been depreciated and replaced with a new system called Security Defaults.

The Baseline Policies will be automatically removed from all tenants at the end of February 2020. The recommendation from Microsoft is to either replace them with Security Defaults or re-create them with standard Conditional Access polices if Azure AD premium licensing is available.

Hello Security Defaults

Like Baseline Polices, Security Defaults is freely available to all Azure AD tenants including those on the Azure AD free tier. It is configured through a single on/off setting that is buried in the Azure AD properties blade under a small link at the bottom of the page called ‘Manage Security defaults’.

Tuning it on automatically enables similar security settings on the Azure AD tenant as all the old Baseline Protection Policies did, with a few notable differences:

• Security Defaults are all or nothing – the is no granularity to only enable some of the functionality
• Security Defaults cannot be used with Conditional Access policies – you must disable one to use the other.
• Azure MFA can only use the app push notification method – this includes both admin and risky user sign-ons.

Just like the Baseline Policies, any users who are not registered for MFA will be given 14 days to complete the registration from the first time they sign-on after Security Defaults are enabled before being blocked from logging on.

Try not to break things

Security Defaults doesn’t support some of the more complex scenarios that might be common in larger organisations such as exclusions for ‘break glass’ emergency admin accounts or SMTP access for legacy on-premises or Multi-Function Device email.

If you have these types of requirements, and you have Azure AD premium licensing for all users, then Conditional Access may be a better fit for your organisation. The extra granularity and control of Conditional Access can overcome many of the issues with Security Defaults. However, this comes with an additional cost of complexity (as well as the licensing). It can be difficult to configure Conditional Access securely, whereas Security Defaults is one simple toggle switch.

Enabling Security Defaults will not break Azure AD Connect synchronisation as the AD Connect sync account is automatically excluded. But because of this, it is important that this account is only used for AD Connect sync, otherwise it could compromise the security of the tenant.

One area where Security Defaults standout, like the Baseline Policies before it, is that it enables compromised password detection for all users. Outside of Security Defaults this is reserved for those on Azure AD P2 licensing only as part of Azure Identity Protection. If a user’s password is found in a credential leak Security Default will require that the user changes their password before they can logon.

The downside is that if you are synchronising user accounts from an on-premises Active Directory you need Azure AD P1 licensing and password write-back configured for this to work properly, or if the user is off site they may be locked out until they can change their Active Directory password.

To enable or not to enable

Security Defaults could be a good fit for smaller organisations with an Office 365 tenant who don’t have licensing for Conditional Access, especially if all users are cloud only accounts. It provides a simple one click setting to enable a good level of user account security protection on a tenant, including some advanced features – all for free. But before you enable it you need to make sure that:

• All users have a smartphone with the Microsoft Authenticator app installed.
• If MFA has already been configured in your organisation, through the legacy Baseline Policies for example, then you need to ensure all users have the app push notification method enabled and registered before enabling Security Defaults.
• All users are using modern authentication – you don’t have any users or devices connecting over old clients like Office 2010 or the native Android mail client, or using protocols like IMAP, POP3 or SMTP.

It is recommended that all new SMB Office 365 tenants enable Security Defaults to start. In fact, Security Defaults are enabled by default on all new tenants created after October 22^nd, 2019. If you need to use features blocked by Security Defaults then transition to Conditional Access, most types of Microsoft 365 licensing will cover you for this.

For existing tenants using baseline policies you need to carefully asses if you can enable Security Defaults in your organisation or need to migrate to Conditional Access. Either way, you need to take some action to ensure that your Office 365 tenant retains that baseline level of protection from attack.