“MFA” or ‘Multi-Factor Authentication’ is a process where something more than just a username and password is required before granting access to a resource.
This could be a one-time code sent to a user’s cellphone via SMS text, a phone call to a user’s office/desk phone, a one-time code ‘pushed’ to a mobile app on a cellphone, a code on a physical ‘fob’ (also known as an OATH token or hard token). More recently, biometrics have come into play, too, with MFA – perhaps you use your thumb/fingerprint or a retina or face scan, instead of (or in addition to) a phone call or text.
In any event, your ID and password alone aren’t sufficient to access a system/resource.
You’ve likely set this up for bank accounts, credit cards or other financial transactions (and maybe even work, too). This has helped make those services/transactions much more secure. Now, if someone knows/guesses/buys your password and email address, that’s ‘not enough’ to get into your account.
We’re going beyond MFA, too, where the idea is to not even require a password anymore – use other technologies to make sign-ins easier AND more secure - at the same time. For example, below, our ‘passwordless sign-in’ capability sends a prompt to the PC with a number, then moments later, the MS Authenticator app on a mobile device prompts for a number-match, followed by a biometric:
Starting back with the Jericho Forum, the corporate IT world has been moving towards a “zero trust” model where Identity is the initial control point (vs the network perimeter/firewall). This isn’t only your people (and their credentials) but the devices in your org also have an “identity” and are part of the access control system, usually completing mutual authentication, often based on PKI. If you think about it, this makes sense, but is often taken for granted and it might not be obvious - a user needs a device to access a system or service. We’re not yet able to plug humans directly into the Matrix.
Hardware technology advances have made the Trusted Platform Module (TPM) or similar technology almost ubiquitous in PCs and mobile devices. These provide a secure enclave for credential material that is ONLY present/stored/available on a given device. Information secured by a TPM isn’t technically exportable – if a TPM is used to secure a credential/key on a device, that credential only works on that given device.
While all this has been going on, teams at Microsoft continue to create/develop/iterate technologies and solutions such as Windows 10, Windows Hello for Business, Azure AD, and on-prem Active Directory. Further, this work includes on-going collaborative engineering between those teams. As a result, we have some really great interoperability across our services/products that you may or may not be aware of.
One such integration occurs when a user signs-in to (or unlocks) a Windows 10 PC via Windows Hello for Business (WH4B) – screenshots below. This quick and seemingly uneventful sign-in process results in the user/Windows 10 device obtaining a new type of cloud-aware credential from Azure AD known as a “Primary Refresh Token” – or PRT. This is similar to the idea of a Kerberos ticket you’d get on-prem from an AD Domain Controller running the KDC. Before Kerberos, NTLM and Windows NT PDC/BDCs were the rage. From the cloud-era, we add web authentication, tokens and Azure AD to the list of authentication systems.
Subtle point #1 – The act of signing in with Windows Hello for Business requires so little effort that, to most people, it seems like nothing happened, let alone a ‘strong authentication.’
“That’s it? That seemed like it was even less secure than a password?? Only a glance of my face or a short PIN?? How can that be more secure than a long, complex password?”
Subtle point #2 - Windows Hello for Business sign-in is a form of MFA
Subtle point #3 – After Windows Hello for Business sign in, the PRT has an added element (or ‘claim’), indicating that the user completed MFA.
Subtle point #4 – Azure AD honors the MFA claim from WH4B sign-in - just as it would any other ‘typical’ MFA (SMS text, phone call, etc.).
Subtle point #5 – The MFA claim will persist in the PRT, as long as the PRT remains valid.
Subtle point #6 – The Azure MFA service isn’t involved in this MFA process – so, if users don’t/can’t use cellphones, or the location doesn’t have good cell signal, or whatever, you can still have successful MFA (including AAD Conditional Access).
Subtle point #7 – There are a lot of technologies interwoven with this and each has a lot of variables (device registration level; managed vs federated; TPM vs no; version of Win10, etc.). I’m not attempting to go into the depths of these here; I am merely discussing the end-results; the fruits of your labor.
More on the PRT
This PRT has a variety of info about the user and the device – you can review the PRT from CMD or PowerShell console: DSREGCMD /status
For example, below, we see the device in the screen shots above is Azure AD Joined (= “YES”) and we see some of the information from the certificate the device obtained from AAD during the AAD Join process:
We can correlate that information with the AAD-issued certificate from the cert store on the device itself:
We can also see the validity and expiration dates for the PRT – however, the PRT will refresh if the device is in use, so the expiry time will continue to ‘slide’ into the future.
With this information in mind, you might be thinking just that: “So?”
So, when this user attempts to access a resource that has an Azure AD Conditional Access Policy requiring MFA, Azure AD silently “sees” the PRT and the existing MFA claim – and the user won’t be prompted for MFA.
Your user MFA’d - without knowing it. No pop-up. No phone call. No SMS code to put in. Just the act of looking at the PC completed the MFA. In terms of level of effort, is there anything easier than looking at something?
This is all due to the ‘under the covers’ interop between Windows, the TPM hardware, Windows Hello for Business, Active Directory and Azure AD. Here’s a special ‘shout-out’ to those people in the Microsoft Product Groups who made this possible.
Now, be honest. Did you know that? I bet at least some of you didn’t. Sure, you may have seen the behavior - and possibly even been puzzled by it. Hence, the title of this post.
“WRONG Hilde. Wrong. SO wrong. I don’t have Windows Hello for Business setup and my users are still not getting MFA’d as expected?”
Ok, not everyone is using Windows Hello for Business yet. However, recall the PRT. It’s not the “Windows Hello for Business PRT” it’s just “the PRT.” The PRT and “Modern Authentication” makes end-user’s lives easier, even without Windows Hello for Business.
Let’s look at the same scenario but without WH4B. A user signs into a Hybrid AAD Joined Windows 10 PC with a username and password. The user attempts to access a resource that has the same AAD Conditional Access Policy requiring MFA as our prior example. The first time that access attempt happens, AAD sees the PRT but it does NOT have the MFA claim (no Windows Hello for Business and no prior MFA). As part of the authorization (authZ) that comes from the AAD CA policy processing, the ‘require MFA’ control fires off – and the user gets an MFA prompt. Assuming the user completes the MFA, AAD “stamps” the PRT with the MFA claim. Now, going forward, on subsequent access attempts requiring MFA, AAD sees the PRT with the MFA claim and says ‘I see you already did your MFA. I won’t prompt you again.’
“If that’s the MFA dream, I’m living the MFA nightmare. I’m not even getting MFA’d when I access the app the first time?? Either Azure MFA is broken, or my CA Policy is jacked up.”
There is one more interplay of technologies we’ll cover here for this PRT + MFA business … and that is device registration. If you register/join a device to AAD (i.e. Intune enrollment or setting up the MS Authenticator) and there is an MFA tied to that device join/registration process, that establishes this device-bound strong authentication (PRT + MFA claim). From that point forward, from that device, AAD will see the PRT and the MFA claim - and honor it. Silently. That user will get few (if any) MFA prompts afterwards – until a password change or the device isn’t used for a while (the PRT expires on its own after 14 days of inactivity but it’s continually refreshed if it’s in use).
“Wait? I don’t get re-MFA’d?? One MFA prompt and that’s it!? I paid good money for this – I want my prompts!”
Hang on … let’s review some of the conditions that need to be met for Windows 10 to obtain that PRT with the MFA claim:
To me, that’s more than ‘good enough.’ There is more technical depth to it, but I think you get the point.
Don’t take my word for it though. Recently, a large customer of mine (180k users in AAD) expressed significant angst when their users weren’t getting MFA’d as they’d expected (that convo was the tipping point for me finishing/publishing this post). Once I explained what’s really going on under the covers, they realized the strength of Modern Authentication and their angst turned to glee. There should be more glee in IT.
More depth (these are excellent docs, by the way):
A few FAQs:
I hope this helped shed some light on a topic that comes up very frequently. If you weren’t aware of these layers of technology working together to help keep your users happier (easier logins; fewer pop-ups) and your org more secure (strong, compound authentication), now you know.
A special thanks to several who helped in discussions around this topic: Ross, Amit, Ravi, Daniel, Dale Kim, Paul Bowden and JJ Streicher-Bremer. Those people were invaluable in the formation/review of this post and brought up some points that I wanted to share/remind:
1) It’s good to remind people that “blogs aren’t docs” - even though I work for Microsoft, in a technical role, and I try REALLY hard to make my posts accurate and complete, these blogs are my own thoughts/opinions/experiences. They’re not official docs. I try to provide information that can help in understanding/using technology but “your mileage may vary.”
2) There have been instances where “Microsoft blogs” differ from “Microsoft docs” - and this has caused confusion – or worse. How things work ‘today’ may not be how things work ‘tomorrow.’ Change is constant. Do your due diligence. Use your best judgement. Test. Test again. Read blogs. Read docs. And as my dad used to say, “Don’t believe everything you read.”
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.