• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Azure AD / What are Azure AD Security Defaults, and should you use them?

What are Azure AD Security Defaults, and should you use them?

March 24, 2020 by Steve Goodman 5 Comments

Azure AD Security Defaults

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.

Azure AD

About Steve Goodman

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.

Comments

  1. Phil says

    June 2, 2020 at 10:22 pm

    Im not 100% certain on this s Ive not seen it specified exactly , but from what ive read on your post and elsewhere this seems to mean that if you turn on security defaults that ALL conditional access policies are unavailable and not just ones pertaining to MFA settings?
    It seems a pity that in a mixed licencing environment that you can’t take advantage of security default defaults for E1 /A1 users but continue to use CA and more flexible MFA settings for your E5/A5 users. Im my situation I have a few thousand A5s that we want to use more advanced settings for and tens of thousands A1 users that we would like basic MFA for but cannot afford upgraded licences for.
    Also, what happens with things like service accounts and other accounts you would like to omit from MFA with security defaults – is it possible to do that?

    Reply
  2. Tim Haegele says

    May 14, 2020 at 5:13 am

    Hello Steve,

    AD Security Defaults breaks SASL SMTP_AUTH. I dont knwo how to tackle this problem other than to disable it – or buying Azure AD Premium.

    Any idee?

    https://serverfault.com/questions/907219/office365-relay-postfix-authentication-unsuccessful

    Thanks for the great infos, Tim

    Reply
  3. Ben Davis says

    April 24, 2020 at 4:37 am

    Thanks for this article Steve I found it incredibly useful. How did you manage the users who dont have a phone with the authentication app? Did you face any issues with printers or app passwords?

    Reply
  4. Hal says

    March 27, 2020 at 1:48 am

    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).

    Reply
    • Steve Goodman says

      March 27, 2020 at 1:55 am

      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.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • The Practical 365 Weekly Update: S2, Ep 9 – Controversial Teams guest changes and a roundup of important Microsoft 365 announcements and features
  • Hands-on SharePoint Syntex Blog Series – Part I
  • The Practical 365 Weekly Update: S2, Ep 8 – What to expect in 2021, Solarigate, TLS in Exchange and new Teams updates
  • Security updates released for Exchange and SharePoint Servers 2010 to 2019
  • The Practical 365 Weekly Update: S2, Ep 7 – Urgent Exchange security updates, new Teams features launch
Practical 365

Related Posts

Related Posts

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials. Read more...

Find out more about advertising with us.

Contact us


Subscribe to our newsletter
  • Facebook
  • Twitter
  • RSS
  • YouTube

Copyright © 2021 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland