MFA! MFA! MFA!

There isn’t an information security professional currently employed in the field who will not tell you and anyone else that multi-factor authentication is the low hanging fruit that yields the biggest gains in improving a system’s security posture.

I’m presuming that everyone who is reading this has had, at least, one account that requires MFA. That’s the deal where you visit a login page, type in your user name, then your password (or had those filled in by a password manager, such as 1Password, Google Chrome’s, or Apple’s iCloud Keychain.), and then the system sends you another code through a different channel (such as mail, text message, or a separate application) that you have to enter into it.

I work in a K-12 environment, and getting MFA enabled for just staff accounts has been a bigger project than I expect it would have been in the private sector, as adding anything to the overworked and underpaid teachers who are now in, hopefully, the last chapter of the pandemic, could be a much bigger deal than it would be in other organizations. Fortunately, our staff accounts are Microsoft accounts, and Microsoft ‘s Conditional Access makes MFA incredibly flexible.

Goals

Diminish the number of successful, but suspicious logins into our Office 365 environment and drop unsuccessful suspicious login attempts to a lower priority of security concerns. This will also decrease the number of security issues that would follow a compromised account, such as phishing campaigns from internal accounts.
Accomplish this in any way that would be less of a burden on the teaching staff.

Previously, whenever a user login had appeared to be coming from California, or Canada, or Cambodia, would be a suspicious event. Do we have a teacher that is traveling? Do we have a staff member who is using a VPN at home? Or is this a legitimate security event?

And, we’d have hundreds of failed login attempts against a single user account, which was worrying as well.

With MFA - both of these situations are of less concern for our environment.

The second goal, making things easier for teachers is the larger challenge, as enabling MFA is very easy to do. To lead with a contrast, we also have staff accounts that are Google accounts. Enabling Google accounts with MFA has very little ability to customize when and who get MFA challenged at a login event. There is some, but not like with Microsoft’s Conditional Access.

Microsoft has the classic ability to just enable MFA as a requirement for per-user account. This is similar to how Google currently offers MFA. The way this works is whenever an account that has MFA required signs into anything in that environment - they must have that extra MFA step of putting in the extra code.

Microsoft’s Conditional Access works sort of like a login firewall, if condition X is met during a login event - MFA needs to happen, if it’s not, no MFA is required. This allowed me to create these conditions:

  • If the device signing into O365 can be established as a Windows 10 device, hybrid joined to our Azure AD environment, no MFA is required.
  • If the device signing into O365 is attempting to sign in from our public IP addresses, no MFA is required.

What this means for teachers and is:

  • If they are using their district issued computer at home (or anywhere in the world), nothing changes for them how they use their computer.
  • If they are using a personal device at work, nothing changes for them how they use that device.

Only if they are using a personally owned device off of our networks does MFA come into play. With the exception of someone who is dedicated enough to crack into one of our staff accounts using IP spoofing, this should shut out the overwhelming majority of suspicious login events.

The summary of this is that there are plenty of our staff members that likely will not have even noticed that MFA has been enabled.

As a post-script, the program that is attempting to sign into the Office 365 (or Azure) services has to be able to confirm with Windows 10 to know that it is a hybrid joined device. Modern versions of Outlook, for example, have this done easily. Web browsers, on the other hand, may or may not, be able to do this. Fortunately, for our environment, Chrome, Firefox, and Edge are, in that order, the popular web browsers.

  • Chrome can have this working with the addition of the Windows Accounts extension published by Microsoft. We were able to deploy this through forcing the installation of the extension through Google Admin. This does require that the staff member is signed into their organizational Google account in Google Chrome, but this is already so common that it is barely an ask.
  • Firefox actually has had this baked into itself for quite some time. Enabling Windows SSO under settings is a single checkbox. To make things even easier for our staff, I used Microsoft Endpoint to force this setting to be enabled. The Mozilla project provides very straight forward instructions for how to use their published ADMX to achieve this through Microsoft Endpoint.
  • Edge is just a matter of signing into the O365/Azure account.