In this video, Pete Zerger demonstrates how to optimize the user experience in Azure Multi-Factor Authentication (MFA) using trusted IPs, and how to support MFA with legacy applications using app passwords.
- [Instructor] I want to talk about two more components that influence our multi-factor authentication experience, and those are trusted IPs and app passwords. So trusted IPs is a feature of Azure MFA that administrators of a managed or federated tenant can use to bypass two-step verification for users that are signing in from the company's local intranet. I can actually get to trusted IPs in the newer classic portal.
We'll look at the path in the new portal here. So I'm signed in to the Azure portal. I've selected my Active Directory, and if I highlight Conditional access and Named locations, I'll see a Configure trusted IPs option. Name locations is an element of conditional access, an advanced topic we'll cover later in the course. For now, we're going to focus on this base MFA concept of trusted IPs. I'll click on the trusted IPs link, which will actually launch me into the classic portal.
And you'll notice we land right here on app passwords and trusted IPs, the two topics we're concerned about. And I will check the box by Skip multi-factor auth for requests from federated users on my intranet. And you'll notice here that there are some samples to show you the format with which you need to make these entries. So we can put up to 50 networks into the list here. And we're going to do it in the very typical CIDR format. So, for example, my 24-bit netmask there.
I could take this all the way out to an individual IP address if I wish by simply applying a 32-bit netmask. So, for example, when I'm working from home, maybe I trust my IP address at my ISP. I could put my public IP address with a /32 to mask all four octet, and now I have an exclusion down to an individual IP level. But the intent here is on a corporate basis, to allow us to eliminate those MFA prompts or users when they're in the office.
Those are simply going to be annoying and really don't do anything to improve security significantly. But we have a couple of options here, so specific IP ranges that you just saw me demonstrate here, just a range of IPs that skip that process. In federated scenarios, we also have an all-federated users option, which allows a bypass when using a claim issued by ADFS. In that federated scenario, that bypass'll only work from inside a company's intranet, so you can't accidentally bypass in the federated scenario outside the corporate network.
Do bear in mind this feature is only available will the full version of Azure Multi-Factor authentication, not the free version that works for administrators. So let's shift our discussion for a moment to app passwords. So some apps that were written before multi-factor authentication was common or maybe around at all, such as Office 2010 or older versions of Apple Mail, don't actually support two-step verification. They aren't instrumented to accept a second verification.
So to use these apps, you need to use an app password in place of your traditional password. The app password allows the application to bypass two-step verification and continue working. But let me just restate that. To use these apps, you need to use app passwords in place of your traditional password. So let's look at how we create app passwords. I'll go ahead and save or leave this behind.
To create an app password, I'm going to go to the MyApps portal. myapps.microsoft.com and I'll log in with my Azure AD user. So I'm already authenticated to the portal, so that token's still there, so I'm logged in as my Pete Zerger account. I'll pick my profile here, which brings me into my profile settings, where I'll find a link to additional security verification. This is the area where I can create app passwords.
I'll do that right up here. You'll notice app passwords is in gray. It's a little easy to overlook sometimes. So we'll click on that app passwords link, which brings me here to the app passwords page. So I'll click the create button, which will allow me to provide a friendly name for my app password. I will typically use a name that incorporates the device and potentially the app that I'm working with. The reason for this will become clear in just a moment.
So there you see an app password, a strong app password is generated for me. And now, I can use that in place of my traditional password on those legacy apps. A few things to know about app passwords, number one, they only need to be entered once per app. You don't need to keep track of them and enter them every time. Two, the actual password is always automatically generated, as you just saw, to ensure we have strong passwords. There is a limit of 40 passwords per user.
That should be many more than you'll ever need, because you should typically only be using one app password per device, not per application. For example, you can create one app password for your laptop and use that app password for all of your legacy applications on that laptop. Then create a second app password for use for all the legacy apps on your desktop. Now, there are a couple of exclusions there to be aware of, such as administrative actions cannot be performed using app passwords through non-browser apps such as Windows PowerShell.
You'll need to use a different account with a strong password for PowerShell without MFA enabled. And that is trusted IPs and app passwords.
In this course—the first in the series—Microsoft MVP Pete Zerger takes you through the basics of setting up endpoint protection. He begins by explaining how to set up Azure Active Directory Premium. Next, he goes into enabling multi-factor authentication, followed by setting conditions for secure access. To wrap up, Pete covers managing mobile devices with Intune, and publishing applications with Azure AD App Proxy.
- Setting up Azure Active Directory for an organization
- Enabling user-level and application-level multi-factor authentication
- Setting conditions for secure access
- Planning a mobile device management (MDM) strategy
- How Intune (standalone) MDM works
- How Intune mobile application management works
- Publishing applications with Azure AD App Proxy
- Assigning users and groups