The Primary Refresh Token: mostly strong

Does the Primary Refresh Token (PRT) on an Azure AD Joined Windows 10 device satisfy an Azure AD Conditional Access MFA requirement? Most of the time, with some exceptional cases when it doesn’t. Microsoft explains under what circumstances the PRT gets the MFA claim and is thus able to satisfy a Conditional Access MFA requirement. Let’s take a closer look.

How to tell

Depending on the Windows sign-in (Password, FIDO2 key, Windows Hello), there is more than one PRT for a user. The PRTs can be told apart by looking at the time stamp for the AzureAdPrtUpdateTime or the AzureAdPrtExpiryTime from the “dsregcmd /status” command as shown in this 1:05 video.

The video shows how Windows is unlocked three times:

• first, using the password,
• second, using a FIDO2 key,
• third, using the Windows Hello PIN.

The “dsregcmd /status” command shows three different time stamps, one for each PRT.

Set up Azure AD Conditional Access to require MFA. Sign in with an Azure AD account on an Azure AD joined Windows 10 device, open the Edge browser (with the setting “Allow single sign-on for work or school sites using this profile” enabled) and clear all the cookies. Authenticate to Azure AD, for example by opening https://portal.office.com; the Edge browser will use the PRT for authentication. The following 2:40 video shows this.

The video shows how the web page https://portal.office.com is opened three times:

• first, after a Windows sign-in with the Windows Hello PIN,
• second, after a Windows unlock with the password,
• third, after a Windows unlock with the Windows Hello PIN.

Because the cookies are cleared each time, the Edge browser uses the respective PRT. There is an MFA prompt for the second case because the PRT does not contain the MFA claim. The PRT does contain the MFA claim in the first and third case.

The PRT, as it is transferred by the Edge browser to Azure AD, can be seen with the help of the developer tools (F12). A GET request to https://login.microsoftonline.com/common/oauth2/authorize contains the PRT in the “x-ms-RefreshTokenCredential” HTTP header field.

MFA Imprinting

There are cases where a PRT without MFA claim gets imprinted with the MFA claim. This happens during an interactive Web Account Manager (WAM) sign-in. Clearly, it depends on the client application and on the authentication library whether or not a sign-in occurs via WAM. How can MFA imprinting be seen in action? Luckily, the OneDrive application can be used to help to understand the MFA imprinting effect via a registry key:

• [HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive] “EnableADAL”=dword:1 –> WAM is used
• [HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive] “EnableADAL”=dword:2 –> WAM is not used

The following 3:00 video starts off in a Windows session that was started with a password logon and a PRT without the MFA claim. First, a OneDrive sign-in is shown with the registry key set to “2”:

• The “Windows.Internal.Security.Authentication.Web.WamProviderRegistration” registry key was not accessed by OneDrive.
• The Edge browser presents an MFA prompt when authenticating with the PRT.
• The PRT is unchanged: the expiry time is the same as before.

Then, a OneDrive sign-in is shown with the registry key set to “1”:

• The “Windows.Internal.Security.Authentication.Web.WamProviderRegistration” registry key was accessed by OneDrive (shown in Process Monitor).
• The PRT is changed: the expiry time is different.
• The Edge browser does not present an MFA prompt when authenticating with the PRT.

Obviously, MFA imprinting has taken place.

Process Monitor in this video uses the filter “Process Name contains onedrive” and “Path contains Windows.Internal.Security.Authentication.Web.WamProviderRegistration.”

There seem to be several registry keys that can be used as indicators for sign-ins via WAM, this [HKLM\Software\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Internal.Security.Authentication.Web.WamProviderRegistration] is one of them.

Some side notes regarding MFA imprinting:

• In my test lab, I could observe MFA imprinting by way of
  • a successful Windows Hello for Business setup (tested on 20H2 and 21H1),
  • signing in to the Edge browser (with the Edge browser as native app),
  • signing in to OneDrive,
  • signing in to Teams,
  • signing in to Outlook,
  • signing in to Excel.
• Signing in to a Web app (like https://portal.office.com) in an Edge browser session does not produce MFA imprinting. Quote: A PRT is only issued and renewed during native app authentication. A PRT is not renewed or issued during a browser session.
• The MFA imprint is carried forward with a PRT refresh.
• I was unsuccessful at trying to get rid of the MFA imprint while the device remains enabled in Azure AD. In my test lab, a new PRT from a password logon contains the MFA claim even after letting the previous PRT expire (2 weeks inactive) or after revoking (Revoke-AzureADUserAllRefreshToken) the previous PRT. If you know of any way that the MFA imprint can be lost while the device remains enabled in Azure AD, please let me know in the comments.

Windows sign-in with Windows Hello or with Fido2 key

After a sign-in with Windows Hello or with a Fido2 key on an Azure AD joined Windows 10 device, the PRT contains the MFA claim.

Windows sign-in with password

There are three ways (I am aware of) that MFA can be required for Azure AD join:

• Per-user MFA
• Device settings
• Conditional Access user actions

After a sign-in with the password on an Azure AD joined Windows 10 device, the PRT contains the MFA claim

• if the user signs in who had originally joined the device to Azure AD and the Azure AD join had taken place with MFA,
• or after MFA imprinting has taken place.

Summary

It is not so easy to have a PRT without MFA claim: sign-in with the password as a user who did not join the device to Azure AD with MFA and avoid anything that leads to MFA imprinting. So, on a standard Azure AD joined Windows 10 device, the PRT contains the MFA claim virtually all the time for the regular user. MFA fatigue is not a problem because the MFA claim in the PRT prevents interactive MFA prompts. Consequently, there is no downside in always requiring MFA and compliant device from fully managed Azure AD joined devices in Conditional Access.

But there is a clear upside to requiring MFA in addition to compliant device: assume only “require compliant device” is set up in Conditional Access. Also assume the organization has 10.000 users and each user has an Azure AD joined Windows 10 device. A malicious attacker has compromised the password of User1, but cannot complete MFA for User1. Now the malicious attacker can steal just any of the 10.000 devices and use it to log on as User1. The PRT will not satisfy the Conditional Access MFA requirement, but this does not matter if only device compliance is required.
If, however, “require compliant device AND MFA” is set up (or “always require MFA”), then the malicious attacker won’t get far with any device other than User1’s. The malicious attacker can log on to another user’s device with User1’s account and password, but cannot complete Windows Hello and cannot connect to any service because there will be MFA prompts for all of those. The malicious attacker would have to steal User1’s Windows 10 device in addition to compromising the password, a much higher obstacle than having to steal just any device.