Pendant que Hiro abuse de l'entreprise avec son propre certificat de signature de code, ils ont ouvert un appel de support avec Microsoft pour un problème complètement différent. Il s'avère que leurs appareils gérés par Intune ne peuvent plus se connecter au WiFi corporatif, ce qui affecte les médecins dans le traitement de leurs patients.

Oups.

L'ingénieur de support sur le cas Intune pointe rapidement vers SCEP comme le problème. Des heures plus tard, ils finissent par obtenir un spécialiste NDES qui pointe vers les deux certificats de service comme les coupables. Ils ont expiré il y a quelques jours et les gens ont seulement remarqué quand les appareils ont abandonné les tentatives de renouvellement de certificats.

Un couple de renouvellements plus tard, tout va bien dans le monde à nouveau. Eh bien, tout va bien jusqu'à ce que Hiro découvre son jeu.

Ce qui vient d'arriver

NDES (Network Device Enrollment Service, Service d'inscription des appareils réseau) est le serveur SCEP. SCEP c'est comment les appareils sans credentials d'annuaire s'inscrivent pour des certificats. Chaque appareil qui ne rejoint pas le domaine — appareils mobiles, IoT, équipement réseau, n'importe quoi géré par Intune — utilise SCEP pour demander un certificat.

NDES s'assoit entre l'appareil et l'autorité de certification. L'appareil envoie une demande d'inscription chiffrée à NDES. NDES détient deux certificats spéciaux, appelés certificats d'autorité d'enregistrement, qui lui permettent de déchiffrer la demande de l'appareil et de la re-signer au nom de l'appareil pour que l'AC fasse confiance à la demande.

Ces deux certificats sont :

  1. Certificat CEP Encryption — déchiffre les demandes d'inscription entrantes des clients
  2. Certificat Exchange Enrollment Agent Offline request — co-signe les demandes à l'AC au nom du client

Les deux sont des certificats réguliers. Ils ont des dates d'expiration. Quand ils expirent, NDES ne peut pas déchiffrer les demandes entrantes et ne peut pas signer celles sortantes. L'inscription s'arrête. Les appareils ne peuvent pas obtenir de certificats. Le WiFi, qui s'appuie sur l'authentification basée sur les certificats, s'arrête de fonctionner.

La réponse à incident a trouvé que les deux certificats avaient expiré trois jours avant. Ils avaient été émis il y a deux ans quand le rôle a été déployé. La période de validité par défaut sur ces modèles est de deux ans — assez longtemps pour que l'expiration disparaisse de la mémoire institutionnelle. Personne ne les surveillait. Personne n'était configuré pour les remplacer avant l'expiration.

Pourquoi les défauts ne se renouvellent pas automatiquement

Les modèles NDES standard de Microsoft pour ces deux certificats sont codés en dur dans le déploiement. Tu ne peux pas les remplacer jusqu'à APRÈS que NDES soit déployé. Le service se lance avec les défauts, utilise les défauts, et ils ne s'auto-inscrivent pas. L'hypothèse c'est qu'un opérateur va les renouveler manuellement quand ils vont être sur le point d'expirer.

Cette hypothèse casse en pratique.

Dans la plupart des organisations, NDES se fait déployer, ça fonctionne, et puis ça disparaît de la queue de monitoring. Le compte de service qui le roule est un gMSA avec des permissions minimales. Les certificats vivent dans le magasin de certificats de la machine — ce qui est exactement où ils ne devraient pas être. Idéalement, les certificats de service NDES seraient HSM-backed, stockés dans un hardware security module qui ne permet pas l'export et limite l'accès aux clés privées. En pratique, ils s'assoient dans le magasin de la machine comme n'importe quel autre certificat, accessibles à n'importe qui qui compromise ce serveur.

Des années passent. Les gens qui ont déployé NDES ont bougé. Les certificats expirent au milieu de la nuit. Le service continue de rouler mais ne peut pas faire son travail. Les appareils réessayent l'inscription, échouent, et graduellement abandonnent. Au moment où quelqu'un remarque, le WiFi est cassé, des médecins sont affectés, et la réponse à incident appelle des gens à 3h du matin.

La solution : dupliquer l'un, remplacer l'autre avec renouvellement automatique

La solution demande de comprendre la contrainte : le certificat CEP Encryption est un certificat machine et peut être dupliqué. L'Exchange Enrollment Agent Offline request est un certificat utilisateur et ne peut pas se renouveler automatiquement sur un ordinateur, peu importe ce que tu fais au modèle.

La solution réelle :

  1. Dupliquez le modèle CEP Encryption dans un modèle personnalisé.
  2. Pour l'Exchange Enrollment Agent, ne dupliquez pas le défaut. Remplacez-le avec le modèle Computer Enrollment Agent, qui est déjà basé sur la machine et peut se renouveler automatiquement.
  3. Activez le renouvellement automatique sur le modèle CEP Encryption dupliqué et le modèle Computer Enrollment Agent.
  4. Accordez les permissions Enroll et AutoEnroll du serveur NDES (objet ordinateur) sur les deux modèles, avec Use existing subject value et Valid existing cert configurés.
  5. Accordez l'accès à la clé privée du gMSA NDES aux deux certificats inscrits.
  6. C'est tout. NDES découvre et utilise automatiquement les nouveaux certificats.

Le paramètre « Use existing subject value » garantit que le serveur NDES se ré-inscrit en utilisant le même nom de sujet que le certificat existant, maintenant l'identité du service à travers les cycles de renouvellement. La condition « Valid existing cert » exige qu'un certificat valide existe déjà avant que le renouvellement puisse procéder — cela prévient les lacunes d'inscription pendant le processus de renouvellement.

NDES sélectionne quels certificats utiliser en fonction de trois critères : ils doivent avoir l'EKU correct, ils doivent avoir les mêmes valeurs de sujet qui ont été configurées lors du déploiement NDES original, et il utilise ceux avec la date d'expiration la plus longue. Aucune configuration de registre requise. Le service les trouve lui-même.

Une fois que c'est configuré, le serveur NDES va automatiquement se ré-inscrire et renouveler les deux certificats avant qu'ils expirent. Le contexte de la machine gère la ré-inscription. Le modèle re-tamponne l'accès à la clé privée au gMSA à chaque renouvellement, donc le compte de service maintient l'accès aux clés privées même quand les certificats sont remplacés.

Les certificats renouvelés sont adoptés par le service en cours automatiquement. Aucun redémarrage de service requis. Aucune intervention manuelle requise. Les certificats se renouvellent, le service continue de rouler, et l'incident qui vient juste de casser le WiFi ne se reproduit jamais.

La réalité du terrain

C'est l'appel de support le plus commun pour les déploiements NDES. Pas une mauvaise configuration du protocole. Pas une attaque. Pas une faille de conception dans SCEP. Juste : « les certificats ont expiré et on n'a pas remarqué ».

La solution est une seule fois. Le setup prend peut-être une heure une fois que tu sais ce que tu fais. Après ça, c'est fini. Les certificats se renouvellent eux-mêmes pour la durée de vie du service. La seule fois que tu les toucheras à nouveau c'est si tu désactives le rôle.

Ce qu'il faut vérifier cette semaine

Si tu as NDES déployé, vérifie les dates d'expiration sur les deux certificats maintenant :

  • Regarde Certificates > Personal dans le magasin de certificats de la machine sur ton serveur NDES
  • Trouve le certificat CEP Encryption et le certificat Exchange Enrollment Agent Offline request
  • Note leurs dates d'expiration
  • Si l'un d'eux est à moins de 30 jours de l'expiration, renouvelle-le aujourd'hui
  • Si tu ne l'as pas déjà fait, implémente le renouvellement automatique

Les étapes :

  1. Dupliquez le modèle CEP Encryption par défaut dans Active Directory
  2. Identifiez le modèle Computer Enrollment Agent (ce dernier remplace le modèle par défaut Exchange Enrollment Agent)
  3. Activez l'auto-inscription sur le modèle CEP Encryption dupliqué et le modèle Computer Enrollment Agent
  4. Configurez les deux modèles avec les paramètres « Use existing subject value » et « Valid existing cert »
  5. Accordez les permissions Enroll et AutoEnroll du serveur NDES (objet ordinateur) sur les deux modèles
  6. Inscrivez les deux certificats sur le serveur NDES
  7. Accordez l'accès à la clé privée du gMSA NDES aux deux certificats inscrits
  8. Vérifiez que les deux certificats se renouvellent automatiquement avant leurs dates d'expiration

NDES utilisera automatiquement les nouveaux certificats en fonction de l'EKU et de la date d'expiration. Aucune configuration requise.

Ce n'est pas compliqué. Ce n'est pas clever. C'est juste : configure-le une fois, et ça marche pour toujours.

La plupart des organisations qui rencontrent ce problème le découvrent de la façon difficile — comme celle dans cette histoire, étant simultanément compromise de trois façons différentes à la fois. Au moins une de ces compromissions aurait pu être prévenue avec une heure de travail de setup.

Et si tu veux fermer la porte complètement : ces certificats de service NDES devraient être HSM-backed, pas assis dans le magasin de la machine. Mais c'est une conversation pour un autre article.