auscros.blogg.se - 365 security defaults

If you created your Office 365 / AAD tenant after October 2019, then these policies are already enabled by default. If you are an end-user of Microsoft products, there’s a good chance you wouldn’t have heard of them before, mainly if you are a new Microsoft customer.

Requires that all actions targeting administrative API’s in Office 365 and Azure demand an additional MFA prompt.

Blocks users from using legacy authentication options when accessing Exchange Online, via older versions of Microsoft Outlook or using protocols such as POP3/IMAP.

Enforces MFA for every user account on the tenant.

That’s why Microsoft has introduced security defaults, a simple option that, once enabled on your AAD tenant, does the following: In short, trying to do the right thing becomes more of a chore and, as expected, is something that never gets addressed adequately. Typically, the steps involved here would be distinct and laborious - enable and deploy multi-factor authentication (MFA) here, run some scripts to allow a secure mode of authentication over there etc.

Ideally, organisations wish to ensure that they’re enforcing a “basic” set of options for each cloud identity, to reduce the risk that any attack may pose.

With the rise of phishing attacks, the proliferation of breached lists containing, in some cases, millions of user name/passwords and general concerns that a cloud-first IT strategy naturally brings to the table, security becomes a real challenge. Therefore, I thought it might be useful to do a post where I discuss and highlight some of the issues you might face when you enable security defaults for the first time on your tenant. Recently, as our Gold Partner consultancy practice has gone live with enforcing security default policies on Azure Active Directory (AAD), we’ve had to grapple with some interesting “gotchas” that arose.