Troubleshooting PRT et SSO Windows : diagnostiquer CloudAP, WAM et les applications

Résumé opérationnel

Je reproduis dans la session de l’utilisateur concerné, note l’application, l’URL, l’heure et le type de prompt. dsregcmd /status fournit ensuite AzureAdPrt et, en cas d’échec, AcquirePrtDiagnostics avec le statut de la tentative précédente.

Si le PRT est absent, je corrèle AAD/Operational et AAD/Analytic entre les événements 1006 et 1007, puis je vérifie join, identité, heure, proxy et authentification. Si le PRT est présent, je déplace l’enquête vers WAM, le cache de l’application, le navigateur ou Conditional Access.

Je ne capture jamais le contenu des jetons et je ne supprime pas l’objet appareil, les comptes WAM ou le profil utilisateur avant d’avoir conservé les preuves et isolé la couche fautive.

Je reproduis dans la session de l’utilisateur concerné, note l’application, l’URL, l’heure et le type de prompt. dsregcmd /status fournit ensuite AzureAdPrt et, en cas d’échec, AcquirePrtDiagnostics avec le statut de la tentative précédente.

Symptôme, contexte et périmètre de l’incident

Je distingue trois symptômes: AzureAdPrt NO, AzureAdPrt YES mais SSO absent partout, ou échec limité à une application. Leur périmètre indique si je dois commencer par CloudAP, WAM ou l’application.

dsregcmd doit être lu par sections. Device State confirme la jointure, SSO State le PRT de l’utilisateur, Diagnostic Data la tentative précédente. Un DeviceAuthStatus en échec ou une identité désactivée peut empêcher le parcours sans panne du poste.

AcquirePrtDiagnostics fournit Attempt Status, utilisateur, méthode et phase lorsqu’il est présent. Je traduis le HRESULT avec les outils Windows mais je conserve le message et l’événement d’origine, car un code identique peut provenir de plusieurs sous-composants.

• PRT, SSO, CloudAP, WAM
• Endpoint Lab — Session, Acquire, Broker, Resource
• session interactive de l’utilisateur, heure exacte du prompt, droits lecture AAD event logs

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting PRT et SSO Windows, l’enquête suit le parcours Session → Acquire → Broker → Resource. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Qualifier l’étendue du SSO, Lire dsregcmd en contexte user et Relever Attempt Status. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « AzureAdPrt NO, PRT YES, aucun SSO et Une app seulement » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Qualifier l’étendue du SSO.
• Lire dsregcmd en contexte user.
• Relever Attempt Status.

Cartographie du flux à diagnostiquer

Je distingue trois symptômes: AzureAdPrt NO, AzureAdPrt YES mais SSO absent partout, ou échec limité à une application. Leur périmètre indique si je dois commencer par CloudAP, WAM ou l’application.

dsregcmd doit être lu par sections. Device State confirme la jointure, SSO State le PRT de l’utilisateur, Diagnostic Data la tentative précédente. Un DeviceAuthStatus en échec ou une identité désactivée peut empêcher le parcours sans panne du poste.

AcquirePrtDiagnostics fournit Attempt Status, utilisateur, méthode et phase lorsqu’il est présent. Je traduis le HRESULT avec les outils Windows mais je conserve le message et l’événement d’origine, car un code identique peut provenir de plusieurs sous-composants.

État initial et prérequis de collecte

L’état initial de Troubleshooting PRT et SSO Windows doit couvrir session interactive de l’utilisateur, heure exacte du prompt, droits lecture AAD event logs, accès sign-in logs Entra. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Session, Acquire, Broker, Resource sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• session interactive de l’utilisateur
• heure exacte du prompt
• droits lecture AAD event logs
• accès sign-in logs Entra
• état réseau et proxy
• application témoin compatible WAM
• compte de secours

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting PRT et SSO Windows relie Session, Acquire, Broker, Resource. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Qualifier l’étendue du SSO. Lire dsregcmd en contexte user. Relever Attempt Status. Corréler événements 1006/1007. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Acquisition échouée », « Broker ou compte », « Cache ou bibliothèque » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Qualifier l’étendue du SSO.
• Lire dsregcmd en contexte user.
• Relever Attempt Status.
• Corréler événements 1006/1007.
• Tester réseau et proxy
• Comparer WAM/navigateur/application
• Vérifier sign-in logs et CA

Investigation pas à pas

L’investigation suit l’ordre Session → Acquire → Broker → Resource. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting PRT et SSO Windows, les contrôles « Reproduire et horodater le symptôme », « Contrôler la première couche », « Corréler les preuves » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé de Troubleshooting PRT et SSO Windows

Je distingue trois symptômes: AzureAdPrt NO, AzureAdPrt YES mais SSO absent partout, ou échec limité à une application. Leur périmètre indique si je dois commencer par CloudAP, WAM ou l’application.

dsregcmd doit être lu par sections. Device State confirme la jointure, SSO State le PRT de l’utilisateur, Diagnostic Data la tentative précédente. Un DeviceAuthStatus en échec ou une identité désactivée peut empêcher le parcours sans panne du poste.

AcquirePrtDiagnostics fournit Attempt Status, utilisateur, méthode et phase lorsqu’il est présent. Je traduis le HRESULT avec les outils Windows mais je conserve le message et l’événement d’origine, car un code identique peut provenir de plusieurs sous-composants.

• session interactive de l’utilisateur
• heure exacte du prompt
• droits lecture AAD event logs
• accès sign-in logs Entra

Traitement, exploitation et cas limites de Troubleshooting PRT et SSO Windows

Dans Event Viewer, j’affiche les canaux Analytic et Debug puis j’active temporairement AAD/Analytic pour reproduire. Les événements 1006 et 1007 bornent le flux; j’exporte le canal avant de le désactiver si le volume ou la sensibilité l’exige.

Je vérifie heure, résolution DNS, proxy WinHTTP et utilisateur, inspection TLS et accès aux endpoints Microsoft requis. Un navigateur fonctionnel ne prouve pas que le contexte système ou CloudAP utilise le même proxy.

Pour un appareil hybrid joined, je contrôle aussi la jointure et les dépendances de synchronisation/fédération correspondant au scénario. Je ne confonds pas EnterprisePrt AD FS et AzureAdPrt Microsoft Entra.

• Tester réseau et proxy
• Comparer WAM/navigateur/application
• Vérifier sign-in logs et CA

Lire les états propres à Troubleshooting PRT et SSO Windows

Si PRT vaut YES, je teste une application brokerisée connue puis le navigateur compatible. Un échec isolé peut venir du cache de l’application, d’une version MSAL, d’un compte secondaire ou d’un plugin qui ne passe pas par WAM.

Je rapproche la tentative avec les sign-in logs Entra: application, ressource, utilisateur, device ID, Conditional Access et failure reason. Le journal cloud peut montrer que l’authentification a réussi mais que l’accès a été bloqué par une policy.

La correction minimale est validée sans réinscription de l’appareil. Une déconnexion/reconnexion ou un nettoyage de compte est une action intrusive. Elle exige une cible limitée, une sauvegarde du contexte et un plan de récupération vérifié.

• AzureAdPrt NO — Attempt Status et AAD
• PRT YES, aucun SSO — Test WAM
• Une app seulement — Logs de l’app
• CA failure — Sign-in logs

Pilote et suivi opérationnel de Troubleshooting PRT et SSO Windows

Le pilote couvre le périmètre PRT, SSO, CloudAP, WAM et contrôle Qualifier l’étendue du SSO. Lire dsregcmd en contexte user. Relever Attempt Status. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting PRT et SSO Windows.

Les cas d’échec « AzureAdPrt NO », « PRT YES, aucun SSO », « Une app seulement » 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 exporter un jeton, AAD Analytic peut être verbeux, ne pas supprimer l’objet Entra en première intention, tenir compte du contexte elevated/non-elevated. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Qualifier l’étendue du SSO. Lire dsregcmd en contexte user. Relever Attempt Status. Corréler événements 1006/1007. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting PRT et SSO Windows, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

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

$ErrorActionPreference = 'Stop'
try {
  dsregcmd.exe /status
  Get-WinEvent -LogName 'Microsoft-Windows-AAD/Operational' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-ScheduledTask -TaskPath '\Microsoft\Windows\Workplace Join\' -ErrorAction SilentlyContinue |
    Select-Object TaskName,State
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[08:01:10.004] Device   AzureAdJoined=YES DeviceAuthStatus=SUCCESS
[08:01:12.442] CloudAP  User=<USER> Authentication=Success
[08:01:13.881] PRT      AzureAdPrt=YES AttemptStatus=0x0
[08:01:15.002] WAM      Resource=<APP-ID> Token=Acquired
[08:01:15.770] App      SSO=Success CorrelationId=<GUID>

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment AzureAdPrt NO, PRT YES, aucun SSO, Une app seulement, CA failure. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Qualifier l’étendue du SSO, Lire dsregcmd en contexte user et Relever Attempt Status sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Troubleshooting PRT et SSO Windows est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• Qualifier l’étendue du SSO.
• Lire dsregcmd en contexte user.
• Relever Attempt Status.
• Corréler événements 1006/1007.
• Tester réseau et proxy
• Comparer WAM/navigateur/application
• Vérifier sign-in logs et CA

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting PRT et SSO Windows restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Qualifier l’étendue du SSO. Lire dsregcmd en contexte user. Relever Attempt Status. Corréler événements 1006/1007. ainsi que les causes déjà écartées.