Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
“Why are my users not prompted for MFA as expected?”
Published Jun 08 2020 10:49 AM 91.1K Views

“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:

 

image.png image.png image.png

 

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. 

 

image.png image.png

 

 

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).

image.png

We can correlate that information with the AAD-issued certificate from the cert store on the device itself:

image.png

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.” 

image.png

“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):  

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-session...

 

  • 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.” :smile:   

 

HildePRT      

 

 

15 Comments
Copper Contributor

Thank you for the great content!

The video in the YouTube link is mirrored, no magic whiteboard involved :)

Copper Contributor

Hi Michael,

Great post! I indeed did not know about the MFA & PRT validity period.

I'm curious. What's your view on not having to fulfill MFA and the device gets stolen?

 

Brass Contributor

@Michael Hildebrand,

 

Any chance you are or know the person who can help me with a related question.... 

 

We use Azure MFA, we are at the final stage were we have risk based CA policies. Its great, MFA only prompts when Azure Security Graph feels its needed. However, we have a limited handful of tools like password vaults where we MUST MFA prompt every single time. No allowing 14 days, no using risk scores, MUST MUST MUST prompt for MFA. 

 

Please tell me there is some obscure thing we can put in the app registration manifest or strange powershell command we can run against the enterprise app entry to make this happen.  If there is not can we PLEASE have one? Its the only thing that stops us from dumping another MFA vendor we have.

 

If your not the right person would you kindly forward it on?

Brass Contributor

Thank you for blogging this.

Now, I know you're just a blogger, but I hope some smart people like Caleb Baker or others on the Azure AD/Azure MFA/Conditional Access product teams are reading and following me.

 

Now, to forward a question from the CEO, paraphrased:

"Microsoft can make such an overcomplicated, interconnected solution, but they can't force MFA on connection to the corporate VPN like every other vendor?"

We have placed an order to a competitor VPN vendor because of this problem. We're not ready for a complete zero-trust transformation, we need the corporate VPN, and our CISO and risk manager won't budge this need for MFA every time. We're government, it's just more complicated.

 

A very simple workaround would be for us admins to be able to ignore the MFA claim on the PRT for specific cloud apps, either on the cloud app itself, or in a Conditional Access policy. That way, I'd ignore the MFA claim for the "VPN Server" cloud app (automatically created by RRAS), and our users would get the ideal experience when connecting to the corporate VPN (given we still had Microsoft RRAS .. ).

 

Sign-in frequency isn't enough. Even if you set it to its minimum of 1 hour, it's still an entire hour where users won't need to perform MFA. To add, requiring users to input password is a bad experience. We require MFA for the VPN connection, but not necessarily password.

It isn't too late, I'm a big fan of RRAS, and a big fan of Azure MFA and Conditional Access. Get this out the door ASAP and save yourself a customer ;)

 

I mean, there are lots of other use cases where "just" ignoring logon is a policy nightmare. Password managers, identity/access management systems, internal documentation, etc. It shows some ignorance to customer demand if you "just" excuse the lack of MFA because there's a lot of conditions behind the scenes.

 

Azure MFA NPS Extension is the only alternative, and it's a bad experience. When initiating VPN connection, it simply idles, and there's no way for the user to know that they need to use the Authenticator app on their phone. It increases the need for education, and it requires the user to have Authenticator set up already, or it will just time out. As I said, it's a bad experience, whereas the WAM interactive sign-in dialog is much more user-friendly and can even get the user through Authenticator registration if needed.

Man - I have some catching up to do here ...

  • Filip - re: mirrored whiteboard - I tested it and I think you're right.  A darkened background, a bright pen color and 'just the right angle.'  Plus, I have it on good authority that Stuart isn't left-handed.  :cool:
  • Stefan - re: issue of stolen devices - physical possession of a device by an attacker opens up alot of 'what ifs.'  I don't claim to have the perfect answer but there are several options I could think of - for starters, I did a quick test and I locked out my device w/ 5-6 failed PIN attempts - that is the initial control.  Further, one could issue a wipe/reset or reboot of the device via MDM/mgmt tool, use the portals/PowerShell to revoke/invalidate the tokens, disable/delete the device object in AAD, disable the user, and/or reset the user's password.
  • ITEric and Kasper have similar comments - "we need a per-app option to always require MFA" - that requirement makes sense to me.  I am not 'in the know' of plans for that but I did find a UserVoice item that seems to get at what you're needing (I see Kasper's prior comment there already) - take a look and vote it up (our PGs keep keen eyes on UserVoice): https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/33405382-option-to-enfor... 
Brass Contributor

@Michael Hildebrand thanks for the reply. I have voted and commented there per your suggestion. I will still shamelessly beg you to raise it with those who actually might consider it. You must know who that is to have gained the insight this article has. Just pointing them at that user voice could do alot to raise its profile. Cheers! 

Brass Contributor

Thanks, great article! All the stuff under dsregcmd /status is endlessly confusing even after many attempts to learn it all, but this article helps a little!

Hiya freds123 - If you haven't seen these, have a look; they break down the elements in the output of DSREGCMD /status:  

 

https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-hybrid-join-windows-cur...

 

https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd

Microsoft

Nice work all, very good article indeed! Explains a thing or two I noticed in my lab yesterday... :grinning_face_with_sweat:

Thanks for sharing!

Brass Contributor

@Michael Hildebrand just wanted to say thanks for this article, it's really clear and helped me to get my message across to some senior stakeholders. I tried to give you a shout-out on twitter but the link in your bio here is dead and I couldn't find you!

Copper Contributor

Great article.  Very informative, gives a bit more confidence to the procedure... and entertaining.  Nice.

Copper Contributor

I created a CA policy requiring MFA, then I went to MySignins and signed out from everywhere, locked my device, signed in using WHfB fingerprint, tried to access a corp app and was challenged with MFA. Is this expected?

Copper Contributor

@Michael Hildebrand  I have most likely the same issue as Pablo has, my device is "Hybrid Azure AD joined" and proper registered. When I logon to the Azure Portal, which is MFA protected or any Azure services without MFA protection, I see a wired behavior of my claim. On the portal I still get asked for MFA, even if I use WH4B as authentication and in the Azure AD sign-in logs I realized , that under the chapter "Device Info" the section "Join Type" is empty. All other test users have there "Hybrid Azure AD joined" as a value and for them all is working as expected. We tried with dsregcmd /leave and /join to redeploy it, but no success. All the certificates are created during the join process as expected. Any idea what could cause the issue?

Copper Contributor

Very good article,

 

Came acress this article because one of my users challenged me why he didn't need to re-authenticate each day using MFA

I used your article and will check with the IT Manager if we need to shorten the PRT time due to the Security Policy 

Brass Contributor

I have a few questions:

 

If the option is still there to sign-in with a password does this bypass the MFA?

 

In Hybrid AAD there is a option for the users to skip the MFA prompts, so if an attacker had the password then they would be able to gain local access to that device and possibly access to local data and servers from there. This doesn't seem to prevent access to the devices or the on-prem resources. How is that done?

 

Why no Windows Hello for servers?

 

Version history
Last update:
‎Jun 08 2020 01:23 PM
Updated by: