Windows Server 2016 fin de support : mise à niveau contrôleurs de domaine Active Directory avant le 12 janvier 2027

Une mise à niveau des contrôleurs de domaine Active Directory liée à la fin de support de Windows Server 2016 est un projet daté, avec une échéance fixe — pas un élément de backlog qu'on peut continuer à reporter. L'équipe Windows Server de Microsoft affirme sans détour que « le support étendu de Windows Server 2016 prendra fin le 12 janvier 2027 », et la fiche Microsoft Lifecycle pour Windows Server 2016 confirme que le produit suit la Fixed Lifecycle Policy avec une date de fin de support étendu en janvier 2027. Le support courant (mainstream) s'est déjà terminé en janvier 2022.

La partie inconfortable n'est presque jamais les contrôleurs de domaine eux-mêmes. La plupart des équipes peuvent planifier une reconstruction de DC. Ce qui les bloque, c'est une courte liste d'hôtes et d'appliances critiques pour l'activité qui ne peuvent pas être mis à niveau — et ces hôtes ne portent pas seulement leur propre risque. Parce que les défauts de chiffrement Kerberos, les niveaux fonctionnels et les paramètres de durcissement à l'échelle du domaine sont des propriétés du domaine, une poignée de machines non corrigeables épinglent l'annuaire entier à leur niveau de sécurité.

Windows Server 2016 fin de support : échéance de la mise à niveau des contrôleurs de domaine Active Directory

Windows Server 2016 suit la Fixed Lifecycle Policy de Microsoft, qui garantit « un minimum de cinq ans de support courant » plus « une période supplémentaire de support étendu pour certains produits ». Le chiffre de dix ans souvent cité vient d'une page différente : Microsoft décrit le Long Term Servicing Channel de Windows Server comme offrant « un minimum de 10 ans de support : cinq ans de support courant et cinq ans de support étendu, qui inclut des mises à jour de sécurité régulières ». Le support étendu est la phase qui délivre encore des mises à jour de sécurité. Une fois qu'il se termine, cela s'arrête.

Le cadrage propre à Microsoft de ce que signifie la fin de support pour un système d'exploitation serveur est direct : une fois qu'un produit atteint la fin de support, « cela signifie aussi la fin des mises à jour de sécurité et des bulletins », une situation qui « peut provoquer des problèmes de sécurité ou de conformité et mettre en danger les applications métier ».

Le 25 février 2026, Microsoft a annoncé les Extended Security Updates pour Windows Server 2016. Ces mises à jour sont livrées « via le portail Azure », et l'ESU « activé par Azure Arc » est présenté comme apportant des bénéfices Azure supplémentaires, dont de la flexibilité de licence et des capacités de gestion Azure. La recommandation de Microsoft dans ce même billet est de migrer vers Windows Server 2025 ou vers Azure — l'ESU est présenté comme un pont, pas une destination.

Pour un contrôleur de domaine en particulier, le risque n'est pas abstrait. Le catalogue de points de contrôle Active Directory de l'ANSSI contient un constat dédié intitulé « DC/RODC with an obsolete operating system », qui décrit les contrôleurs de domaine exécutant des « systèmes d'exploitation pour lesquels Microsoft ne publie plus de mises à jour de sécurité. Ainsi, toute nouvelle vulnérabilité découverte sur ces systèmes d'exploitation restera exploitable. » Sa remédiation tient en une ligne : « Migrer ces systèmes d'exploitation obsolètes dès que possible, de préférence vers la dernière version de Windows. »

Pourquoi un seul hôte legacy retient tout le domaine

C'est la partie contre-intuitive, et c'est là que la plupart des plans de migration 2027 échouent silencieusement.

Les niveaux fonctionnels sont bornés par votre pire contrôleur de domaine

Le niveau fonctionnel de forêt et de domaine détermine quelles capacités AD DS sont disponibles — et la matrice d'interopérabilité des niveaux fonctionnels de Microsoft rend cette dépendance explicite. Un DC Windows Server 2012 R2 ne peut pas fonctionner au niveau fonctionnel Windows Server 2016. Un DC Windows Server 2016, 2019 ou 2022 ne peut pas fonctionner au niveau fonctionnel Windows Server 2025.

Un seul contrôleur de domaine 2012 R2 survivant plafonne donc tout le domaine au niveau 2012 R2, ce qui vous prive de toutes les capacités introduites depuis — y compris les fonctionnalités de niveau domaine de Windows Server 2016 (rotation automatique des secrets NTLM et autres secrets à base de mot de passe pour les comptes configurés en Smart card required for interactive logon, prise en charge du NTLM réseau autorisé lorsqu'un utilisateur est restreint à des appareils joints au domaine spécifiques, et le SID d'identité de clé publique récent pour les clients Kerberos s'authentifiant avec la PKInit Freshness Extension) et la fonctionnalité optionnelle de pages de base de données 32k du niveau Windows Server 2025.

La checklist de l'ANSSI traite ce point comme un défaut noté à part entière, sous « Insufficient forest and domains functional levels » : l'alerte se déclenche à son premier palier de maturité quand le niveau fonctionnel de forêt est inférieur à Windows Server 2008 R2, au palier 3 en dessous de Windows Server 2012 R2, et au palier 4 en dessous du niveau Windows Server 2016. La justification donnée est qu'« utiliser un niveau fonctionnel faible prive la forêt de fonctionnalités de sécurité importantes ».

Les clients legacy retiennent votre chiffrement Kerberos en otage

Le même mécanisme s'applique au chiffrement. La documentation Microsoft sur la détection et la remédiation de l'usage de RC4 dans Kerberos explique que RC4 « est typiquement utilisé dans les environnements Windows lorsque des comptes ou des appareils ne supportent pas des types de chiffrement plus forts comme AES-SHA1 » — et que lorsqu'un compte n'a aucune valeur msDS-SupportedEncryptionTypes, le KDC retombe sur la valeur DefaultDomainSupportedEncTypes à l'échelle du domaine.

Ce repli est le piège. Assouplir DefaultDomainSupportedEncTypes pour garder une appliance fonctionnelle « change le comportement de tous les comptes qui n'ont pas de valeur définie », selon les mots de Microsoft. Un hôte, une régression à l'échelle du domaine. C'est le même mécanisme derrière le fallback Kerberos RC4, et c'est ce qui maintient le Kerberoasting économiquement viable : les tickets de service chiffrés en RC4 se craquent hors ligne bien plus vite que ceux en AES.

Windows Server 2025 ferme complètement la porte, et l'avertissement de Microsoft mérite d'être cité intégralement :

Relisez cette dernière phrase. Un seul appareil limité à RC4 ne fait pas qu'affaiblir le domaine — il peut vous forcer à garder des contrôleurs de domaine plus anciens, ce qui à son tour plafonne votre niveau fonctionnel, ce qui à son tour bloque le durcissement que vous cherchiez à déployer. La dépendance remonte de l'appliance vers l'annuaire.

Le changement de défaut RC4 est déjà déployé

Ce n'est pas un problème futur. KB5073381, qui traite la CVE-2026-20833, a déployé le changement en plusieurs phases :

La porte de secours du rollback a disparu. Si une dépendance legacy ne fonctionnait que grâce à l'ancien défaut RC4, elle est déjà cassée ou déjà couverte par une exception explicite.

Détection

Commencez par trois inventaires. Aucun ne nécessite d'agent, et les trois sont assez peu coûteux pour tourner chaque semaine.

1. Répartition des systèmes d'exploitation sur les objets ordinateur. L'attribut operatingSystem est renseigné par la machine elle-même lors de la jonction au domaine et rafraîchi au démarrage — c'est donc une première approximation raisonnable, sans être une preuve absolue :

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object { $_.Enabled -eq $true } |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Croisez avec LastLogonDate : un OS obsolète qui ne s'est pas authentifié depuis un an relève du nettoyage, pas d'un blocage de migration. Traitez comme véritable contrainte ceux qui se sont connectés cette semaine. Cela complète la revue d'identité machine couverte dans la surface d'attaque des objets ordinateur Active Directory — cet article couvre la découverte d'objets machine obsolètes et dangereux ; celui-ci couvre ce qu'il faut faire quand vous ne pouvez pas les supprimer.

2. Versions d'OS des contrôleurs de domaine et niveaux fonctionnels actuels.

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog, Site

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'msDS-Behavior-Version'

3. Usage réel de RC4. Microsoft publie deux scripts open-source, List-AccountKeys.ps1 et Get-KerbEncryptionUsage.ps1, dans le dépôt Kerberos-Crypto :

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Pour trouver les comptes épinglés sur RC4 par configuration plutôt que par capacité, interrogez directement l'attribut — la valeur décimale 4 signifie RC4 uniquement :

Get-ADObject -Filter "msDS-SupportedEncryptionTypes -eq 4" -Properties msDS-SupportedEncryptionTypes |
    Select-Object DistinguishedName, ObjectClass

Remédiation

Étape 1 — Cadrer l'exception par compte, jamais par domaine. Microsoft propose deux options lorsqu'un compte retombe sur le défaut du domaine, et une seule est sûre à l'échelle : « Définir la valeur msDS-SupportedEncryptionTypes spécifique dans les propriétés du compte pour s'assurer qu'il ne retombe pas sur la valeur DefaultDomainSupportedEncTypes. » Utilisez cette option. Réservez la valeur à l'échelle du domaine au durcissement, pas à l'assouplissement — le chemin de registre pour forcer AES-SHA1 uniquement est HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, valeur DefaultDomainSupportedEncTypes (REG_DWORD) définie à 0x18.

Étape 2 — Mettre en quarantaine ce que vous ne pouvez pas mettre à niveau. Pour chaque hôte qui doit survivre au-delà du 12 janvier 2027 :

1. Interdire toute connexion Tier 0. Aucun Domain Admin, aucun compte de service avec des droits à l'échelle du domaine, aucune délégation, ne devrait jamais s'authentifier sur un hôte non corrigeable.
2. Le restreindre au niveau réseau aux seuls ports et pairs dont il a réellement besoin.
3. Cadrer les etypes Kerberos avec une GPO ciblée plutôt qu'une politique de domaine. Dans Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité, définissez Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos, en la limitant à l'OU contenant uniquement les hôtes legacy.
4. Appliquer la signature partout ailleurs, pour que l'hôte faible ne puisse pas servir de relais pivot — voir signature SMB et signature LDAP.

Étape 3 — Mettre à niveau les contrôleurs de domaine en premier, et proprement. Microsoft est explicite sur la méthode : « La méthode recommandée pour mettre à niveau un domaine consiste à utiliser une installation propre de l'OS pour promouvoir de nouveaux serveurs en DC exécutant une version plus récente de Windows Server, puis à rétrograder les anciens DC selon les besoins. Cette méthode est préférable à la mise à niveau du système d'exploitation d'un DC existant. » La séquence documentée est : joindre le nouveau serveur, installer le rôle AD DS (qui exécute automatiquement adprep), le promouvoir, déplacer les rôles FSMO avec Move-ADDirectoryServerOperationMasterRole, puis rétrograder et retirer l'ancien DC.

# Repérer les détenteurs FSMO actuels avant de déplacer quoi que ce soit
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

Si vous choisissez plutôt une mise à niveau sur place, Microsoft exige que vous « exécutiez adprep /forestprep et adprep /domainprep manuellement » — forestprep une fois par forêt pour chaque version plus récente de Windows Server, domainprep une fois dans chaque domaine contenant des DC que vous mettez à niveau, à nouveau par version.

Étape 4 — Choisir la bonne cible. Selon les chemins de mise à niveau sur place supportés de Microsoft, Windows Server 2016 peut être mis à niveau sur place, via support d'installation, vers Windows Server 2019, 2022 ou 2025. Windows Server 2012 R2 peut aller directement vers Windows Server 2025, car « à partir de Windows Server 2025, les systèmes non en cluster peuvent monter jusqu'à quatre versions à la fois » — mais les mises à niveau en cluster restent limitées à une version à la fois.

Étape 5 — Relever les niveaux fonctionnels en dernier. Seulement après que le dernier DC legacy a été rétrogradé et retiré. Notez que ceci est largement à sens unique : le rollback du niveau fonctionnel de forêt se limite à un retour vers Windows Server 2012 R2 ou Windows Server 2008 R2 depuis une mise à niveau de ces niveaux, et le rollback au niveau domaine n'existe que lorsque vous relevez vers Windows Server 2016 avec un niveau de forêt Windows Server 2012 ou inférieur.

🚨 Danger : ne relevez pas le niveau fonctionnel tant qu'un DC non supporté est encore joint. La consigne de Microsoft est que si la forêt contient des DC à un niveau fonctionnel plus ancien que ce qu'un nouvel OS supporte, « l'installation est bloquée » et ces DC « doivent être retirés et le niveau fonctionnel de la forêt relevé vers une version supportée avant d'ajouter de nouveaux DC Windows Server à votre forêt ».

Le séquencement compte plus que la vitesse ici. Mettre en quarantaine, puis mettre à niveau les DC, puis relever les niveaux, puis durcir le chiffrement à l'échelle du domaine. Faire cela dans un autre ordre casse la production ou vous laisse avec un domaine durci sur le papier qui retombe encore sur son membre le plus faible — l'un des schémas récurrents des mauvaises configurations de sécurité Active Directory les plus courantes.

Comment EtcSec détecte cela

EtcSec fait remonter cette chaîne de dépendance exacte à partir d'un seul audit en lecture seule, sans agent sur les hôtes legacy. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 et COMPUTER_OS_OBSOLETE_VISTA inventorient les objets machine dont les systèmes d'exploitation ne reçoivent plus de mises à jour de sécurité, classés selon qu'ils s'authentifient encore. PR001_5_1_DC_OS_OBSOLETE isole le cas bien plus sérieux — un contrôleur de domaine lui-même exécutant un OS obsolète — car c'est le contrôle qui détermine si votre Tier 0 est corrigeable ou non. ANSSI_R15_LOW_FUNCTIONAL_LEVEL rapporte les niveaux fonctionnels actuels de forêt et de domaine par rapport à la référence recommandée, afin que vous puissiez voir immédiatement quel DC legacy plafonne l'annuaire.

Pris ensemble, ces contrôles répondent à la seule question qui compte avant le 12 janvier 2027 : quels hôtes précis retiennent le domaine, et que se passerait-il réellement si vous les retiriez. Relancer l'audit après chaque étape de remédiation prouve que le niveau a bougé — l'approche décrite dans auditer la sécurité Active Directory et prouver la remédiation.