Troubleshooting SCEP avec Intune : diagnostiquer NDES et l’émission du certificat

Résumé opérationnel

Je commence par confirmer que le poste a reçu le profil de confiance et le profil SCEP, puis je relève l’heure exacte de la tentative. Sans cette chronologie, les journaux IIS, connecteur et CA sont difficiles à corréler.

Le parcours se découpe en affectation MDM, communication poste vers NDES, validation du challenge par le module de stratégie, émission AD CS, livraison et reporting. Chaque phase a ses propres preuves et ses propres corrections.

Le test final n’est pas la présence d’un certificat: je contrôle magasin, clé privée, sujet, SAN, EKU, chaîne, révocation et authentification réelle auprès du service cible.

Je commence par confirmer que le poste a reçu le profil de confiance et le profil SCEP, puis je relève l’heure exacte de la tentative. Sans cette chronologie, les journaux IIS, connecteur et CA sont difficiles à corréler.

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

Je relève le symptôme exact: profil en erreur, événement SCEP, code HRESULT, absence de requête IIS, challenge refusé, demande CA échouée ou certificat installé mais non sélectionné par le service. Chaque symptôme positionne l’enquête à une étape différente.

Sur Windows, je corrèle DeviceManagement-Enterprise-Diagnostics-Provider/Admin avec le magasin concerné et l’heure du check-in. Un profil de confiance réussi ne prouve pas que le profil SCEP a généré une CSR.

Pour la communication poste vers NDES, je vérifie DNS, TLS, chaîne du certificat serveur, proxy, pare-feu, chemin complet mscep.dll/pkiclient.exe et codes IIS. Un accès interactif 403 peut être attendu après sécurisation; l’absence totale de requête IIS ne l’est pas.

• Intune, SCEP, NDES, Troubleshooting
• Endpoint Lab — Policy, HTTPS, Validation, Issuance
• poste pilote reproductible, accès Intune aux états par paramètre, droits de lecture IIS et Certificate Connector

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting SCEP et NDES, l’enquête suit le parcours Policy → HTTPS → Validation → Issuance. 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 Horodater et qualifier le symptôme, Confirmer réception des deux profils et Tester DNS, TLS et arrivée IIS. 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 « Aucune ligne IIS, VerifyRequest false et 0x80070057 » 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.

• Horodater et qualifier le symptôme.
• Confirmer réception des deux profils.
• Tester DNS, TLS et arrivée IIS.

Cartographie du flux à diagnostiquer

Je relève le symptôme exact: profil en erreur, événement SCEP, code HRESULT, absence de requête IIS, challenge refusé, demande CA échouée ou certificat installé mais non sélectionné par le service. Chaque symptôme positionne l’enquête à une étape différente.

Sur Windows, je corrèle DeviceManagement-Enterprise-Diagnostics-Provider/Admin avec le magasin concerné et l’heure du check-in. Un profil de confiance réussi ne prouve pas que le profil SCEP a généré une CSR.

Pour la communication poste vers NDES, je vérifie DNS, TLS, chaîne du certificat serveur, proxy, pare-feu, chemin complet mscep.dll/pkiclient.exe et codes IIS. Un accès interactif 403 peut être attendu après sécurisation; l’absence totale de requête IIS ne l’est pas.

État initial et prérequis de collecte

L’état initial de Troubleshooting SCEP et NDES doit couvrir poste pilote reproductible, accès Intune aux états par paramètre, droits de lecture IIS et Certificate Connector, accès lecture à AD CS Failed Requests. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Policy, HTTPS, Validation, Issuance 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.

• poste pilote reproductible
• accès Intune aux états par paramètre
• droits de lecture IIS et Certificate Connector
• accès lecture à AD CS Failed Requests
• synchronisation horaire
• copie anonymisée des profils
• service Wi-Fi ou VPN de validation

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting SCEP et NDES relie Policy, HTTPS, Validation, Issuance. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Horodater et qualifier le symptôme. Confirmer réception des deux profils. Tester DNS, TLS et arrivée IIS. Lire VerifyRequest dans les traces. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « DNS, proxy ou URL », « Challenge ou certificat de signature », « Paramètre de profil ou connecteur » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Horodater et qualifier le symptôme.
• Confirmer réception des deux profils.
• Tester DNS, TLS et arrivée IIS.
• Lire VerifyRequest dans les traces.
• Contrôler Failed Requests AD CS
• Inspecter certificat et clé privée
• Rejouer l’authentification cible

Investigation pas à pas

L’investigation suit l’ordre Policy → HTTPS → Validation → Issuance. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting SCEP et NDES, 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 SCEP et NDES

Je relève le symptôme exact: profil en erreur, événement SCEP, code HRESULT, absence de requête IIS, challenge refusé, demande CA échouée ou certificat installé mais non sélectionné par le service. Chaque symptôme positionne l’enquête à une étape différente.

Sur Windows, je corrèle DeviceManagement-Enterprise-Diagnostics-Provider/Admin avec le magasin concerné et l’heure du check-in. Un profil de confiance réussi ne prouve pas que le profil SCEP a généré une CSR.

Pour la communication poste vers NDES, je vérifie DNS, TLS, chaîne du certificat serveur, proxy, pare-feu, chemin complet mscep.dll/pkiclient.exe et codes IIS. Un accès interactif 403 peut être attendu après sécurisation; l’absence totale de requête IIS ne l’est pas.

• poste pilote reproductible
• accès Intune aux états par paramètre
• droits de lecture IIS et Certificate Connector
• accès lecture à AD CS Failed Requests

Traitement, exploitation et cas limites de Troubleshooting SCEP et NDES

Sur NDES, les traces du module et du Certificate Connector montrent le début et la fin de VerifyRequest. Un retour false impose de lire l’exception corrélée avant de redémarrer un service ou de toucher aux clés NDESConnector.

Je contrôle les valeurs sous HKLM\SOFTWARE\Microsoft\MicrosoftIntune\NDESConnector et HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP uniquement comme indices de configuration. Leur modification exige une sauvegarde, un test sur un serveur pilote et l’application de la procédure Microsoft correspondant à l’erreur confirmée.

Si la validation réussit, je passe à Certification Authority > Failed Requests et au journal Application de la CA. Template introuvable, droits d’enrôlement, sujet non fourni, EKU ou cryptographie incompatible doivent être corrigés dans leur couche.

• Contrôler Failed Requests AD CS
• Inspecter certificat et clé privée
• Rejouer l’authentification cible

Lire les états propres à Troubleshooting SCEP et NDES

Après émission, je vérifie que le certificat arrive dans le bon contexte et possède une clé privée accessible. Le service RADIUS ou VPN peut refuser un certificat pourtant valide si la chaîne, l’EKU Client Authentication, le SAN attendu ou la révocation ne correspondent pas.

Je conserve également les versions du connecteur, de Windows Server et du modèle. Les anciens articles Microsoft peuvent décrire des connecteurs retirés; j’identifie le composant réellement installé avant d’appliquer un chemin de log historique.

La correction est validée sur une nouvelle demande identifiable, puis par renouvellement ou réémission contrôlée. Je ne conclus pas à partir d’un certificat résiduel créé avant le changement.

• Aucune ligne IIS — Résolution et trace réseau
• VerifyRequest false — Trace CertificateRegistrationPoint
• 0x80070057 — Trace avec request-id
• Denied by Policy Module — Module puis CA

Pilote et suivi opérationnel de Troubleshooting SCEP et NDES

Le pilote couvre le périmètre Intune, SCEP, NDES, Troubleshooting et contrôle Horodater et qualifier le symptôme. Confirmer réception des deux profils. Tester DNS, TLS et arrivée IIS. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting SCEP et NDES.

Les cas d’échec « Aucune ligne IIS », « VerifyRequest false », « 0x80070057 » 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 pas supprimer les certificats RA sans runbook, ne pas confondre documentation de l’ancien connecteur, un test navigateur ne reproduit pas une CSR SCEP, collecter avant tout redémarrage. 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 Horodater et qualifier le symptôme. Confirmer réception des deux profils. Tester DNS, TLS et arrivée IIS. Lire VerifyRequest dans les traces. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting SCEP et NDES, 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 {
  Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 250 |
    Where-Object Message -match 'SCEP|Certificate|0x' | Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-ChildItem Cert:\LocalMachine\My,Cert:\CurrentUser\My |
    Sort-Object NotAfter | Select-Object Subject,Issuer,Thumbprint,NotBefore,NotAfter,HasPrivateKey
} catch { Write-Error "Collecte impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  certutil.exe -user -store My
  Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 120 |
    Where-Object Message -Match 'SCEP|certificate|certificat' |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-WinEvent -LogName 'Microsoft-Windows-CertificateServicesClient-CertEnroll/Operational' -MaxEvents 80 |
    Select-Object TimeCreated,Id,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[13:10:00.102] Intune     Profile=<GUID> Challenge=Issued
[13:10:01.882] Connector  RequestId=<GUID> Forward=NDES
[13:10:02.441] IIS        POST /certsrv/mscep/mscep.dll Status=200
[13:10:03.111] ADCS       RequestId=4812 Disposition=Issued
[13:10:04.090] Client     Thumbprint=<THUMBPRINT> Store=CurrentUser\My

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

La matrice couvre notamment Aucune ligne IIS, VerifyRequest false, 0x80070057, Denied by Policy Module. 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 Horodater et qualifier le symptôme, Confirmer réception des deux profils et Tester DNS, TLS et arrivée IIS 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 SCEP et NDES 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.

• Horodater et qualifier le symptôme.
• Confirmer réception des deux profils.
• Tester DNS, TLS et arrivée IIS.
• Lire VerifyRequest dans les traces.
• Contrôler Failed Requests AD CS
• Inspecter certificat et clé privée
• Rejouer l’authentification cible

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting SCEP et NDES 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 à Horodater et qualifier le symptôme. Confirmer réception des deux profils. Tester DNS, TLS et arrivée IIS. Lire VerifyRequest dans les traces. ainsi que les causes déjà écartées.