Primary Refresh Token : comprendre le SSO Microsoft Entra sous Windows

L’essentiel

Le Primary Refresh Token est délivré par Microsoft Entra au broker de la plateforme après authentification de l’utilisateur et validation de l’appareil. Il sert ensuite à demander des jetons pour les applications, pas à être présenté directement à chaque ressource.

Sous Windows, CloudAP participe à la connexion et Web Account Manager fournit le broker aux applications. Une clé de session liée au PRT signe les demandes; sa protection par TPM réduit le risque de rejeu hors de l’appareil.

AzureAdPrt: YES confirme la présence d’un PRT pour l’utilisateur connecté à l’instant de dsregcmd. Il ne valide ni une application précise, ni un accès conditionnel, ni le canal MDM.

Le Primary Refresh Token est délivré par Microsoft Entra au broker de la plateforme après authentification de l’utilisateur et validation de l’appareil. Il sert ensuite à demander des jetons pour les applications, pas à être présenté directement à chaque ressource.

Pourquoi cette technologie existe

Lors d’une connexion prise en charge, Windows établit l’identité utilisateur et l’état de l’appareil. CloudAP échange avec Microsoft Entra et obtient un PRT ainsi qu’une clé de session; le mécanisme varie selon Entra join, hybrid join et fédération.

Le PRT est un artefact de renouvellement à large portée, pas un access token destiné à une ressource. WAM et les applications compatibles demandent à Entra des jetons ciblés en s’appuyant sur le PRT et la preuve de possession.

La clé de session signe les requêtes liées au PRT. Lorsqu’elle est protégée par TPM, le matériel contribue à empêcher l’export et le rejeu de la preuve sur un autre poste.

PRT et SSO Windows s’appuie sur la chaîne Sign-in → PRT → Broker → Apps. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont appareil enregistré ou joint selon scénario, utilisateur Entra valide, connectivité login.microsoftonline.com, heure et proxy corrects. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont AzureAdPrt NO, PRT YES, application demande login et SSO web seulement en échec. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Sign-in ouvre la séquence: Utilisateur et appareil s’authentifient. PRT prend ensuite le relais: Entra émet session et clé associée. Le traitement se poursuit avec Broker, où CloudAP/WAM demande les jetons. Enfin, Apps ferme la boucle: Reçoivent jetons et SSO selon CA. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « AzureAdPrt NO » conduit d’abord à vérifier AcquirePrtDiagnostics, car la cause possible est Émission ou renouvellement échoué. Pour « PRT YES, application demande login », la preuve utile devient Logs app/WAM. Les cas « SSO web seulement en échec » et « Accès CA refusé » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont PRT et SSO Windows expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions appareil enregistré ou joint selon scénario, utilisateur Entra valide, connectivité login.microsoftonline.com, heure et proxy corrects doivent être réunies en même temps. La validation porte ensuite sur Identifier le type de join, Lire SSO State en contexte user, Contrôler heures PRT et Observer CloudAP/AAD. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Lors d’une connexion prise en charge, Windows établit l’identité utilisateur et l’état de l’appareil. CloudAP échange avec Microsoft Entra et obtient un PRT ainsi qu’une clé de session; le mécanisme varie selon Entra join, hybrid join et fédération.

Le PRT est un artefact de renouvellement à large portée, pas un access token destiné à une ressource. WAM et les applications compatibles demandent à Entra des jetons ciblés en s’appuyant sur le PRT et la preuve de possession.

La clé de session signe les requêtes liées au PRT. Lorsqu’elle est protégée par TPM, le matériel contribue à empêcher l’export et le rejeu de la preuve sur un autre poste.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose appareil enregistré ou joint selon scénario, utilisateur Entra valide, connectivité login.microsoftonline.com, heure et proxy corrects, TPM recommandé. Ces conditions permettent de distinguer une limite de PRT et SSO Windows d’un scénario simplement non éligible.

• appareil enregistré ou joint selon scénario
• utilisateur Entra valide
• connectivité login.microsoftonline.com
• heure et proxy corrects
• TPM recommandé
• applications compatibles WAM
• policies CA connues

Cycle de fonctionnement, étape par étape

Le cycle de PRT et SSO Windows traverse Sign-in → PRT → Broker → Apps. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans PRT et SSO Windows, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de PRT et SSO Windows

Lors d’une connexion prise en charge, Windows établit l’identité utilisateur et l’état de l’appareil. CloudAP échange avec Microsoft Entra et obtient un PRT ainsi qu’une clé de session; le mécanisme varie selon Entra join, hybrid join et fédération.

Le PRT est un artefact de renouvellement à large portée, pas un access token destiné à une ressource. WAM et les applications compatibles demandent à Entra des jetons ciblés en s’appuyant sur le PRT et la preuve de possession.

La clé de session signe les requêtes liées au PRT. Lorsqu’elle est protégée par TPM, le matériel contribue à empêcher l’export et le rejeu de la preuve sur un autre poste.

• appareil enregistré ou joint selon scénario
• utilisateur Entra valide
• connectivité login.microsoftonline.com
• heure et proxy corrects

Traitement, exploitation et cas limites de PRT et SSO Windows

Pour le SSO navigateur, un mécanisme de cookie PRT est utilisé par les navigateurs compatibles. Les applications Office et autres clients modernes s’intègrent au broker; une application utilisant son propre cache peut avoir un état différent du PRT système.

Le PRT est renouvelé pendant l’usage actif selon le cycle Microsoft. Sa durée nominale ne doit pas être transformée en promesse de session permanente: révocation, changement d’état utilisateur/appareil, fréquence de connexion et Conditional Access influencent l’accès.

Les claims MFA et appareil peuvent être associés au parcours d’authentification. Un PRT présent n’implique pas que toutes les exigences d’une policy Conditional Access sont satisfaites pour une application donnée.

• Tester une application WAM
• Comparer navigateur et client natif
• Tester après changement réseau

Lire les états propres à PRT et SSO Windows

dsregcmd /status exécuté dans la session de l’utilisateur expose AzureAdPrt, heures UTC, authority et diagnostics de la tentative précédente. Exécuté élevé, il peut afficher un contexte différent ou un avertissement; je conserve le contexte dans la collecte.

CloudAP écrit les erreurs dans AAD/Operational et les informations détaillées dans AAD/Analytic. Les événements 1006 et 1007 encadrent une acquisition PRT dans la procédure Microsoft et permettent de construire une chronologie.

Le PRT ne remplace pas Cloud Kerberos Trust. Ce dernier utilise le parcours Entra et un TGT partiel pour atteindre des ressources AD; je distingue toujours SSO cloud, ticket Kerberos et jeton applicatif.

• AzureAdPrt NO — AcquirePrtDiagnostics
• PRT YES, application demande login — Logs app/WAM
• SSO web seulement en échec — Navigateur supporté
• Accès CA refusé — Sign-in logs

Pilote et suivi opérationnel de PRT et SSO Windows

Le pilote couvre le périmètre Microsoft Entra, PRT, SSO, CloudAP et contrôle Identifier le type de join. Lire SSO State en contexte user. Contrôler heures PRT. Les résultats sont segmentés selon les populations réellement concernées par PRT et SSO Windows.

Les cas d’échec « AzureAdPrt NO », « PRT YES, application demande login », « SSO web seulement en échec » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne jamais collecter ou exposer des jetons, AzureAdPrt YES n’est pas une validation globale, respecter UTC, séparer PRT, access token et TGT. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Identifier le type de join. Lire SSO State en contexte user. Contrôler heures PRT. Observer CloudAP/AAD. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour PRT et SSO Windows, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  dsregcmd.exe /status
  Get-WinEvent -LogName 'Microsoft-Windows-AAD/Operational' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte PRT impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de PRT et SSO Windows relie Sign-in, PRT, Broker, Apps. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Identifier le type de join. Lire SSO State en contexte user. Contrôler heures PRT. Observer CloudAP/AAD. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Émission ou renouvellement échoué », « Cache ou broker applicatif », « Navigateur ou cookie » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Identifier le type de join.
• Lire SSO State en contexte user.
• Contrôler heures PRT.
• Observer CloudAP/AAD.
• Tester une application WAM
• Comparer navigateur et client natif
• Tester après changement réseau

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Identifier le type de join, Lire SSO State en contexte user, Contrôler heures PRT et Observer CloudAP/AAD. Ces contrôles relient la configuration du service au résultat réellement observé.

• Identifier le type de join.
• Lire SSO State en contexte user.
• Contrôler heures PRT.
• Observer CloudAP/AAD.
• Tester une application WAM
• Comparer navigateur et client natif
• Tester après changement réseau

Limites, modes de panne et lecture des erreurs

Les écarts connus de PRT et SSO Windows incluent AzureAdPrt NO, PRT YES, application demande login, SSO web seulement en échec, Accès CA refusé. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de PRT et SSO Windows commence sur le périmètre Microsoft Entra, PRT, SSO, CloudAP, Inside Endpoint — Sign-in, PRT, Broker, Apps, appareil enregistré ou joint selon scénario, utilisateur Entra valide, connectivité login.microsoftonline.com. Les limites et actions de réversibilité ci-dessous cadrent la progression.