Welcome back here. In our next episode, we're gonna talk about multi factor authentication or M F. A.
The objectives include understanding what M. Fai is, how we can enable it inside of our edge, your tenant and then some of the configuration options we have available.
So first, what is M. F A. You might already be familiar with it, but let's cover some basics before we continue.
Multi factor Authentication is a layered approach to protecting and securing user identities. Instead of just having a password to access an account, M F requires having another piece of information to verify your identity. This can include additional authentication methods such as something you have or something you are.
That's something you have could be a phone or device key that has a PIN code that changes every 30 seconds, and the something you are could be biometrics, like a fingerprint or facial recognition.
So am affair requires the second form of authentication, while at the same time making it simple for user's. We learned in a previous episodes that Emma Fae can be combined with conditional access where you set up a policy such that if the user is on the internal trusted corporate network. Then maybe you don't require M f A,
but assumes the user leaves and tries to access. Resource is
from an external network. Mm facon be required. We could also requiring him if they prompt if we suspect the user account is at risk or exhibiting risky behavior.
And just recently, Microsoft published a block post talking about M F A. Being the best protection against account compromises by saying it can prevent up to 99% of attacks on the accounts. And this can be done by enabling multi factor authentication.
Definitely give these articles or read and understand why I m f A is so important.
Azure FAA comes in a few different forms and can requires additional licensing, depending on which one you use. First is the full featured azure M F A that comes with azure active directory premium licenses. Here you get all the features of azure M F. A, along with the ability to use conditional access to require M f. A for your users.
We looked at some of these policies in previous episodes and module two.
The next is Azure 80 free. Here you can use pre created conditional access baseline policies to require M F A for user's, and they're found when you view the conditional access resource inside of Azure.
Finally, we have azure M F A. For global administrators. I call this mini M F A. As it is a subset of M f A capabilities available for protecting your global admin accounts.
This is offered at no cost for accessing Microsoft Online service is like the Azure portal or Microsoft 3 65 admin center, and it only applies to users in the global administrator rule. This is an awesome feature, and it means there is no excuse for not protecting your most privileged accounts. And this is evident by Microsoft making
this many M F A free for user's in that role.
So how do we enable M F A for user's? It's pretty simple in something we've already discussed, and you can do it by creating a conditional access policy to enforce registration. When a user signs and access a resource, you can also combine conditional access policies and M f A with Azure 80 identity protection.
This is also a feature we talked about and module two
this can require MM registration or require completing an M f. A challenge if the user sign in is determined to be risky.
Another option we have is enabling M F A. Per user. This is considered an older enablement method where you went in and enabled it per user. This also required M F A to be completed by the end user every time they logged in, with some exceptions,
such as logging in from a trusted I P address or allowing the user to save their M f A response.
And remember the device. As I mentioned, this older enablement for M F A. Required enabling it per user. Or you could do a bulk enable by uploading a C S V file with the user name and M F A status as enabled or disabled for each user.
I only touch on this as it is an older enablement method, but it's something you should be aware of and familiar with if you're working inside of Azure.
If you do enable a user with this older method, it does require conversion to be able to use the conditional access multi factor authentication, and this is something you can do through as your power show, and I believe also the Azure cli.
Next. Let's talk about verification methods, and this is how your user is gonna be able to perform. The second factor. The user, when they register, will choose from a list of enabled options that you have configured inside the tenant.
The 1st 1 of these is a call to their phone number where the service calls the phone number that the user has registered and they simply respond to the prompt in order to gain access. You can also customize the verification phone calls, and I believe this does require additional premium licensing.
You can set the caller i D and the number of pen attempts allowed per call.
The next option is a text message to a phone number where it just gives a code that the user then has to input onto the sign in screen. And then next, we have two options that involved the Microsoft Authenticator rap,
where you get a notification through the mobile app that you then approve or deny, or you get a verification code that can change every 30 to 60 seconds. I believe that way the code is constantly cycled through and isn't repeated. The Microsoft, with indicator app, is available both for the iPhone and Android phones.
Next, we have trusted eyepiece, and these are trusted locations that you have configured, such as network ranges inside your corporate network. This allows bypassing the M F A prompt when the user is coming from one of these trusted I P addresses, and this is only available in the full version of Azure M F A.
And over on the right. The screen shot we have here is actually from the older M F A enablement process screen,
and we'll take a look at this in the demo as well.
For the conditional access version ofhim Buffet, we have the same concept, but with a different name called Named Locations. As I mentioned these air used with conditional access policies, and they're used to identify where Emma Fae can be bypassed, and this is also used for reducing false positives inside the
information as a part of identity protection.
And over here on the right, you can see you can name the different locations and define it based on an I P address range or a country or region and then market as a trusted location.
Next, we have fraud alerts and this really it just allows your users to report fraudulent Sinan attempts so they might get an M F A prompt, maybe a phone call, text message or something inside the app that they didn't initiate.
This allows the user to report that their account may be compromised.
This is enabled inside of Azure active directory, and there are two options associated with it. First, you can automatically block the user when they report the fraud,
or the user can just use their code to report the fraud. And this is for when the service actually makes that phone call that they prompt for they compress a special key, like zero or the pound sign to report the fraud during the call.
We could also configure a one time bypass option. This allows the user to bypass completing the M F A challenge one time
this is temporary and does expire after a certain amount of time. In this case, we can configure it in seconds. This should only be the option when the user account is not compromised. But for some reason the user cannot complete the M F A challenge
over here on the right of the screen shot, we have to put in a reason why we're allowing the bypass and the example They have his lost phone, which makes sense if they've lost their phone and are unable to complete them. F a challenge than putting in a one time bypass can allow them to access. Resource is until that is resolved.
And finally, one of the last things we have here are called at passwords and these air used inside of applications that don't support multi factor authentication.
A good example of this is older office applications like Outlook 2010. Instead of completing the multi factor challenge when accessing the resource, you use an APP password in place of your traditional password that's associated with your user account. Unfortunately, at passwords, do not work with conditional access,
and you do have the ability to enable or disable creation of at passwords by your users.
That does it for some of the basics of azure, M F A and some of the options. We can't configure for it.
I want to follow it up with a quick quiz question What two ways can azure M F A. B enabled?
We have the per user option, which is considered legacy at this point. And then we have the conditional access policy option, which is now the preferred method to do so.
Coming up next, we'll take a look at these options and how to configure it inside of our azure tenant with an M F A demo. See you in the next episode.