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.

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.

Le fonctionnement de « Architecture SCEP, NDES et Certificate Connector » dépend du rôle exact de chaque partie : plan de contrôle, transport, traitement local, état conservé et résultat renvoyé. Le portail peut afficher une décision prise par Windows, tandis qu’un agent local peut subir une limite provenant du service cloud.

Les interfaces supportées et les détails internes observables n’ont pas le même statut. Logs, tâches et clés de registre peuvent expliquer un comportement. Ils ne constituent pas pour autant des interfaces stables pour une automatisation durable.

Le cycle réel couvre le déclenchement, le traitement, le résultat, la nouvelle évaluation et la réaction à une dérive. Reproduire une configuration sans comprendre cette séquence masque souvent la cause d’un écart.

Une intention envoyée, une valeur effective, un inventaire, un état de conformité, une télémétrie et un cache d’affichage ne décrivent pas la même chose. Leur producteur, leur heure et leur contexte déterminent la façon de les interpréter.

Identités, certificats, licences, services réseau, versions clientes et autres outils de gestion peuvent modifier le résultat sans appartenir directement au produit étudié. Une dépendance absente ne doit pas être confondue avec une limite de la technologie.

Une observation terrain reste un indice lorsqu’elle complète la documentation. Les noms de tâches, fichiers, événements ou rythmes internes peuvent changer. Les décisions de conception reposent sur les interfaces et les comportements officiellement documentés.

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

Je sépare les prérequis nécessaires à l’existence de la fonction de ceux qui ne concernent qu’un scénario d’administration. La présence d’une option dans une console ne prouve ni la prise en charge de la version cliente, ni l’éligibilité de la licence.

Les builds, éditions, rôles, dépendances réseau et contextes d’exécution doivent être confirmés avant d’interpréter un comportement. Les éléments internes observés mais non documentés comme interfaces publiques sont explicitement traités comme tels.

• 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

Cette séquence décrit ce que font les différents composants, depuis le déclenchement jusqu’au résultat. Elle sert de modèle mental : selon le scénario, certaines étapes peuvent être asynchrones ou exécutées dans un autre contexte.

Je distingue l’action demandée, son transport, son traitement local et son accusé de résultat. Cette distinction explique pourquoi deux écrans peuvent afficher temporairement des états différents sans qu’il y ait nécessairement une panne.

Fonctionnement détaillé et responsabilités

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

Configuration, exploitation et cas limites

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

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.

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.

Interfaces d’observation, commandes et exemples

Les commandes illustrent les objets et états décrits dans l’article. Elles restent en lecture seule et ne modifient volontairement aucune ressource. Elles servent à comprendre les données disponibles, pas à fournir un outil de collecte prêt à déployer.

Une automatisation durable doit employer une API ou une interface officiellement supportée. Une clé de registre, un fichier ou une tâche interne peut évoluer avec Windows, l’agent ou le service.

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

• 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

Je vérifie le modèle sur un appareil représentatif en reliant la configuration du service, l’état reçu, le traitement local et la donnée remontée. L’objectif n’est pas de certifier la production, mais de confirmer que l’explication décrit bien le comportement observé.

Un cas d’usage est retenu lorsque la technologie répond au besoin sans ajouter une autorité concurrente, une dépendance non maîtrisée ou un niveau d’opacité incompatible avec l’exploitation.

• 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 limites du modèle produisent des symptômes observables. Le tableau indique où le fonctionnement normal peut diverger et quelles informations permettent de confirmer l’origine de l’écart, sans transformer l’article en procédure de dépannage.

Une erreur isolée doit être replacée dans sa phase et son contexte. Je privilégie les résultats documentés du service et du client avant les détails d’implémentation susceptibles de changer.

Adoption progressive, réversibilité et vigilance

Pour introduire la technologie, je commence par un scénario borné, des appareils pilotes et des critères d’observation définis. L’adoption progresse uniquement si les dépendances, la supervision et les responsabilités de support sont comprises.

Le retour arrière dépend souvent de la propriété de la ressource et du cycle de synchronisation. Je le teste avant généralisation et je ne déduis jamais la réversibilité de la seule disparition d’un profil dans le portail.