Contrôleurs de domaine sur des versions de Windows Server non prises en charge : sortir proprement de l'impasse
Un contrôleur de domaine détient une copie de tous les secrets du domaine. Lorsqu'il tourne sur une version de Windows Server qui ne reçoit plus de correctifs de sécurité, chaque nouvelle vulnérabilité publiée devient une porte d'entrée permanente vers l'ensemble de l'annuaire.
Pourquoi c'est un risque de niveau forêt
Tous les contrôleurs d'un domaine sont équivalents du point de vue de la sécurité : compromettre l'un d'eux permet d'extraire les condensats de mots de passe, y compris celui du compte krbtgt, et donc de forger des tickets pour n'importe quel utilisateur. Un seul DC obsolète, même situé dans une petite agence, abaisse ainsi le niveau de sécurité de toute la forêt. Windows Server 2008 et 2008 R2, puis 2012 et 2012 R2, ont atteint leur fin de support ; Windows Server 2016 approche de la sienne. Les dates exactes et les éventuelles mises à jour de sécurité étendues (ESU) sont publiées dans le cycle de vie des produits Microsoft, à vérifier au moment de votre planification.
Au-delà des correctifs, un DC ancien bloque aussi le relèvement du niveau fonctionnel et donc l'activation de protections modernes, et il reste souvent le dernier point d'appui de protocoles anciens comme SMBv1 ou la réplication FRS.
Faire un inventaire fiable
L'inventaire doit partir de l'annuaire, pas de la documentation. Listez les objets ordinateurs de l'unité d'organisation Domain Controllers, les objets serveur dans Sites et services Active Directory, et l'attribut operatingSystem de chaque contrôleur. Comparez ensuite avec la réalité : un DC présent dans l'annuaire mais éteint depuis des mois est un signal d'alerte, tout comme un serveur qui n'apparaît plus dans la console mais dont les enregistrements DNS subsistent. Pensez aux contrôleurs en lecture seule, aux domaines enfants et aux forêts de test oubliées.
Mise à niveau sur place ou nouveau contrôleur ?
Microsoft prend en charge certaines mises à niveau sur place de contrôleurs de domaine, mais nous recommandons presque toujours de promouvoir un nouveau serveur et de retirer l'ancien. Cette approche part d'un système propre, sans configuration historique ni logiciels tiers accumulés, et permet de revenir en arrière tant que l'ancien DC n'est pas rétrogradé.
- Vérifier la santé de la réplication et la migration de SYSVOL vers DFS-R.
- Promouvoir le nouveau contrôleur dans le bon site, avec DNS et catalogue global si nécessaire.
- Transférer les rôles FSMO éventuellement détenus par l'ancien DC.
- Mettre à jour les références : DHCP, configurations DNS statiques des serveurs, applications pointant vers un nom ou une adresse IP précise.
- Rétrograder proprement l'ancien contrôleur, puis le retirer du réseau.
Hygiène de rétrogradation et nettoyage des métadonnées
Une rétrogradation propre retire le serveur de la topologie de réplication et supprime ses enregistrements. Lorsque ce n'est pas possible (serveur détruit, restauration impossible), une suppression forcée laisse des métadonnées : objet NTDS Settings, objet serveur dans Sites et services, enregistrements DNS de type SRV, A et NS, références dans les partitions d'application. Depuis Windows Server 2008, supprimer l'objet ordinateur d'un DC dans la console déclenche le nettoyage principal, mais il faut encore vérifier DNS et Sites et services. L'outil ntdsutil reste disponible pour les cas complexes.
Ne pas oublier les secrets. Un DC retiré ou perdu a pu être copié. Si le serveur a quitté votre contrôle sans rétrogradation propre, considérez une double réinitialisation du mot de passe du compte krbtgt, planifiée pour respecter les délais de réplication.
Ce qu'un audit vérifie
- la version et l'état de support de chaque contrôleur de domaine, y compris les RODC ;
- la cohérence entre l'annuaire, Sites et services et les enregistrements DNS ;
- la présence de métadonnées orphelines laissées par d'anciens contrôleurs ;
- le mode de réplication de SYSVOL et les protocoles anciens encore actifs sur les DC.