Il y a des chantiers qu’on reporte depuis des années. Pas parce qu’ils sont impossibles, mais parce qu’il y a toujours un truc qui bloque. Dans mon cas, c’était Exchange 2013 — ce bon vieux serveur mail qui se fichait en travers de toute tentative de modernisation de l’AD. Depuis sa migration vers une solution plus légère, la voie était libre. Voilà donc le récit d’une nuit de boulot bien remplie.
Le contexte
L’infrastructure tourne sur deux domaines Active Directory distincts reliés par une relation d’approbation bidirectionnelle :
- Un domaine dédié aux serveurs et à l’infrastructure
- Un domaine dédié aux stations de travail et utilisateurs
Cette séparation est volontaire : si un compte utilisateur est compromis côté stations, l’attaquant ne peut pas rebondir automatiquement sur l’infrastructure critique. C’est du bon sens en matière de segmentation.
Les deux domaines tournaient depuis des années en niveau fonctionnel Windows Server 2012 R2, alors que les contrôleurs de domaine sont tous en Windows Server 2016. C’est le genre de dette technique qui s’accumule sans faire de bruit — jusqu’au jour où on décide de s’en occuper.
Prérequis avant de toucher quoi que ce soit
1. Vérifier la santé de la réplication AD
Avant toute opération sur les niveaux fonctionnels, on vérifie que tous les DCs sont sains et répliquent correctement :
repadmin /replsummary
La sortie doit montrer 0 échec sur tous les contrôleurs de domaine source et destination. Si des erreurs apparaissent, on s’arrête là et on les corrige d’abord.
dcdiag /test:replications
Ce test doit se terminer par un succès sur chaque DC. Aucune tolérance pour des erreurs de réplication avant une montée de niveau fonctionnel.
2. Identifier les rôles FSMO
netdom query fsmo
Il faut savoir précisément qui détient quels rôles. Points importants :
- Le Schema Master et le Domain Naming Master sont des rôles de forêt — ils vivent dans le domaine racine
- La commande pour monter le niveau de la forêt doit être exécutée depuis le DC qui détient le Schema Master, pas n’importe quel DC
C’est un point qui m’a d’ailleurs valu une erreur lors de la manipulation — j’y reviens plus bas.
3. Backup complet avant tout
La montée de niveau fonctionnel est irréversible. On ne peut pas redescendre sans restaurer un backup. Donc on fait un full backup de tous les DCs avant de commencer. Pas de compromis là-dessus.
# Vérifier les niveaux actuels avant intervention
Get-ADDomain | Select DomainMode
Get-ADForest | Select ForestMode
La montée en niveau fonctionnel
Domaine et forêt — dans le bon ordre
La procédure est simple mais l’ordre compte :
- Monter d’abord le niveau du domaine
- Monter ensuite le niveau de la forêt
- Répéter pour chaque domaine
Sur le PDC Emulator du domaine :
Set-ADDomainMode -Identity mondomaine.local -DomainMode Windows2016Domain
PowerShell demande une confirmation — c’est normal et bienvenu.
Sur le DC qui détient le Schema Master (domaine racine) :
Set-ADForestMode -Identity mondomaine.local -ForestMode Windows2016Forest
L’erreur classique à éviter
Si vous lancez la commande Set-ADForestMode depuis un DC qui n’est pas le Schema Master, vous obtiendrez :
Set-ADForestMode : Une référence a été renvoyée par le serveur
Ce n’est pas une erreur catastrophique — c’est juste Windows qui vous dit d’aller sur le bon DC. Connectez-vous sur le Schema Master et relancez la commande.
Cas particulier : deux domaines, une seule forêt
Dans une architecture avec deux domaines dans la même forêt (ou reliés par approbation intra-forêt), le niveau de forêt est partagé. En montant la forêt depuis le domaine racine, la modification s’applique à l’ensemble. Quand vous tenterez de monter la forêt pour le second domaine, vous obtiendrez :
Set-ADForestMode : Impossible d'abaisser le niveau fonctionnel du domaine (ou de la forêt)
Malgré le message trompeur, ce n’est pas une erreur — c’est que c’est déjà fait. Une vérification confirme :
Get-ADDomain mondomaine.lan | Select DomainMode
Get-ADForest mondomaine.lan | Select ForestMode
Audit des approbations AD
Une fois les niveaux fonctionnels à jour, j’en ai profité pour auditer la relation d’approbation entre les deux domaines — mise en place il y a plus de dix ans et jamais vraiment revérifiée depuis.
Lire l’état d’une approbation
Get-ADTrust -Filter * | Format-List *
Les attributs importants à analyser :
| Attribut | Valeur attendue | Ce que ça signifie |
|---|---|---|
Direction |
BiDirectional | Les deux domaines se font mutuellement confiance |
ForestTransitive |
True/False | Approbation de forêt ou non |
SelectiveAuthentication |
False | Tout compte peut s’authentifier cross-domaine |
SIDFilteringQuarantined |
False | Pas de filtrage SID strict |
UsesAESKeys |
False* | Voir ci-dessous |
*UsesAESKeys : False ne signifie pas que RC4 est utilisé — c’est juste un flag AD qui indique que le chiffrement AES n’est pas explicitement forcé au niveau de l’objet d’approbation. La réalité du trafic Kerberos peut être très différente.
Vérifier le chiffrement Kerberos réel
La commande klist liste les tickets Kerberos actifs et leur type de chiffrement réel :
klist
Sur chaque ticket, cherchez la ligne Type de chiffrement KerbTicket. Sur une infrastructure en Windows Server 2016 avec des comptes configurés correctement, vous devriez voir :
Type de chiffrement KerbTicket : AES-256-CTS-HMAC-SHA1-96
C’est ce qu’on veut. AES-256 sur tous les tickets, y compris les tickets cross-domaine vers l’infrastructure (LDAP, CIFS, krbtgt inter-domaines). Le flag UsesAESKeys : False dans l’AD était donc trompeur — le trafic Kerberos était déjà en AES-256 en pratique.
Architecture de sécurité : bilan et réflexions
La segmentation domaines : bonne idée ?
La séparation stations/serveurs en deux domaines avec approbation est une approche de sécurité valide. En cas de compromission d’un compte utilisateur côté stations, l’attaquant ne dispose pas automatiquement de droits sur l’infrastructure serveur.
Mais cette barrière n’est efficace que si :
- Les comptes de services sont distincts par domaine — pas de compte unique qui s’authentifie des deux côtés
- Les scripts et tâches planifiées n’utilisent pas de comptes cross-domaine
- Les droits d’accès sur les partages cross-domaine sont gérés par des groupes dédiés, pas des comptes individuels
AGDLP : toujours d’actualité
Pour les accès cross-domaine aux partages fichiers, la méthode AGDLP reste la bonne pratique :
- Account (compte utilisateur dans le domaine stations)
- Global group (groupe global dans le domaine stations)
- Domain Local group (groupe local de domaine dans le domaine serveurs)
- Permission (droits NTFS sur le partage)
C’est plus de travail à mettre en place, mais ça donne une visibilité claire sur qui a accès à quoi, et ça facilite la gestion à long terme.
Ce qu’apporte le niveau fonctionnel 2016
Au-delà du nettoyage de dette technique, voici les gains concrets :
Sécurité Kerberos renforcée — support natif d’AES-256 pour tous les comptes, meilleure gestion des clés de session.
Windows LAPS natif — le niveau 2016 est un prérequis pour migrer de l’ancien client LAPS (MSI legacy) vers Windows LAPS intégré à Windows 11/Server 2022. Sur Windows 11 24H2, le client LAPS legacy n’est de toute façon plus nécessaire.
Privileged Access Management (PAM) — possibilité de créer des appartenances à des groupes avec expiration automatique, utile pour les accès temporaires privilégiés.
Base pour aller plus loin — prérequis pour une éventuelle montée vers les niveaux fonctionnels 2019 ou 2022.
Commandes de vérification post-opération
# Vérifier les niveaux fonctionnels
Get-ADDomain | Select DomainMode
Get-ADForest | Select ForestMode
# Vérifier l'état des approbations
Get-ADTrust -Filter * | Select Name, Direction, TrustType, ForestTransitive
# Vérifier le chiffrement Kerberos en cours
klist
Une nuit de travail pour solder dix ans de dette technique. La montée de niveau fonctionnel en elle-même est rapide — quelques commandes PowerShell et c’est plié. Le vrai travail c’est la préparation : s’assurer que la réplication est saine, identifier correctement les rôles FSMO, faire un backup solide avant de toucher quoi que ce soit.
L’audit des approbations a été l’occasion de redécouvrir une configuration mise en place il y a longtemps et de constater qu’elle tenait toujours la route — ce qui est rassurant. Et la vérification Kerberos a confirmé que le chiffrement AES-256 était déjà en place en pratique, malgré un flag AD qui laissait penser le contraire.
Le prochain chantier : migrer LAPS legacy vers Windows LAPS natif maintenant que le niveau fonctionnel le permet.
Il va aussi falloir penser a upgrader l’OS de mes controlleurs…..