Why Microsoft Requiring Multi-Factor Authentication for Privileged Accounts is a Good Thing

On June 22, 2018, Microsoft announced a public preview of a new security policy which will enable multi-factor authentication (or MFA) for Azure Active Directory “privileged accounts” (or administrator accounts), including most Microsoft 365 admin accounts. After the preview, they will automatically opt these accounts into the policy by default, adding a much needed layer of security to these accounts. Spanning Backup for Microsoft 365’s Sr. Product Manager Andy Rouse explains why this is a good thing in his newest blog post.

I couldn’t be more pleased with Microsoft. On June 22, 2018, their identity division announced a public preview of a new security policy which will enable Multi-Factor Authentication (MFA) for Azure Active Directory “privileged accounts” (or administrator accounts), including most Microsoft 365 admin accounts. After the preview, they will automatically opt these accounts into the policy by default, adding a much needed layer of security to these accounts.

This is an important, proactive step by Microsoft to protect the credentials of administrator accounts that have “the keys to the kingdom” to their customers’ Microsoft 365 environments.

These accounts, if compromised, can be used by malicious actors to wreak havoc on an organization and their data, and, in the worst case, shut them down indefinitely. Their credentials must be protected at all costs.

Many 3rd party applications (including backup applications) that integrate with Microsoft 365 and other SaaS products frequently require a customer to use application specific service accounts that aren’t tied to an actual user. And these accounts often need to have elevated, administrator permissions necessary to function correctly.

When vendors require service accounts to access Microsoft 365, the added protection of Single Sign-On (SSO) and MFA can’t be utilized. This creates a dangerous combination: service accounts with elevated privileges and no additional protection like MFA.

And to complicate the situation — this often means that the service account’s credentials must be stored by the 3rd party application to be used in the day-to-day functions. Even if credentials are stored securely and are encrypted when used by the application to authenticate, this still expands your organization’s attack surface in a big and dangerous way.

Now, if this isn’t setting off alarm bells in your head, it should be.

Here’s a good example of why. Late last year, Skyhigh Networks discovered a brute force attack specifically targeting Microsoft 365 service accounts.

They explain: “The reason this is so clever is that system accounts*, given their purpose,* tend to have higher access and privileges than an average account*. And, most importantly,* such accounts do not yield well to authentication frameworks like Single-Sign-On (SSO) or Multi-Factor Authentication (MFA) and are also subject to lax password policies*. These two aspects help reveal the motivation behind KnockKnock, (i.e.* attack a weak-link with the potential for elevated exploits*).”*

Does this affect Spanning Backup for Microsoft 365?

Not at all. Spanning Backup for Microsoft 365 uses OAuth 2.0, where a Global Administrator grants permissions to the application to access the Microsoft 365 APIs, which can then function independently of any admin credentials.

We’ve been backing up cloud native data in SaaS applications for a long time. In all of our applications, we utilize an app-only authorization model (or OAuth 2.0), where an administrator provides a one time authorization to an application, giving it permissions necessary to function. Once the authorization occurs, the application functions independent of any user credentials —meaning the 3rd party application is unimpeded by a password change or MFA until the permissions are revoked.

From the start, we built Spanning Backup for Microsoft 365 with security in mind. We worked closely with Microsoft to ensure that having an app-only security model using OAuth 2.0 was supported. It required much more work and complexity than relying on service accounts, but it was the right thing to do — especially for our customers.

In addition, we made a conscious decision to support the security choices our customers have made when it comes to authentication. These security configurations are sometimes simple, sometimes complex, and are often unique to each customer. For example, many require MFA across the board, or a Single Sign-On application to ensure identity is managed properly, or both.

The great thing about OAuth 2.0 is that Spanning Backup falls back on the security configuration that customers have with Microsoft 365 (or Google Workspace or Salesforce). And when industry standard protocols like this exist that enable 3rd party applications to work seamlessly and securely with SaaS products like Microsoft 365, there’s no excuse to not use them. The customer should never have to make this kind of security tradeoff in order to use a 3rd party application — especially a data “protection” solution.

When I see a company like Microsoft making a hard decision like this to protect their customers’ business critical applications and data, they have my full support, both personally and professionally. It’s one more step in the right direction toward securing all of our data that is in the cloud.

Microsoft 365 Backup and Recovery: Is it Necessary?