SCEP avec Intune : comprendre NDES, le Certificate Connector et le cycle d’émission

L’essentiel

Avec SCEP, la paire de clés est créée sur l’appareil et la clé privée ne transite pas par Intune, NDES ou l’autorité de certification. Le poste envoie une CSR accompagnée d’un challenge construit pour son profil et son identité.

Le module de stratégie installé avec le Certificate Connector protège NDES: il compare le challenge et la CSR avec les valeurs attendues par Intune avant d’autoriser l’émission par une autorité AD CS d’entreprise.

Je sépare toujours le profil de confiance, le profil SCEP, la publication HTTPS de NDES, le connecteur, le modèle AD CS et le service consommateur. Une erreur dans l’une de ces couches peut produire un certificat absent ou inutilisable.

Avec SCEP, la paire de clés est créée sur l’appareil et la clé privée ne transite pas par Intune, NDES ou l’autorité de certification. Le poste envoie une CSR accompagnée d’un challenge construit pour son profil et son identité.

Pourquoi cette technologie existe

Le profil Trusted certificate installe la chaîne que le poste et le service consommateur doivent reconnaître. Le profil SCEP référence l’autorité émettrice, définit sujet, SAN, EKU, taille de clé, stockage logiciel ou TPM, durée et seuil de renouvellement.

Lors du check-in MDM, Windows reçoit ces paramètres. Le client SCEP crée localement une paire de clés, fabrique une Certificate Signing Request et présente au point de terminaison NDES le challenge chiffré et signé fourni par Intune.

IIS expose le chemin NDES en HTTPS. Le rôle Network Device Enrollment Service ne doit ni être installé sur un contrôleur de domaine ni partager le serveur de l’autorité émettrice; le Certificate Connector s’installe sur le serveur NDES dans le scénario Microsoft CA.

Architecture SCEP, NDES et Certificate Connector s’appuie sur la chaîne Intune → Endpoint → NDES + Connector → AD CS. 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 AD CS Enterprise supporté et modèle publié, serveur NDES membre du domaine et distinct de la CA, Certificate Connector enregistré dans Intune, publication HTTPS et résolution DNS maîtrisées. 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 Profil réussi, certificat absent, 403 sur URL NDES et Challenge refusé. 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. Intune ouvre la séquence: Distribue confiance, paramètres et challenge. Endpoint prend ensuite le relais: Crée la clé privée et la CSR. Le traitement se poursuit avec NDES + Connector, où Reçoit et valide la demande. Enfin, AD CS ferme la boucle: Signe, publie et révoque. 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. « Profil réussi, certificat absent » conduit d’abord à vérifier DM-EDP, IIS et chronologie, car la cause possible est Client SCEP ou URL non atteint. Pour « 403 sur URL NDES », la preuve utile devient URL exacte et IIS. Les cas « Challenge refusé » et « Demande refusée par CA » 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 Architecture SCEP, NDES et Certificate Connector expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions AD CS Enterprise supporté et modèle publié, serveur NDES membre du domaine et distinct de la CA, Certificate Connector enregistré dans Intune, publication HTTPS et résolution DNS maîtrisées doivent être réunies en même temps. La validation porte ensuite sur Cartographier profils, URL et modèles, Valider chaîne TLS et publication NDES, Déployer confiance puis SCEP au pilote et Suivre une demande jusqu’à AD CS. 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

Le profil Trusted certificate installe la chaîne que le poste et le service consommateur doivent reconnaître. Le profil SCEP référence l’autorité émettrice, définit sujet, SAN, EKU, taille de clé, stockage logiciel ou TPM, durée et seuil de renouvellement.

Lors du check-in MDM, Windows reçoit ces paramètres. Le client SCEP crée localement une paire de clés, fabrique une Certificate Signing Request et présente au point de terminaison NDES le challenge chiffré et signé fourni par Intune.

IIS expose le chemin NDES en HTTPS. Le rôle Network Device Enrollment Service ne doit ni être installé sur un contrôleur de domaine ni partager le serveur de l’autorité émettrice; le Certificate Connector s’installe sur le serveur NDES dans le scénario Microsoft CA.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose AD CS Enterprise supporté et modèle publié, serveur NDES membre du domaine et distinct de la CA, Certificate Connector enregistré dans Intune, publication HTTPS et résolution DNS maîtrisées, chaîne racine/intermédiaire distribuée. Ces conditions permettent de distinguer une limite de Architecture SCEP, NDES et Certificate Connector d’un scénario simplement non éligible.

• AD CS Enterprise supporté et modèle publié
• serveur NDES membre du domaine et distinct de la CA
• Certificate Connector enregistré dans Intune
• publication HTTPS et résolution DNS maîtrisées
• chaîne racine/intermédiaire distribuée
• droits d’enrôlement et de révocation documentés
• service consommateur configuré pour la même confiance

Cycle de fonctionnement, étape par étape

Le cycle de Architecture SCEP, NDES et Certificate Connector traverse Intune → Endpoint → NDES + Connector → AD CS. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Architecture SCEP, NDES et Certificate Connector, 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 Architecture SCEP, NDES et Certificate Connector

Le profil Trusted certificate installe la chaîne que le poste et le service consommateur doivent reconnaître. Le profil SCEP référence l’autorité émettrice, définit sujet, SAN, EKU, taille de clé, stockage logiciel ou TPM, durée et seuil de renouvellement.

Lors du check-in MDM, Windows reçoit ces paramètres. Le client SCEP crée localement une paire de clés, fabrique une Certificate Signing Request et présente au point de terminaison NDES le challenge chiffré et signé fourni par Intune.

IIS expose le chemin NDES en HTTPS. Le rôle Network Device Enrollment Service ne doit ni être installé sur un contrôleur de domaine ni partager le serveur de l’autorité émettrice; le Certificate Connector s’installe sur le serveur NDES dans le scénario Microsoft CA.

• AD CS Enterprise supporté et modèle publié
• serveur NDES membre du domaine et distinct de la CA
• Certificate Connector enregistré dans Intune
• publication HTTPS et résolution DNS maîtrisées

Traitement, exploitation et cas limites de Architecture SCEP, NDES et Certificate Connector

Le module de stratégie ne fait pas confiance à une requête parce qu’elle atteint l’URL. Il vérifie auprès du service Intune que le challenge est authentique, non altéré et cohérent avec sujet, SAN, usage et appareil attendus.

Après validation, NDES demande à l’autorité AD CS d’émettre selon le modèle publié. Le compte et le serveur impliqués doivent disposer des droits précis de lecture et d’enrôlement; le modèle détermine EKU, fournisseur cryptographique, taille de clé et durée maximale.

Le certificat signé revient au poste et est associé à la clé privée déjà créée. Le magasin CurrentUser ou LocalMachine dépend du ciblage utilisateur ou appareil; la présence du certificat sans clé privée rend l’authentification cliente inutilisable.

• Contrôler sujet, SAN, EKU et clé privée
• Tester renouvellement et révocation
• Valider l’authentification finale

Lire les états propres à Architecture SCEP, NDES et Certificate Connector

Le renouvellement commence avant l’expiration selon le profil. Révocation, disponibilité des CDP/AIA et propagation de la CRL appartiennent au cycle de vie: émettre correctement ne suffit pas si le serveur RADIUS ou VPN ne peut pas valider la chaîne et son statut.

La haute disponibilité exige plusieurs URL SCEP supportées, un équilibrage correctement conçu et des connecteurs capables d’atteindre les mêmes autorités. Je teste chaque chemin séparément, car une distribution aléatoire peut masquer un nœud défaillant.

Le succès se prouve à quatre endroits: profil appliqué dans Intune, événement MDM/SCEP sur Windows, validation et trafic IIS sur NDES, demande délivrée sur AD CS puis authentification réelle auprès du Wi-Fi ou du VPN.

• Profil réussi, certificat absent — DM-EDP, IIS et chronologie
• 403 sur URL NDES — URL exacte et IIS
• Challenge refusé — CertificateRegistrationPoint
• Demande refusée par CA — Failed Requests AD CS

Pilote et suivi opérationnel de Architecture SCEP, NDES et Certificate Connector

Le pilote couvre le périmètre Intune, SCEP, NDES, Certificate Connector et contrôle Cartographier profils, URL et modèles. Valider chaîne TLS et publication NDES. Déployer confiance puis SCEP au pilote. Les résultats sont segmentés selon les populations réellement concernées par Architecture SCEP, NDES et Certificate Connector.

Les cas d’échec « Profil réussi, certificat absent », « 403 sur URL NDES », « Challenge refusé » 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 exposer NDES sans module de stratégie, protéger les journaux contenant UPN et identifiants, surveiller expiration des certificats IIS et RA, tester CRL et AIA depuis les serveurs consommateurs. 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 Cartographier profils, URL et modèles. Valider chaîne TLS et publication NDES. Déployer confiance puis SCEP au pilote. Suivre une demande jusqu’à AD CS. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

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

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

La chronologie de Architecture SCEP, NDES et Certificate Connector relie Intune, Endpoint, NDES + Connector, AD CS. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Cartographier profils, URL et modèles. Valider chaîne TLS et publication NDES. Déployer confiance puis SCEP au pilote. Suivre une demande jusqu’à AD CS. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Client SCEP ou URL non atteint », « Comportement du module ou publication », « CSR différente des attentes » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Cartographier profils, URL et modèles.
• Valider chaîne TLS et publication NDES.
• Déployer confiance puis SCEP au pilote.
• Suivre une demande jusqu’à AD CS.
• Contrôler sujet, SAN, EKU et clé privée
• Tester renouvellement et révocation
• Valider l’authentification finale

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Cartographier profils, URL et modèles, Valider chaîne TLS et publication NDES, Déployer confiance puis SCEP au pilote et Suivre une demande jusqu’à AD CS. Ces contrôles relient la configuration du service au résultat réellement observé.

• Cartographier profils, URL et modèles.
• Valider chaîne TLS et publication NDES.
• Déployer confiance puis SCEP au pilote.
• Suivre une demande jusqu’à AD CS.
• Contrôler sujet, SAN, EKU et clé privée
• Tester renouvellement et révocation
• Valider l’authentification finale

Limites, modes de panne et lecture des erreurs

Les écarts connus de Architecture SCEP, NDES et Certificate Connector incluent Profil réussi, certificat absent, 403 sur URL NDES, Challenge refusé, Demande refusée par CA. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Architecture SCEP, NDES et Certificate Connector commence sur le périmètre Intune, SCEP, NDES, Certificate Connector, Inside Endpoint — Intune, Endpoint, NDES + Connector, AD CS, AD CS Enterprise supporté et modèle publié, serveur NDES membre du domaine et distinct de la CA, Certificate Connector enregistré dans Intune. Les limites et actions de réversibilité ci-dessous cadrent la progression.