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.

Le besoin opérationnel doit être défini avant de choisir un profil ou un outil. Il faut distinguer le résultat attendu, l’expérience utilisateur, le propriétaire de la configuration et les contrôles qui confirmeront son application. La présence d’un paramètre dans une console ne justifie pas son activation.

L’intention configurée dans le cloud, son applicabilité, l’état reçu par Windows et le résultat observé correspondent à quatre informations différentes. Une affectation réussie, un état vert ou une requête HTTP acceptée ne prouve pas à lui seul que tout le parcours fonctionne.

• PRT, SSO, CloudAP, WAM
• postes Windows gérés et services Microsoft officiellement documentés
• validation en laboratoire puis pilote représentatif avant généralisation

Questions à résoudre et méthode de diagnostic

Le diagnostic de « Troubleshooting PRT et SSO Windows » commence par le symptôme exact et son horodatage. Plusieurs causes restent possibles tant qu’un log, un état local ou une donnée du service ne les a pas confirmées ou écartées. Une affectation visible dans le portail, un code isolé ou un état ancien ne suffit pas.

La première collecte reste en lecture seule : contexte utilisateur ou SYSTEM, version de Windows et des composants, identifiants de corrélation, événements, logs et état du registre. Aucun cache, certificat, objet ou clé ne doit être supprimé avant cette collecte.

La première phase qui diverge détermine la suite. Une seule cause est corrigée à la fois, puis le scénario initial est rejoué. Un contournement temporaire ne doit pas être présenté comme une correction définitive.

Les heures du portail et du poste, le décalage UTC et les identifiants présents dans plusieurs logs forment une chronologie unique. Deux messages identiques peuvent appartenir à des tentatives différentes. La conclusion indique clairement les faits confirmés, les hypothèses probables et les points qui restent impossibles à vérifier.

• comprendre l’architecture, les dépendances et les limites
• mettre en œuvre un pilote mesurable et reproductible
• construire un diagnostic et un rollback utilisables par l’exploitation

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

Je fige l’état du poste avant toute correction : versions, heure, identité, contexte d’exécution, affectations, autorités de gestion et dernier cycle connu. Cette photographie permet de distinguer la cause initiale des effets produits par les essais suivants.

Je vérifie également que le compte, l’appareil, la licence, la connectivité et les composants nécessaires rendent le scénario réellement applicable. Un prérequis absent doit être traité comme une cause potentielle, pas comme un détail de préparation.

• 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 relie l’heure de la demande, le check-in, l’événement local, la décision du composant et la remontée dans le portail. Conservez l’heure UTC et l’heure locale. Avant tout partage, anonymisez les UPN, DeviceId, TenantId, noms internes, certificats, adresses et contenus métiers.

La collecte initiale reste en lecture seule. Ne videz pas un cache, ne supprimez pas une clé, ne réinitialisez pas un agent et ne forcez pas un enrôlement avant d’avoir capturé les informations utiles. Ces actions changent l’état et peuvent faire disparaître la cause initiale.

Les scripts publiés ici illustrent la collecte décrite dans l’article et restent en lecture seule. Une remédiation doit proposer une simulation, limiter sa cible, expliquer son impact et restaurer l’état précédent. Une opération privilégiée ou à grande échelle exige en plus une validation formelle et un pilote représentatif.

• 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

Je suis l’ordre réel du traitement et je m’arrête à la première divergence démontrée. Poursuivre malgré une preuve manquante créerait des symptômes secondaires et rendrait la chronologie moins fiable.

Pour chaque étape, je note l’action, l’emplacement, le résultat attendu et la méthode de vérification. Les champs Impact et Retour arrière concernent l’éventuelle correction ; la phase d’observation reste en lecture seule autant que possible.

Fonctionnement détaillé et responsabilités

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

Configuration, exploitation et cas limites

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 et les résultats

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

Une configuration décrit ce qui devrait arriver. L’inventaire montre un état observé à un instant donné, tandis qu’un log d’exécution indique ce que le composant a réellement tenté. Les horodatages et les contextes doivent correspondre avant de relier ces informations.

Les états non applicable, pending, conflict, error et success doivent rester séparés. L’absence d’un poste dans un rapport ne permet pas de conclure : il peut être hors ligne, non éligible, non ciblé, en retard de télémétrie ou exclu de la collecte.

Pilote, généralisation et maintien en conditions opérationnelles

Le pilote couvre plusieurs modèles matériels, versions de Windows, profils réseau, populations utilisateur et exceptions métier. Une cohorte témoin aide à distinguer l’effet du changement d’une évolution globale du service, d’une mise à jour applicative ou d’un incident réseau.

Les critères GO sont définis avant le début : couverture, taux de succès, délai de convergence, incidents, tickets support, régressions et temps de rollback. Une moyenne satisfaisante ne masque pas un sous-groupe en échec ; les résultats sont donc segmentés par version, modèle, site et mode de gestion.

Les cas négatifs sont testés volontairement : appareil hors ligne, licence absente, identité non éligible, règle non applicable, réseau filtré et retour arrière. Un design exploitable doit échouer de manière visible, sûre et compréhensible pour le support.

Après généralisation, les exceptions, permissions, versions de profil et dépendances doivent être revues régulièrement. Le service cloud et Windows évoluent ; une décision correcte aujourd’hui doit rester traçable et être revalidée lorsqu’un prérequis ou une interface change.

Commandes et scripts de diagnostic en lecture seule

Les commandes de cette section servent à inventorier, corréler ou illustrer. Les scripts de diagnostic restent en lecture seule : ils arrêtent leur exécution en cas d’erreur et ne modifient volontairement aucun paramètre du poste.

Je vérifie toujours le contexte d’exécution. Une commande lancée dans la session utilisateur n’observe pas forcément les mêmes certificats, variables, chemins ou ruches de registre qu’un processus exécuté sous SYSTEM.

# Exemple de collecte en lecture seule — à adapter avant utilisation
$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 }

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

Le symptôme oriente l’enquête, mais ne sélectionne jamais seul une correction. Je n’applique la réponse proposée que lorsque la preuve recherchée confirme la cause et que les autres hypothèses importantes sont écartées.

Après correction, je rejoue exactement le scénario initial avec les mêmes points de mesure. Si le symptôme se déplace vers une autre phase, je poursuis l’analyse au lieu de déclarer l’incident résolu.

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

Je valide le comportement local, puis la remontée dans le service. Les délais du portail sont pris en compte, mais l’état attendu sur le poste doit être vérifiable immédiatement ou selon le cycle officiellement documenté.

La clôture exige un résultat reproductible, l’absence de régression, une cause documentée et une correction minimale. La généralisation reste NO-GO si le résultat varie entre deux postes comparables ou si le retour arrière n’est pas maîtrisé.

• 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 rollback restaure l’état ou l’autorité précédente et doit lui aussi être vérifié sur le poste. Retirer une affectation sans confirmer la convergence locale ne constitue pas un retour arrière terminé.

Si la cause reste indéterminée, je conserve la chronologie, les journaux anonymisés, les identifiants de corrélation et la liste des hypothèses déjà écartées avant l’escalade. Je n’efface jamais les preuves pour tenter une réparation générique.