In a nutshell, the Primary Refresh Token (PRT) is a special high privileged refresh token where you can request access tokens for any registered application in Azure and Microsoft 365 to authenticate against it. Compared to Active Directory in on-premises networks, it is the equivalence to the Ticket Granting Ticket (TGT).


Table Of Contents
  1. Introduction
  2. Key Terminology for PRT
  3. Using the PRT to request App Token (Access Token)
  4. Seamless Sign-on (SSO) for Devices in Azure AD
  5. Primary Refresh Token (PRT) in Detail
  6. How is a PRT issued?
  7. Browser SSO
  8. Links



Introduction

By accessing an application like Outlook on the web or Teams, the application requests an access token and redirects the user to Azure AD (Identity Provider IdP) by using the URI https://login.microsoftonline.com.

The PRT is used to get in response a regular accesss token and refresh token dedicated for the requested application and user.

What type of tokens will be issued depends on the apps. Some apps might only implement SAML and others might only implement OIDC/OAuth.

Microsoft identity platform token exchange scenarios with SAML and OIDC/OAuth
https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-token-exchange-saml-oauth


The PRT is issued to the user during Windows logon when the user signs in with its organization credentials (accounts) on following devices:

  • Azure AD registered
  • Azure AD joined
  • Hybrid Azure AD joined


More about Hybrid Azure AD joined devices and how to configure Hybrid Azure AD join for managed domains you can read in my following post.

Configure Hybrid Azure AD join for managed domains



More about  single sign-on (SSO) for devices by using a Primary Refresh Token (PRT) you will find in my following post.

Providing SSO in Azure AD and Microsoft 365





Key Terminology for PRT

In order to understand the different processes for the Primary Refresh Token (PRT), it is important to know the key terminology and components involved in.

The following Windows components play a key role in requesting and using a PRT:

  • Cloud Authentication Provider (CloudAP): CloudAP is the modern authentication provider for Windows sign in, that verifies users logging to a Windows 10 device. CloudAP provides a plugin framework that identity providers can build on to enable authentication to Windows using that identity provider’s credentials.
  • Web Account Manager (WAM): WAM is the default token broker on Windows 10 devices. WAM also provides a plugin framework that identity providers can build on and enable SSO to their applications relying on that identity provider. (Not included in Windows Server 2016 LTSC builds)
  • Azure AD CloudAP plugin: An Azure AD specific plugin built on the CloudAP framework, that verifies user credentials with Azure AD during Windows sign in.
  • Azure AD WAM plugin: An Azure AD specific plugin built on the WAM framework, that enables SSO to applications that rely on Azure AD for authentication.
  • Dsreg: An Azure AD specific component on Windows 10, that handles the device registration process for all device states.
  • Trusted Platform Module (TPM): A TPM is a hardware component built into a device, that provides hardware-based security functions for user and device secrets. More details can be found in the article Trusted Platform Module Technology Overview.

Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#key-terminology-and-components




Using the PRT to request App Token (Access Token)

The process by using the PRT to request a refresh and access token for an app in Azure and Microsoft 365, is detailed described in the following Microsoft article.

PRT usage during app token requests
https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#prt-usage-during-app-token-requests


An application (for example, Outlook, OneNote etc.) initiates a token request to WAM. WAM, in turn, asks the Azure AD WAM plugin to service the token request. Azure AD WAM plugin uses the PRT to request an access token. To provide proof of possession, WAM plugin signs the request containing the PRT with the Session key. Azure AD validates the Session key signature by comparing it against the Session key embedded in the PRT, verifies that the device is valid and issues an access token and a refresh token for the application. In addition, Azure AD can issue a new PRT (based on refresh cycle), all of them encrypted by the Session key.

Browser SSO using PRT
https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#browser-sso-using-prt



More details about the Primary Refresh Token (PRT) and how single sign-on works in Windows 10 you will find below.

This is well documented in the following articles from Microsoft and I want to outline the key points here.

What is a device identity?
https://docs.microsoft.com/en-us/azure/active-directory/devices/overview

What is a Primary Refresh Token?
https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token




Seamless Sign-on (SSO) for Devices in Azure AD

Registering and joining devices to Azure AD gives your users Seamless Sign-on (SSO) to cloud resources. This process also allows administrators the ability to apply Conditional Access policies to resources based on the device they are accessed from.

Device-based Conditional Access policies require either hybrid Azure AD joined devices or compliant Azure AD joined or Azure AD registered devices.


To bring a device in Azure AD, you have multiple options:

  • Azure AD registered
    • Devices that are Azure AD registered are typically personally owned or mobile devices, and are signed in with a personal Microsoft account or another local account.
  • Azure AD joined
    • Devices that are Azure AD joined are owned by an organization, and are signed in with an Azure AD account belonging to that organization. They exist only in the cloud.
  • Hybrid Azure AD joined
    • Devices that are hybrid Azure AD joined are owned by an organization, and are signed in with an Active Directory Domain Services account belonging to that organization. They exist in the cloud and on-premises.


Devices in Azure AD can be managed using Mobile Device Management (MDM) tools like Microsoft Intune, Microsoft Endpoint Configuration Manager, Group Policy (hybrid Azure AD join), Mobile Application Management (MAM) tools, or other third-party tools.

The primary refresh token (PRT) contains information about the device and is required for SSO. If you have a device-based Conditional Access policy set on an application, without the PRT, access is denied. Hybrid Conditional Access policies require a hybrid state device and a valid user who is signed in.

Devices that are Azure AD joined or hybrid Azure AD joined benefit from SSO to your organization’s on-premises resources as well as cloud resources. More information can be found in the article, How SSO to on-premises resources works on Azure AD joined devices.




Primary Refresh Token (PRT) in Detail

A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, Windows Server 2016 and later versions, iOS, and Android devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices.

A PRT contains claims generally contained in any Azure AD refresh token. In addition, there are some device-specific claims included in the PRT. They are as follows:

  • Device ID: A PRT is issued to a user on a specific device. The device ID claim deviceID determines the device the PRT was issued to the user on. This claim is later issued to tokens obtained via the PRT. The device ID claim is used to determine authorization for Conditional Access based on device state or compliance.
  • Session key: The session key is an encrypted symmetric key, generated by the Azure AD authentication service, issued as part of the PRT. The session key acts as the proof of possession when a PRT is used to obtain tokens for other applications.


You can check if a PRT is issued to your user and device by using the command dsregcmd /status

Under SSO State you will find AzureAdPrt yes or no.

Web Account Manager (WAM): WAM is the default token broker on Windows 10 devices. WAM also provides a plugin framework that identity providers can build on and enable SSO to their applications relying on that identity provider.

Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#key-terminology-and-components


You can also reveal the PRT with mimikatz as it is stored in memory like other credentials.

https://github.com/gentilkiwi/mimikatz/wiki

privilege::debug
sekurlsa::cloudap

token::elevate
dpapi::cloudapkd /keyvalue: /unprotect
dpapi::cloudapkd /context: /derivedkey: /prt:




How is a PRT issued?

Device registration is a prerequisite for device based authentication in Azure AD. A PRT is issued to users only on registered devices. For more in-depth details on device registration, see the article Windows Hello for Business and Device Registration. During device registration, the dsreg component generates two sets of cryptographic key pairs:

  • Device key (dkpub/dkpriv)
  • Transport key (tkpub/tkpriv)

The private keys are bound to the device’s TPM if the device has a valid and functioning TPM, while the public keys are sent to Azure AD during the device registration process. These keys are used to validate the device state during PRT requests.

The PRT is issued during user authentication on a Windows 10 device in two scenarios:

  • Azure AD joined or Hybrid Azure AD joined: A PRT is issued during Windows logon when a user signs in with their organization credentials. A PRT is issued with all Windows 10 supported credentials, for example, password and Windows Hello for Business. In this scenario, Azure AD CloudAP plugin is the primary authority for the PRT.
  • Azure AD registered device: A PRT is issued when a user adds a secondary work account to their Windows 10 device. Users can add an account to Windows 10 in two different ways –
    • Adding an account via the Use this account everywhere on this device prompt after signing in to an app (for example, Outlook)
    • Adding an account from Settings > Accounts > Access Work or School > Connect

In Azure AD registered device scenarios, the Azure AD WAM plugin is the primary authority for the PRT since Windows logon is not happening with this Azure AD account.


Once issued, a PRT is valid for 14 days and is continuously renewed as long as the user actively uses the device.


More about PRT you will find directly under https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token


You will also get deep details about PRT under the following links about abusing the PRT.

Abusing Azure AD SSO with the Primary Refresh Token
https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/

Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO
https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30

Introducing ROADtools – The Azure AD exploration framework
https://dirkjanm.io/introducing-roadtools-and-roadrecon-azure-ad-exploration-framework/



Browser SSO

In Windows 10, Azure AD supports browser SSO in Internet Explorer and Microsoft Edge natively or in Google Chrome via the Windows 10 accounts extension.

To better understand how browser SSO with PRT works, you can read also the following two great posts about PRT.

Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO
https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30

Abusing Azure AD SSO with the Primary Refresh Token
https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/


BrowserCore.exe is a core component of Windows 10 and it serves as a browser add-on that allows Microsoft users to connect via Azure and Microsoft websites.

It is an executable exe file which belongs to the BrowserCore Chromium Native Process process which comes along with the BrowserCore Software developed by TeamDev software developer.

Source: https://developer.chrome.com/docs/apps/nativeMessaging/#native-messaging-host


Windows 10 have a native messaging host for Chrome preinstalled
https://addons.mozilla.org/en-US/firefox/addon/windows-10-accounts-port/

Chrome Browser – Windows 10 Accounts Extension
https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji?hl=en



Links

What is a Primary Refresh Token?
https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

What is a device identity?
https://docs.microsoft.com/en-us/azure/active-directory/devices/overview

Troubleshooting hybrid Azure Active Directory joined devices
https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current

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

Azure AD Understanding Tokens(John Savill)
https://youtu.be/R5pXessyfIk

AzureAD and Office 365 Tokens Lifetime
https://itworldjd.wordpress.com/2019/07/31/azuread-office-354-token-lifetime/