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.

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.

• Intune, SCEP, NDES, Troubleshooting
• 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 SCEP et NDES » 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 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

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.

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

• 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

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

Configuration, exploitation et cas limites

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

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.

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 {
  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 }

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

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