1. Introduction to Azure MFA
So in this section and the sections that follow, we’re going to talk about implementing an authentication and access management solution. This first section is specifically talking about MFA, or multifactor authentication. We’re going to talk about the other ways of managing user authentication, some of which are passwordless ways. We’re going to talk about conditional access after that. And finally, identity protection So this section of the course will talk about Azure MFA. You’ll notice that we’re talking about MFA but not MFA Server. We’re talking about MFA for the cloud. Microsoft used to provide an option called MFA Server, which has since been deprecated. And this exam doesn’t deal with MFA Server in any way, even though you might see references to it in the documentation and in the portal. So we have our Azure Active Directory, and of course we have our users that have signed into it. Now, identity is one of the main targets of hackers who try to find people’s user IDs and passwords, even if only to guess them or find them exposed through other means, and then log in as them. So identity is one of those vulnerable areas.
And so multifactor authentication aims to protect the identities of your users. It accomplishes this by removing the password as the sole method of authentication. And the concept of multifactor is that a password is just one of the factors; you’re going to have to have some other factor. The most common other factor that people use now is related to their phone or cellular device. And so you’re going to get an SMS text message, you’re going to get a phone call, you’re going to get an email, or you’re going to use an application like the Azure Authenticator to generate a secret code that you use to log in. And a lot of that stuff has to do with having possession of your phone, and the code might change every few seconds. As a result, real-time possession of the phone prevents people from simply knowing your password if they don’t have physical access to your phone, preventing this account from being hacked. There are now methods for forcing certain users to use multifactor authentication. So I could pick one of these teacher-users, and you’ll see that there is a per-user MFA option with this external icon. This represents a brand new website that needs to be opened in order to implement multifactor authentication for a single user.
So I can go into this teacher, let’s say this particular teacher, and enable MFA. Then I can go and enable it for that particular individual. Okay? So there is this ability to enable multifactor authentication for a single user. Now it might be wise to have an MFA strategy across your whole organization. When are you going to ask people to sign up for MFA because MFA is not something you can just turn on? I’ve turned on MFA for this one person. But then they have to register for it, right? They have to go, and they log in. They’re going to have to download the authenticator app, or they’re going to have to sign up for one of the other MFA methods that I’ve enabled. Okay, so this is sort of a hassle for this particular individual. But we should probably have a strategy across our entire organisation for who is going to be governed by this MFA.
Under what circumstances do we want them? Is it risk-based? Is it determined by the number of permissions they have if they are an administrative type user? Is it based on how frequently or infrequently they log in, etc. for So let’s switch back to the portal. I’m going to close this new screen here and go back to this portal, and let’s look at MFA settings on the whole. Now, MFA is actually not configured inside the tenant here. What we’re probably going to do is type “multifactor authentication” into the search box, and we’re going to see that multifactor authentication is its own standalone service, standalone. And again, we’re going to have to basically set some settings up so that we can enable multifactor authentication, and then we can set some rules around when it’s used, how long sessions last, etc.
2. MFA Settings
Alright, so let’s look at some of the settings for multifactor authentication. This screen contains a number of settings, such as lockout, fraud alert, and so on. We’re also seeing that you can talk about MFA servers here. And as I mentioned in the last video, MFAserver is deprecated as of July 1, 2019. And so you can’t do any new deployments of the MFA server. So we won’t talk about that here. There’s also a link to the MFA cloud settings, so why don’t we do that first? This is going to open up that external site. Remember, we were here looking at the user settings just a moment ago. So now we’re in the Service Settings tab. Under service settings, there are four major settings. One is for app passwords, trusted IPS verification options, and remembering MFA on a trusted device. Now we’re talking about trusted IPS here. We’re basically allowing users to skip multifactor authentication if we know that they’re running from their own location.
So you could enter your own IP addresses here. It’s not going to be ten dots, but let’s say your IP address range falls into that category for your corporate network. Users on your corporate network would not have to use this MFA. They could be trusted based on their location. in terms of verification options. Then we’re basically going to allow one of four methods. Either they’re going to get a phone call, a voicemail to their phone, a text message to their phone, or a notification through their mobile app, which could be, yeah, there’s a mobile app, and finally, there is some type of token or verification code. These are the four options that we can enable. Let’s say we don’t want them to use call-to-phone or text messages, and we must force them to use an app in terms of the verification code. This is the Microsoft Authenticator app, and that’s the code that changes every few seconds that they need to use. If you yourself have a mobile app, you could have the user be notified on their phone through the iOS or Android notification process using a push notification for your app text message. I think we’re all familiar with receiving SMS codes.
These six-digit, five-digit codes must come through the phone call in order for us to continue. Now each of these processes requires users to be able to set them up these.For example, if we said text message, the user will have to register their phone number the next time they log in, or they will have to download this app to get the verification code. Finally, just remember the authentication. If they are on a trusted device and they know they’re on a trusted device, they can click a link or a button that says, “I trust this device,” and the MFA will not kick in for this many days between one and 365 days. So this is not currently enabled. We’re not going to change any of these settings at this time. But we’re just going to see that this particular MFA portal has these settings here. If I close this and go back here to the Azure Portal, we can’t see there are still some other settings here. The account lockout is the most basic, where if somebody fails to log in, let’s say the MFA has denied attempts, they have the wrong code, the time has expired, or whatever. Then there’s a way of triggering a lockout, and maybe they give them 24 hours to be able to try again. Okay, so there are the settings in here. Now you can actually block users.
Let’s say you know a particular user has been hacked, or you suspect that they might have something up with their account. You can go in here and basically block users manually. Somebody says they lost their phone. Somebody calls your help desk and wants you to make sure that their account can’t be used. This isn’t here. There’s another option that’s interesting: let’s say somebody receives an MFA request on their phone and it’s not them. Right? So now they get this pop-up on the app for the SMS, and it’s like, “No, it wasn’t me.” And obviously, you can then allow them to submit that as a fraud attempt and basically optionally block that user. So somebody’s trying to log into their account. This idea of someone attempting to hack into my account is initiated by the user. The notifications are where, when users do have these fraud alerts, they’re going to be notified to.This could be your help desk ticket. This could be a manager’s email address or something like that. Now, Azure supports the use of OAS as a verification method. And these codes basically refresh every 30 seconds or 60 seconds. You could buy these devices.
They’re key fobs similar to those made by RSA and other companies. And you can register a user against the serial number model of these hardware devices. These are the tokens. Now we don’t use this anymore because we have the authenticator app, but for real security, you don’t want it to be based on the person’s personal phone. You can buy a security token and have that configured for the last two. So for the phone call settings, this is pretty basic. If you’re going to get calls, you could have a unique caller ID number. Microsoft has the numbers that they call from. But if you want it to be your own personal 1800 number, you could enter the number of PIN attempts allowed per call. So the phone calls them and asks them to enter this code. They put it in wrong; you can say, “Well, you only get two per call,” etc. And you can even have a greeting. So you can have a company-specific sound file that plays when you’re called. Hi there. This is ABC, Inc. Please enter your code. Whatever personalised greeting you want in there So those are your MFA settings. Again, part of this has to do with having a strategy for how hard you’re going to lock down MFA for all users, for specific users, and things like that. So we do have these options within MFA settings here.
