“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.
- Semi-related bonus link – Stuart Kwan’s YouTube ‘authentication basics’ vid - P.S. I’ve still not figured out how the “mirrored – but transparent” whiteboard he uses works.
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
- Something your user has - that device.
- Something your user knows (or is) – a PIN or a fingerprint or face scan
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:
- NOTE: The validity date/time here is for the certificate obtained during device registration – it is not the validity date/time for the PRT (that’s further below).
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.
- IMPORTANT: As the PRT is used/refreshed, the MFA claim persists (if there is one). See “Subtle point #5 above.”
“So what?”
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:
- THAT specific device (the PRT is not exportable and is bound to a single, specific device)
- THAT user’s completion of a prior ‘strong’ authentication, from THAT device? Check.
- Which means the user successfully logged in AND completed an MFA? Check.
- THAT device has been successfully AAD registered (at least) or AAD Joined or Hybrid AAD joined? Check.
- Which means it has requested and obtained a device certificate from AAD? Check.
- Which means it has been successfully AD joined? In the case of Hybrid AADJ, check.
- THAT device obtained a symmetrically encrypted session key from AAD? Check.
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):
- https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
- https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration
A few FAQs:
- Q – You explained that a PRT is a long-lived credential – how long lived? When do I get a new one?
- A – As discussed above, the PRT is only issued after strong authentication, so it is indeed a long-lived credential. Honestly, if you think about it, obtaining a PRT is WWWAAAYYYY stronger than setting a password. It is refreshed every 4 hours, expires after 14 days (if un-used). It is invalidated when the user’s password changes, the user or device is deleted or disabled.
- Q - What about MacOS, mobile, etc? Does a PRT get used by those?
- A – I’m not very deep in those platforms but rather than punt and say, ‘out of scope for this post,’ I’ll offer a high-level, non-developer answer.
- We embed the AAD authentication code or ‘libraries’ (MSAL) into certain apps to “broker” this authentication/SSO/PRT/MFA activity. Apps such as the Intune Company Portal, the MS Authenticator, as well as newer Office for Mac and Office Mobile apps can serve as broker apps. As we’ve discussed, strong authentication is tied to a specific device, so it requires device registration - which is why setting up the MS Authenticator app or connecting Outlook to your mailbox may require device registration in AAD. These authentication libraries/code can provide your Mac/mobile users a similar ‘easy to use, yet secure’ experience.
- Q – What about the ‘Sign-In Frequency’ setting in AAD? Can’t I use that to force a re-MFA? I really need to re-prompt my users.
- A – We’ve heard that feedback – some customer-requirements dictate more ‘active’ re-prompting of users. Silently extending the PRT and the MFA claim isn’t always acceptable. So, we improved the Sign-In Frequency control in AAD to also apply to the MFA. For example, if I use that setting to force a re-auth every four hours, in most cases. that will include a re-entry for password and a re-prompt for MFA. https://techcommunity.microsoft.com/t5/azure-active-directory-identity/manage-authentication-sessions-in-azure-ad-conditional-access-is/ba-p/1421687
- Q – I like the simplicity of Windows Hello for Business and passwordless but we have dozens of shift workers who sign in to shared devices and can’t use cellphones – what hope do we have?
- A – There are multiple solutions for passwordless sign in. Liju’s recent post here, covers FIDO2 keys.
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:
- Our official docs are just that – official docs w/ rigor and teams of people working to update/improve them as their ‘day-job.’ Official docs are usually very specific and scoped to a certain feature/capability and as a result, often don’t/can’t cover how multiple features/capabilities work together to form a ‘solution’ or address a ‘real world’ scenario. You, as the consumer of those docs, have to synthesize that information as you design your solution. Microsoft docs are very good and are continually clarified and updated/tweaked/edited as wording is improved, mistakes are fixed and capabilities change. Plus, similar to blogs, they are open for comments/feedback.
- Blogs – whether hosted behind a ‘microsoft.com’ address or elsewhere - are not official docs. They are usually ‘passion projects’ by people who want to communicate with peers and share knowledge and experiences. Blog authors put a lot of time/rigor into their posts but by the nature of a blog post, it’s usually not an official doc. Further, more often than not, a blog post is a ‘point in time’ article that grows stale over time (sometimes, quickly). Capabilities described in a blog may change over time; the docs for those capabilities will be updated but a blog likely won’t be (I know if you look at my older blog posts here, some have not aged very well ☹ and I’m too lazy to go update them all).
- Why am I stating the obvious? Two reasons:
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.” 
HildePRT
Microsoft
