🌐 Aussi en: English · Deutsch · Español
Dans l’article précédent, trois machines HP sont devenues un domaine Windows Server 2025 : AD, DNS, basculement DHCP, stratégies de groupe, BitLocker, Storage Spaces. C’était le jour un : tout installé, tout au vert, tout « fonctionne ».
Cet article parle du jour deux, le moment où l’on arrête d’admirer les coches vertes pour commencer à poser des questions qui fâchent. Quelle heure est-il, et selon qui ? Quels services tournent sans que personne ne les ait demandés ? Que se passe-t-il si un serveur refuse tout simplement de démarrer demain ? Spoiler : l’une de ces questions avait une réponse très drôle.
Même configuration que la dernière fois : je décide, et mon co-admin IA (Claude, qui pilote PowerShell via WinRM) fait l’inventaire, applique les changements et vérifie le résultat après chaque étape. D’abord lire, ensuite modifier, enfin vérifier. Ennuyeux à dessein.
🔍 Étape zéro : l’inventaire avant les opinions
Avant de toucher à quoi que ce soit, un passage en lecture seule sur les trois DC : build de l’OS, RAM, mode de gestion de l’alimentation, rôles installés, services en cours, configuration SMB, protection LSA, signature LDAP, source de temps, Defender, taille des journaux d’événements, ordre DNS de la carte réseau, fichier d’échange, disques, profils du pare-feu. Plus le domaine lui-même : stratégie de mots de passe, niveau fonctionnel, schéma LAPS, nettoyage DNS, liste des GPO.
Anecdote : la première version de ce script d’inventaire n’a renvoyé absolument rien. Pas d’erreur, pas de sortie, juste le silence. WinRM (via pywinrm) envoie PowerShell sous forme de ligne de commande UTF-16 encodée en Base64, et Windows limite les lignes de commande à 8191 caractères. Un script de 3,5 Ko devient ~9,5 Ko sur le fil et… s’évapore. Coupé en trois, et soudain les serveurs ont beaucoup de choses à raconter.
🕰️ L’horloge qui n’obéissait à personne
Ma trouvaille préférée de la journée :
PS> w32tm /query /source
Free-running System ClockC’était sur HP1, l’émulateur PDC, le seul contrôleur de domaine dont tout le rôle dans la hiérarchie du temps est d’être l’horloge de référence du domaine. Chaque membre du domaine se synchronise sur un DC, chaque DC se synchronise sur le PDC… et le PDC se synchronisait sur son propre quartz et ses bonnes intentions. Le domaine entier tenait une heure parfaitement cohérente et parfaitement hors-sol.
Pourquoi c’est important : par défaut, Kerberos tolère 5 minutes de décalage d’horloge. Au-delà, les ouvertures de session commencent à échouer avec des erreurs qui ressemblent à tout sauf à « votre horloge est fausse ». La correction tient en trois lignes, uniquement sur le PDC :
w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x8 ptbtime2.ptb.de,0x8 ptbtime3.ptb.de,0x8" `
/syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /rediscoverLa PTB est l’institut national de métrologie allemand : le domaine prend désormais son heure chez les gens qui définissent littéralement la seconde dans ce pays. HP1 annonce la strate 2, les deux autres DC suivent HP1. Hiérarchie rétablie. Les iLO ont eu droit au même traitement plus tard : ils n’avaient aucun NTP, et deux d’entre eux se croyaient en « Eastern Europe (DST disabled) ».
🌐 Ordre DNS du client : pourquoi HP2 a paniqué quand HP1 a redémarré
Vous vous souvenez de la remarque de la dernière fois, selon laquelle HP2 avait refusé les ouvertures de session pendant environ sept minutes pendant le redémarrage de HP1 ? L’inventaire l’a expliqué : la carte réseau de HP2 avait exactement un serveur DNS configuré, HP1. Pas de HP1, pas de DNS, pas d’enregistrements SRV, pas de DC trouvé, pas de Kerberos. HP1 lui-même ne pointait que sur 127.0.0.1.
L’ordre recommandé pour la carte réseau d’un DC est : un DC partenaire d’abord, un autre partenaire ensuite, le loopback en dernier. Le partenaire d’abord, pour qu’un DC fraîchement démarré n’attende pas son propre service DNS pas encore lancé. Le loopback en dernier, pour qu’il résolve encore quand tous les autres sont tombés. HP3 était déjà configuré ainsi, et maintenant les trois le sont.
🗺️ Sites AD : renommer « Default-First-Site-Name »
Chaque forêt commence avec un site appelé Default-First-Site-Name et aucun sous-réseau. Avec trois DC dans une même baie, un seul site est exactement ce qu’il faut. La réplication intra-site utilise la notification de modifications (~15 secondes), et ajouter des sites ne ferait que ralentir les choses.
Deux petits changements malgré tout : le site a été renommé en Homelab (renommer, jamais supprimer et recréer ; AD le suit par son GUID, et Netlogon réenregistre tout seul les enregistrements SRV _sites), et 192.168.10.0/24 lui a été attribué. Chaque client peut désormais associer son IP à un site, ce qui évite les événements Netlogon 5807 pour sous-réseaux inconnus. Comme vous le verrez plus bas, c’est aussi lié au fonctionnement de Windows Update après WSUS.
🖨️ Des services que personne n’a commandés
Windows Server avec Expérience de bureau embarque un nombre surprenant de services qui ont du sens sur un portable et aucun sur un contrôleur de domaine dans une baie. Désactivés sur les trois :
- Spouleur d’impression : le gros morceau. PrintNightmare, et le « printer bug » qui permet à un attaquant de forcer un DC à s’authentifier ailleurs. Microsoft recommande lui-même de le désactiver sur les DC. Personne n’imprime depuis un contrôleur de domaine. Personne.
- Audio (
Audiosrv,AudioEndpointBuilder) : mes DC ne chantent pas. - Géolocalisation (
lfsvc) : ils savent aussi très bien où ils sont. Dans la baie. - Gestion radio (
RmSvc), notifications push (WpnService), télémétrie (DiagTrack), publication de la découverte réseau (FDResPub,fdPHost).
Avertissement honnête : cela ne rend pas les serveurs mesurablement plus rapides. HP1 a 64 Go de RAM dont 60 Go libres, une poignée de services inactifs n’est donc pas un goulot d’étranglement. C’est de la réduction de surface d’attaque et de bruit, pas un bouton turbo. Quiconque vous vend « désactivez 40 services pour 30 % de performances en plus » sur un serveur moderne vous vend un placebo.
🔐 Durcissement, la liste sans paillettes
- Stratégie de mots de passe & de verrouillage : la longueur minimale était de 7 (une valeur par défaut tout droit sortie de 2003). Désormais 12, et verrouillage du compte après 10 tentatives échouées pendant 15 minutes, là où avant il n’y en avait jamais. Piège : le modèle de sécurité de la Default Domain Policy et l’objet domaine doivent concorder. Si vous ne modifiez que l’objet domaine, le PDC le remet discrètement à l’ancienne valeur au prochain rafraîchissement des stratégies.
- Windows LAPS : schéma étendu, l’OU des clients autorisée à écrire ses propres attributs de mot de passe, GPO liée. Chaque client reçoit désormais son propre mot de passe administrateur local aléatoire de 16 caractères, renouvelé tous les 30 jours et stocké chiffré dans AD, lisible uniquement par les admins du domaine. C’est désormais intégré à Windows, sans MSI séparé comme l’ancien LAPS.
- LDAP : liaison de canal imposée. Le passage complet à « signature requise » est la prochaine étape, après avoir vérifié les journaux à la recherche de liaisons non signées (il n’y en avait aucune).
- Protection LSA (
RunAsPPL) : LSASS tourne en processus protégé, ce qui complique sérieusement le vol d’identifiants classique façon Mimikatz. Activée sur les trois, puis mise en service par un redémarrage tournant, un DC à la fois et jamais en parallèle (leçon retenue de la dernière fois). Vérifié à l’ancienne : après chaque démarrage, Wininit journalise l’événement 12, « LSASS.exe was started as a protected process with level: 4 ». Le redémarrage du serveur de fichiers a attendu que je ferme la base de notes que j’avais ouverte sur son partage. Redémarrer une machine sous ses propres fichiers ouverts, c’est un genre très particulier de but contre son camp. - Journaux d’événements : le journal Directory Service faisait 1 Mo. Un mégaoctet. De quoi couvrir à peu près « ce qui s’est passé depuis le déjeuner ». Désormais Security 1 Go, Directory Service 256 Mo, System/Application 128 Mo chacun. Le disque ne coûte rien, et l’investigation sans journaux est impossible.
- Nettoyage DNS : activé avec un vieillissement de 7+7 jours. Sans lui, chaque client DHCP qui s’est un jour enregistré garde son enregistrement A pour toujours, et au bout d’un an votre DNS est un musée.
- WinRM pour les clients : une GPO active WinRM sur l’OU des clients, avec le pare-feu ouvert uniquement au réseau domestique (
192.168.10.0/24), sans authentification Basic et sans trafic non chiffré. C’est le prérequis pour administrer les postes à distance, y compris avec Windows Admin Center, qui ira sur le poste d’administration (il n’est pas pris en charge sur un DC).
🪦 WSUS est mort. Alors qui télécharge les mises à jour maintenant ?
En 2024, Microsoft a annoncé que WSUS était déprécié. Il est toujours présent dans Server 2025 et toujours pris en charge, mais il ne reçoit plus de nouvelles fonctionnalités, et la direction est claire. Ma configuration est déjà passée à Windows Update + stratégies de groupe tout simplement : jours de report pour les clients, fenêtres de maintenance fixes pour les serveurs, un DC patché le samedi en guise de canari.
Mais WSUS remplissait deux rôles, et les règles d’approbation n’en couvrent qu’un. L’autre, c’était la bande passante : télécharger chaque mise à jour une seule fois depuis Internet, puis la distribuer à mille clients sur le LAN. Qu’est-ce qui remplace ça ?
L’optimisation de la distribution (Delivery Optimization). Elle est intégrée à Windows, et c’est en gros du BitTorrent pour les correctifs (avec moins de piratage et plus de Kerberos). Une mise à jour est découpée en morceaux. Le premier client récupère les morceaux sur le CDN de Microsoft. Chaque client suivant interroge d’abord ses pairs : « quelqu’un sur mon réseau a déjà le morceau 17 ? » Si oui, il arrive par le LAN ; sinon, depuis Internet. Plus un réseau compte de clients, plus le téléchargement reste local. 1 000 clients ne signifient plus 1 000× le téléchargement sur votre connexion Internet.
Les réglages qui comptent :
DODownloadMode = 1(LAN) : pairs derrière le même NAT/réseau. C’est ce qu’utilise ma GPO clients.DODownloadMode = 2(Groupe) avecDOGroupIdSource = 1(site AD) : les clients ne partagent qu’avec des pairs du même site AD. Ainsi, une agence ne tire pas de morceaux depuis le siège via le WAN lent. C’est pour cela que des sites et sous-réseaux propres comptent soudain à nouveau, et pourquoi le renommage du site plus haut n’était pas purement cosmétique.- Microsoft Connected Cache : la version adulte pour les grands environnements. Un nœud de cache local par site, qui récupère le contenu une fois et sert tout le monde, l’héritier spirituel du « télécharger une fois » de WSUS, sans la base WSUS et tout l’entretien qu’elle réclame.
Ce que vous perdez vraiment : l’approbation manuelle de mises à jour individuelles. Cela vit désormais dans les stratégies (reports, anneaux, échéances) ou, en entreprise, dans Intune/Windows Autopatch. Pour un homelab à deux clients, tout cela est glorieusement surdimensionné. Les deux portables se partagent quelques centaines de Mo par mois. Mais c’est agréable de connaître le mécanisme.
💾 Sauvegarde Windows Server : comment ça marche vraiment
Trois DC se répliquent mutuellement, donc AD lui-même est redondant. Mais la réplication n’est pas une sauvegarde : une OU supprimée se réplique aussi vite qu’une OU créée. (La corbeille AD de la dernière fois couvre le cas « oups, supprimé ». Elle ne couvre pas « le serveur ne démarre plus ».) HP1 et HP2 exécutent donc désormais chaque nuit une Sauvegarde Windows Server vers leur second SSD de 2 To, jusqu’ici vide.
Sous le capot :
- VSS d’abord. Le service de cliché instantané de volume fige un snapshot cohérent des volumes. La base de données d’AD (
ntds.dit) dispose d’un writer VSS, donc la copie est transactionnellement propre même pendant que le DC continue de travailler. Pas d’interruption, pas de mode maintenance. - Copie au niveau bloc dans des VHDX. Le snapshot est copié bloc par bloc dans des fichiers VHDX sur le volume cible. Après la première sauvegarde complète, les exécutions suivantes ne copient que les blocs modifiés, ce qui rend le job nocturne rapide.
- Versions via clichés instantanés sur la cible. Les anciennes versions sont conservées sous forme de clichés instantanés sur le volume de sauvegarde lui-même. Quand la place vient à manquer, les plus anciennes sont supprimées automatiquement. Aucun script de rétention nécessaire.
- Ce qui est inclus : Bare Metal Recovery (C:, la partition EFI, la partition de récupération) plus System State (base AD, SYSVOL, registre, fichiers de démarrage, les magasins COM+ et de certificats). La base DHCP se trouve sous
C:\Windows\System32\dhcp, elle en fait donc partie aussi.
Les trois scénarios de restauration :
- Fichiers isolés :
wbadmin get versions, puis restaurer des fichiers ou dossiers individuels depuis n’importe quelle version pendant que le serveur tourne. - Objets AD abîmés : démarrer en mode de restauration des services d’annuaire, restaurer le System State (non autoritaire : le DC se remet ensuite à niveau par réplication), ou marquer certains objets comme autoritaires avec
ntdsutilpour qu’ils l’emportent sur les autres DC. - Serveur mort, disque mort, OS mort : démarrer sur l’ISO de Windows Server → Réparer l’ordinateur → Récupération de l’image système, lui indiquer le disque de sauvegarde, et il reconstruit les partitions et restaure C: à l’identique. Pour un DC, c’est une restauration non autoritaire : il revient avec l’état de la nuit précédente, puis réplique tout ce qui est plus récent depuis ses partenaires. Cela doit se faire pendant la durée de vie des tombstones (180 jours), ce qui n’est jamais un problème avec un job nocturne.
La limite honnête : la sauvegarde vit dans la même machine. Cela couvre un disque système mort, une mise à jour ratée, un AD corrompu. Si la carte mère lâche, le SSD peut migrer dans une machine de remplacement. Mais un incendie, un vol ou un rançongiciel qui chiffre tous les volumes emporteraient la sauvegarde avec eux. C’est à ça que servent les copies sur une autre machine (voir la section suivante). Et pour un DC, il reste toujours un plan B : avec deux partenaires en bonne santé, réinstaller et re-promouvoir est souvent plus rapide que de restaurer quoi que ce soit.
📦 Sauvegardes, deuxième partie : sortir les archives familiales de la machine
Les DC peuvent toujours être reconstruits à partir de leurs partenaires. Les 1,5 To d’archives familiales sur le pool à parité de HP3, non. La parité protège contre la perte d’un SSD, pas contre un dossier supprimé, un rançongiciel ou un pool qui décide de passer une mauvaise journée. Le serveur de sauvegarde Linux qui récupère déjà mes instances Nextcloud récupère donc désormais aussi les partages du NAS.
- Un compte dédié en lecture seule.
svc-nas-backupreçoit Lecture sur les trois partages SMB et les droits NTFS de lecture et exécution, et rien d’autre : pas d’admin, pas d’Opérateurs de sauvegarde. (Les Opérateurs de sauvegarde sur un DC peuvent lirentds.dit, autrement dit : tout le domaine.) Son mot de passe aléatoire de 32 caractères se trouve dans un fichier d’identifiants réservé à root sur la machine Linux. - Montages automatiques CIFS en lecture seule. Les partages sont montés en
rovia fstab avecx-systemd.automount. Un test d’écriture depuis le serveur de sauvegarde échoue avec « read-only file system », et c’est exactement le but : un hôte de sauvegarde compromis ne peut pas chiffrer la source. - rdiff-backup, un dépôt par utilisateur. L’état actuel est stocké en fichiers ordinaires, les anciennes versions en diffs inverses, 30 jours d’historique. Le script refuse de sauvegarder un partage injoignable ou vide. Sinon, un hoquet réseau serait enregistré comme « l’utilisateur a tout supprimé ».
La première exécution a duré environ six heures, et les chiffres ont été une leçon sur ce qui coûte vraiment du temps. Mes 1,2 To (quelques milliers de grosses archives) ont défilé à ~108 Mo/s de façon régulière et étaient terminés en trois heures. Les 236 Go d’un autre membre de la famille, répartis sur 189 000 fichiers, ont pris presque autant de temps. Pour rdiff-backup, le nombre de fichiers compte bien plus que le volume de données. La deuxième exécution a pris 73 secondes.
Et oui, j’ai vérifié le nombre de fichiers ensuite. Il ne correspondait pas. Après un léger moment de panique : le Get-ChildItem de PowerShell ignore les fichiers cachés si l’on n’ajoute pas -Force. Avec -Force et sans le bric-à-brac exclu (Thumbs.db, .DS_Store, fichiers de verrouillage Office), les chiffres concordaient au fichier près. La confiance n’exclut pas le -Force.
🔐 BitLocker sur les serveurs : pour le jour où les disques quittent la maison
Mon modèle de menace est ici modeste : un disque qui meurt et repart sous garantie, ou un serveur que je revendrai dans cinq ans. Personne ne doit pouvoir y lire une base AD ou une photo de famille. Donc BitLocker avec TPM seul : pas de PIN, parce que des serveurs doivent démarrer sans surveillance.
- Clés de récupération dans AD, et en dehors. Une GPO sur l’OU Domain Controllers rend obligatoire la sauvegarde de la clé de récupération dans AD. Windows refuse de chiffrer si elle échoue. Les clés sont stockées sous l’objet ordinateur et répliquées sur chaque DC : les clés de HP3 sont apparues sur HP1 en moins d’une minute. Mais si les trois DC sont bloqués sur l’écran de récupération en même temps (après une mise à jour du BIOS sur tous, par exemple), la clé est dans AD et AD ne tourne pas. Il y a donc aussi une copie dans le gestionnaire de mots de passe.
- L’écran de récupération est en pré-démarrage, la console distante iLO fonctionne donc même sans licence Advanced. Avant les mises à jour de firmware,
Suspend-BitLocker -RebootCount 1évite complètement l’invite. - Les volumes de données se déverrouillent automatiquement, et sur le gros pool, seul l’espace utilisé est chiffré. Sinon, cela prendrait des jours sur la parité.
Deux rebondissements. D’abord, le TPM de HP1 se déclarait « owned » mais pas « ready for storage », sans SRK provisionnée. Il appartient probablement encore à une installation antérieure. Initialize-Tpm a répondu ClearRequired=True, il faut donc l’effacer. Je ne l’ai délibérément pas programmé comme paramètre BIOS en attente via Redfish : il se serait déclenché au prochain redémarrage automatique de Windows Update à 3 h du matin, et l’invite de présence physique aurait laissé le DC attendre devant une console que personne ne regarde. Ce sera fait à la main, console iLO ouverte.
Ensuite, le timing. HP1 et HP2 ont été redémarrés pour la protection LSA quelques minutes avant l’installation de la fonctionnalité BitLocker. Get-WindowsFeature annonce joyeusement « Installed », mais manage-bde.exe et le module PowerShell n’apparaissent qu’après le redémarrage suivant. HP3 a justement redémarré un jour plus tard pour des correctifs et a été chiffré dans la foulée ; les deux autres suivront après leur prochain redémarrage.
🔌 iLO : interroger directement le matériel
Les trois machines (deux ProLiant DL20 Gen10 Plus, un MicroServer Gen10 Plus v2) ont un iLO 5, et iLO 5 parle Redfish, une API REST sur HTTPS. Au lieu de cliquer dans trois interfaces web, un seul script Python a donc lu les paramètres BIOS, l’inventaire des firmwares, les températures, les ventilateurs et l’Integrated Management Log des trois.
- Alimentation : déjà optimale partout. Profil de charge General Power Efficient Compute, régulateur Dynamic Power Savings, états C6 du package. Les ventilateurs tournent à 6–8 % au repos. Rien à régler, et passer en « Static High Performance » ne ferait que transformer de l’électricité en chaleur pour une charge qui n’en a jamais besoin.
- Firmware : à jour (System ROM de 2026, iLO 5 v3.21).
- Wattmètre : affiche 0 W. Ces modèles d’entrée de gamme n’ont pas d’alimentations avec mesure. Tant pis.
- IML : surtout des événements « link down » qui coïncident avec du recâblage et des redémarrages du switch. Un DL20 a journalisé une seule uncorrectable PCIe error il y a deux mois, qui n’est jamais revenue. Elle reste sur la liste de surveillance.
- Ménage : fuseau horaire corrigé, NTP pointé vers les DC, noms d’hôte
-ilocohérents, et enregistrements A pour les iLO dans la zone AD, pour que la documentation et la réalité utilisent les mêmes noms.
🗜️ Déduplication : mesurée, puis refusée
Le pool ReFS à parité de HP3 contient environ 1,5 To d’archives familiales, et Server 2025 intègre une déduplication + compression ReFS toute neuve et rutilante. Tentant ! Alors avant d’activer quoi que ce soit : regarder les données.
- 77 % de
.rar, suivis de JPEG, ZIP et MP4. Tout est déjà compressé. Compresser des données compressées rapporte une erreur d’arrondi. - Vrais doublons (même nom, même taille, hors archives multi-parties) : ~72 Go, environ 5 %. Surtout des copies de vieux portables dans des copies de vieux portables. On est tous passés par là.
72 Go économisés contre des jobs d’optimisation nocturnes sur un pool dont les écritures de parité sont déjà le chemin lent, plus un magasin de blocs qui devient, sur un stockage à parité simple, un point unique de « un bloc défectueux abîme désormais de nombreux fichiers ». Avec 2,2 To libres, la réponse est non. La dédup brille sur les disques de VM, la VDI et les cibles de sauvegarde, pas sur un tas d’archives RAR. Faire le ménage des dossiers en double à la main coûte moins cher que n’importe quelle fonctionnalité.
🎯 À retenir
Le jour un fait fonctionner les choses. Le jour deux les rend dignes de confiance : une vraie source de temps, un DNS qui survit à un redémarrage, moins de services, une mémoire plus longue, des mots de passe qui se renouvellent tout seuls, et une sauvegarde à laquelle vous avez vraiment réfléchi avant d’en avoir besoin. Rien de tout cela n’est glamour, et presque rien n’apparaît sous forme de coche verte. Et la découverte la plus effrayante n’était pas un correctif manquant. C’était un domaine dont le sens du temps venait d’un quartz livré à lui-même.
Prochaine étape : l’effacement du TPM sur HP1 et BitLocker sur les deux premiers DC, et enfin l’application de la signature LDAP. C’est une seule option de sécurité dans la Default Domain Controllers Policy, et elle écrase discrètement la valeur de registre que j’avais définie en premier. Et ensuite peut-être, peut-être, à nouveau un peu de YAML. Il commence à me manquer. Un peu.
