[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]
