[MUSIC]
Jeff Bley: Welcome. My name is Jeff Bley and I’m a Program
Manager on the Identity Customer Experience team.
Today, we have a very important topic to discuss—how to
upgrade your security with multi-factor authentication or
MFA.
So, we’re going to start out with the fundamentals of what
MFA is why we need it. Next, we’ll cover what Azure MFA
offers as well as how to leverage Azure MFA using conditional
access. We’ll discuss how you can protect even on-prem
resources with Azure MFA before wrapping things up with
the demo and going over some best practices.
So, let’s start with the fundamentals.
Multi-factor authentication is the combination of two things:
something you know, something you have, and something
you are. Something you know is most commonly a password
or PIN. Something you have can be a phone, smart card, or
hardware token. And something you are is typically a biometric,
such as your face or fingerprint.
So, today, the most common use cases a company has users
that only have passwords and they want to secure access by
requiring a second factor, which would normally be
something you have or something you are.
Now, I want to go over some of the licensing considerations.
There are several versions of Azure MFA available today.
The first is MFA for Office 365. This allows admins to require
users to perform MFA at each sign-in. This is also called per
user MFA.
Next is MFA for Azure AD Global Administrators.
Due to the sensitive nature of Global Admins, they
should be protected by MFA at all times. Compromise of a
Global Admin account means compromise of your entire
tenant. So, we provide MFA for these users at no cost.
Third is Azure Multi-Factor Authentication. This version
gives the most granular controls over MFA, such as using
conditional access. With this, you can define a specific set
of conditions under which users are required to perform
MFA.
Lastly, I wanted to mention the MFA server. This was a
server you would deploy on-prem that services could call
to perform MFA. However, as of July 1st, 2019, we no longer
offer new deployments.
So, let’s talk about why we need MFA. In July of 2019, Alex
Weinert wrote an article titled, Your Password Doesn’t
Matter. In it, he describes many common attack vectors
hackers use, and in all of them the conclusion is that
passwords can be easily compromised.
I’ve highlighted three that I want to talk about. First, there’s
breach replay. Because many people have hundreds of
accounts, it is very common to reuse usernames and
passwords across multiple services. It’s possible that users
have used their company’s username and password for
another service. This means that if a third party’s database
is breached, it can act be your company’s corporate credentials
that are stolen and can then be replayed against your company’s
resources.
Next, there’s phishing. Phishing involves users receiving an
email that asks them to click a link and provide their
credentials. This is usually accomplished by including an urgent
message. For example, it might say, you must login and
verify some information or your bank account will be frozen.
No one wants this to happen, so they might unwittingly click
the link and give their exact password away.
Lastly, I want to discuss password spray. In this attack,
hackers will try common passwords across a large number
of accounts. This typically has a success rate of 1%.
Now, that might sound like a few. But when your company
has hundreds of thousands of users, it means thousands of
breached accounts.
Password complexity requirements aren’t much use to
prevent this because people often fall into pattern behaviors.
For example, requiring an upper case, lower case, number,
and special character may seem like a good idea, but it can
lead users to capitalizing the first letter of the word followed
by 123 and an exclamation mark.
Between this and requiring users to rotate their passwords
periodically, this actually makes passwords less secure.
When people are forced to follow these complexity policies,
most users will pick a password that is easier to remember
and, therefore, easier to guess. For this reason, Microsoft
recommends turning off complexity requirements and
expiring passwords.
In addition, you should enable password protection, which
will prevent users from creating common passwords in the
first place.
Now as you can see, there is a 279% increase of security
incidents from 2016 to 2017, of which 81% of hacking
related breaches leveraged either stolen and/or weak
passwords. So from these statistics, you can clearly see
that attacks are only increasing and that the vast majority
of them are due to passwords being compromised. The
good news is that by enabling MFA, you can decrease the
risk of this happening to your users by more than 99%.
Now, you can use Azure MFA to protect not only your
cloud resources but also resources hosted on-prem. This
can include Office 365, Azure resources, SaaS, and
custom applications, and on-prem applications published
through Azure application proxy, AD FS, or other partner
products that can be integrated with Azure AD.
Now, let’s discuss what Azure MFA brings to the table.
First, there’s the Microsoft Authenticator app. This app
supports push notifications, as well as OTP codes for when
your phone doesn’t have connectivity. This is the most
secure and convenient method available today. If your
users don’t want to download an app, they can use their
phone numbers to do phone call or text message based
MFA. And if your users don’t have a phone or if there are
use cases where they’re not allowed to have a phone,
Azure MFA also supports OATH hardware tokens. These
hardware tokens generate rolling one-time passcodes
and don’t require any internet connectivity.
Now, I want to briefly talk about how Azure MFA works.
In this example, we have a user who is trying to access a
SaaS application that is protected by Azure MFA. First,
the user tries to access the app and because they haven’t
authenticated yet, they’ll be redirected to Azure AD. Azure
AD will then validate the user’s password either natively
in the cloud or through a federated identity provider.
At this point, Azure AD recognizes that MFA is required and
makes a call to the multi-factor authentication service, which
then challenges the user for his or her default MFA method.
The user then completes the challenge and is redirected to
the application which then grants them access.
Now, the best way that you can leverage MFA is using
conditional access. Conditional access is a topic that requires
more time to cover in-depth, but at a high level it has two
parts—assignments and access controls. Assignments define
who is in scope of the policy and under what conditions,
while access controls define what requirements the user
must complete in order to be granted access.
So by leveraging conditional access, you can create policies
that granularly define the who, when, and where of requiring
MFA based on risk, device state, location, and other factors.
Additionally, you can set controls around how users perform
their initial registration of their security information. This is
designed to help mitigate users who exist in your directory
but have not yet registered for MFA. If these users are
compromised, a bad actor can potentially register their own
MFA information. With conditional access, you can prevent
this by requiring users to register from a trusted device or
require another access control.
In addition to Azure MFA, you can also leverage third party
MFA providers using custom controls. When you create a
custom control, a new option appears in access controls
within conditional access. The way this works is that after
a user validates their password, conditional access makes
a call to this third party provider. The provider will perform
its own checks and respond back as to whether or not
the users successfully completed the requirements. Azure AD
will verify the response and if it’s successful will continue its
own authorization flow.
Now if you’re just beginning your journey, you may be
wondering how users will register for MFA. Before I explain,
I’d like to provide some background information.
When MFA and self-service password reset or SSPR came out,
each had its own registration experience. This means there
would be two places where a user might have to input the
same information, such as a phone number. Today, we give
you the option of opting into a combined registration
experience, which allows users to register for both MFA and
SSPR in a single unified flow. This new experience is much
more intuitive and user friendly, and I highly encourage you
to enable this in your tenant. It can be rolled out gradually
based on groups and you don’t have to be using both MFA
and SSPR to enable this. It can work with MFA or SSPR
individually.
Now, let’s discuss the specifics around when users will
register. If you have identity protection, you can enable an
MFA registration policy that will prompt a user for MFA at
each login. They’ll be given the option of clicking skip for
now for up to 14 days, after which they’ll be forced to
register. If you’re using conditional access, users will be
prompted to register the first time they try to access a
resource that requires MFA. And lastly, you can always
encourage your users to self-register
at aka.ms/SetupSecurityInfo if your users are enabled for
the combined registration experience. Or if they’re still
using the older experience, they can go to
aka.ms/MFASetup.
Now, let’s talk about how you can protect your on-prem
resources.
Azure MFA works natively with AD FS 2016 and later. So,
many applications that authenticate directly to AD FS can
require Azure MFA. We also offer an NPS extension that
allows you to protect radius based apps, such as a VPN,
with Azure MFA. Lastly, you can securely publish your
on-prem applications and protect them with all of Azure
AD security features using Azure application proxy or using
one of our partner integrations.
Now, I’d like to show you some of this in action.
In my test environment, here you see under identity
protection that I’ve enabled the MFA registration policy.
This is requiring all users except for a few to register for
Azure MFA. Now when I go to Azure Active Directory, I’ve
created a very simple conditional access policy.
This policy is scoped to all users who are trying to access
either Microsoft Teams or Exchange Online. And when they do
so, I’m requiring them to perform multi-factor authentication.
So now, I’m switching over to a new user who has not yet
registered for multi-factor authentication.
And I’m signing into myapps.microsoft.com.
Now as you can see, it’s prompting him to register for MFA.
If I wanted to, I can click skip for now for up to 14 days.
But for now, I’m going to go ahead and click next.
This is what the new combined registration experience
looks like. As you can see, it’s prompting me to install the
Microsoft Authenticator app. If I didn’t want to use the
Microsoft Authenticator app, I can choose to use a third
party’s Authenticator app, however, this will only work
for the one-time passcodes and will not work for the push
notifications. If I didn’t want to use an Authenticator app,
I can choose, I want to set up a different method and
switch to something like a phone. But for now, I’m going
to cancel that and choose next.
Now within the Microsoft Authenticator app, it’s telling me
to add a work or school account, which within my own
application I am doing. And it is turning on the camera of
my phone. Now when I click next, it’s having me scan the
QR code, which I have just done. I click next.
And now, it’s going to send a test notification to my phone
and on my phone, I see either approve or deny. I’m going
to hit approve.
And that successfully completed. I hit next. And now, I’ve
successfully registered for multi-factor authentication.
Now, there’s one more thing I wanted to point out that
within Azure Active Directory, if you want to see statistics
about how many of your users have registered for MFA,
you can go down to
usage and insights under authentication methods activity.
And here are some good statistics in terms of how many
users have registered for MFA, as well as some other statistics
around self-service password reset and the methods that
they’ve registered for.
So now that you’ve seen how easy it is for users to register
for MFA, I’d like to cover some best practices as you roll
this out to your users.
First, again, I highly recommend enabling the combined
registration experience. This will give users the most intuitive
experience and it can be used to register the same information
in both MFA and SSPR. Second, use conditional access to
require MFA. This will allow you to require MFA only when
necessary. The reason you want to reduce MFA prompts is
because you don’t want to train your users to have what I
call MFA muscle memory.
If the user gets used to doing MFA every day multiple times,
they are more likely to be phished or automatically approve
MFA prompts. Whereas if users rarely have MFA prompts,
they are more likely to pause and think about it and then take
the right course of action. The north star should be one prompt
per user per device per password change.
To further reduce MFA prompts, you should do things like
enabling single sign-on, Azure AD joining or registering
devices, and giving users passwordless authentication
options. Third, create risk based policies with identity
protection. Microsoft can analyze the signals from authentication
attempts and use machine learning to determine how risky a
sign-in is. You can then require these attempts to perform
MFA as needed based on the risk level. This is a great way
to put MFA in front of malicious attempts without prompting
the legitimate users. Lastly, use the Microsoft Authenticator
app over traditional text or phone based MFA. This is the
most secure and most convenient MFA method for users.
You can use it even if your phone has no connectivity and it
can be used for passwordless authentication if you enable it
in your tenant.
I hope this has helped you understand the importance of
protecting your users with multi-factor authentication.
There are some links I’d recommend you look into. The first
is aka.ms/mfadocs. This is a general overview of how
multi-factor authentication works. Next is
aka.ms/securityinfodocs. This has information about the
combined registration experience. Then there’s
aka.ms/securityinfoguide. This provides documentation that
you can give to your users and will help them walk through
some of the steps. And lastly, I encourage you to refer to
our deployment guides for more details about turning on
these products, which can be found at aka.ms/deploymentplans.
Thank you for joining me today and good luck with your MFA
projects.
[MUSIC]