Une GPO de synchronisation de l’heure, poussée sur tous mes serveurs à l’époque de Windows Server 2012 pour contourner des soucis/caprices de w32time à l’époque, forçait chaque machine à interroger directement un serveur ntp chrony, en court-circuitant la hiérarchie de temps native d’Active Directory. Ce contournement a survécu à deux migrations (2012 → 2016 → 2022) sans jamais causer de problemes. Mais Il n’a jamais vraiment été sain. Le durcissement Kerberos de juillet 2026 (déprécation RC4, CVE‑2026‑20833) a retiré ce coussin, et dix ans de dette technique se sont manifestés en quelques heures : authentification inter-domaines en échec, réplication AD en « Accès refusé », partages inaccessibles.

Le contexte de l’infra

Mon infra perso repose sur une forêt Active Directory unique à deux arbres — un point d’architecture qui a son importance pour la suite, et que j’avais moi-même mal étiqueté pendant longtemps :

  • alpha.lan : domaine racine de forêt. Deux contrôleurs de domaine, DC-A1 (PDC Emulator racine) et DC-A2.
  • beta.lan : second arbre de la même forêt. Deux contrôleurs, DC-B1 (PDCe du domaine) et DC-B2.

Ce n’est pas un environnement multi-forêt avec une approbation manuelle : c’est un trust tree-root intra-forêt, automatique et transitif (attribut withinforest). La distinction change tout quand il faut réparer une clé de confiance ou raisonner sur le SID filtering.

Tous les DC sont des VM Hyper-V. Deux sources de temps internes servent de référence NTP amont : NTP-1 (10.0.10.10) et NTP-2 (10.0.10.5).

Un mot sur NTP, ce parent pauvre

Avant d’entrer dans l’incident, un détour qui n’en est pas un : NTP est l’un des services les plus négligés de nos infras, et l’un des plus fondamentaux. On le configure une fois, il « marche », et on l’oublie — jusqu’au jour où il se rappelle à nous de la pire façon.

Or l’heure est le socle silencieux sur lequel repose une quantité de choses :

  • La corrélation des logs. Sans une heure cohérente sur tous les équipements — switches, bornes Wi‑Fi, NAS, hyperviseurs, pare-feu, DC — impossible de reconstituer un incident. Quand un switch tombe et qu’une borne Wi‑Fi perd la connectivité dans la foulée, c’est la simultanéité des événements dans les journaux qui permet de relier la cause à l’effet. Si le switch horodate à 14:03:12 et la borne à 14:07:40 alors qu’ils sont tombés ensemble, l’enquête est morte avant de commencer.
  • La sécurité. Kerberos, la validité des certificats TLS, les jetons MFA, les fenêtres anti-rejeu : tout dépend d’une heure fiable et partagée.
  • La cohérence des systèmes distribués — réplication AD, clusters, sauvegardes incrémentales.

Bref, NTP mérite le même soin qu’on accorde à un switch cœur de réseau. On pense à le pousser sur les équipements réseau, les bornes, les NAS — et on a raison. Mais attention : Windows a sa propre logique. Sur un équipement Linux ou réseau, on pointe une source dans ntp.conf/chrony.conf et c’est réglé. Sur un domaine Active Directory, ce réflexe est un piège : forcer une source externe sur chaque machine casse la hiérarchie de temps native de la forêt. C’est exactement l’erreur que je vais raconter.

Le péché originel : la GPO « Date et heure » de 2012

À l’époque de Windows Server 2012, w32time avait une réputation méritée de capricieux. Pour en finir avec des dérives d’horloge, j’avais créé une GPO qui poussait, sur toutes les OU serveurs et stations, la configuration suivante :

Configurer le client NTP Windows :
  NtpServer          = 10.0.10.10
  Type               = NTP        <-- le problème
  CrossSiteSyncFlags = 0
  SpecialPollInterval= 3600

Sur le moment, ça « réglait » le problème : chaque machine allait chercher l’heure directement sur l’appliance, point. Sauf que Type = NTP ignore purement et simplement la hiérarchie de temps d’Active Directory (NT5DS). Chaque station, chaque serveur membre, chaque DC disciplinait son horloge indépendamment, hors de la pyramide AD.

Cette GPO a traversé la migration vers 2016, puis vers 2022. Personne ne l’a jamais remise en cause — elle « marchait ». Or elle ne marchait pas : elle masquait un défaut structurel.

Pourquoi ça a tenu dix ans

La règle d’or : Kerberos tolère un écart d’horloge de 5 minutes entre le client et le KDC. Tant que l’appliance NTP répondait et que les machines restaient dans cette fenêtre, le petit décalage résiduel entre une station et son contrôleur de domaine était absorbé par cette tolérance. On vivait sur une marge.

Un montage bancal peut tenir des années tant que rien ne consomme cette marge. La bonne architecture, elle, est auto-correctrice :

        Source externe (NTP-1 / NTP-2)
                 │
        DC-A1  (PDCe racine de forêt)   <-- seule source "manuelle"
                 │
        ┌────────┴─────────┐
     DC-A2              DC-B1  (PDCe beta.lan)   <-- NT5DS, tire du PDCe racine
                            │
                        DC-B2  +  serveurs membres  +  stations   <-- NT5DS

Une seule autorité au sommet, tout le reste en NT5DS qui suit la hiérarchie. C’est exactement ce que ma GPO de 2012 empêchait.

Le déclencheur : Microsoft s’en mêle en juillet 2026

Ce que je ne pouvais pas anticiper, c’est le durcissement Kerberos de 2026 lié à CVE‑2026‑20833. Microsoft retire RC4 comme algorithme de repli implicite, par phases :

  • Avril 2026 : le défaut passe à AES‑SHA1 pour les comptes dont les types de chiffrement sont à null. Le repli RC4 implicite est désactivé. Mode Audit encore disponible en rollback.
  • Juillet 2026 : phase finale. Le mode Audit disparaît, la clé de registre RC4DefaultDisablementPhase est ignorée, l’Enforcement AES devient le seul comportement supporté.

Concrètement, ce durcissement rend Kerberos plus strict et moins tolérant. Ce qui « passait quand même » avant — un ticket de secours en RC4, une négociation indulgente sur un compte mal configuré, un poste légèrement décalé — est désormais rejeté net. La marge de 5 minutes qui me sauvait a fondu, et les horloges disciplinées chacune dans leur coin par la GPO Type = NTP se sont retrouvées, pour certaines, du mauvais côté de la tolérance.

Les symptômes, dans l’ordre où ils sont tombés

  1. Perte d’accès aux partages inter-domaines : un utilisateur de beta.lan ne pouvait plus atteindre une ressource sur alpha.lan. L’intra-domaine, lui, fonctionnait.
  2. klist get krbtgt/ALPHA.LAN → STATUS_NO_TRUST_SAM_ACCOUNT (0xc000018b) depuis un poste.
  3. Réplication AD en « Accès refusé » (erreur 5) : DC-B1 n’arrivait plus à répliquer les partitions forest-wide (Configuration, Schema, ForestDnsZones) depuis les DC de alpha.lan, alors que l’intra-domaine passait.
  4. dcdiag /test:CheckSecurityError pointait une « différence de temps entre le client et les contrôleurs de domaine ».

Les fausses pistes (la partie honnête)

C’est là que le diagnostic devient instructif, parce que plusieurs indices m’ont envoyé — et auraient envoyé n’importe qui — dans le mur.

Fausse piste n°1 — le RC4. La date collait tellement bien avec l’enforcement RC4 que j’ai d’abord soupçonné un problème d’enctype sur l’approbation. Mais l’erreur n’était pas KDC_ERR_ETYPE_NOTSUPP : c’était un problème de compte de trust. Le code d’erreur tranche, pas l’intuition.

Fausse piste n°2 — le secret de trust. Le STATUS_NO_TRUST_SAM_ACCOUNT criait « clé de confiance cassée ». Sauf que nltest /sc_verify renvoyait NERR_Success. Piège classique : sc_verify ne teste que le canal sécurisé Netlogon, pas la clé Kerberos inter-royaume du trust. Les deux peuvent diverger.

Fausse piste n°3 — le décalage d’horloge, version DC. dcdiag annonçait une « différence de temps ». Mais en comparant l’UTC réel ([DateTime]::UtcNow) entre les DC des deux arbres, l’écart était de… quelques millisecondes. dcdiag, quand il voit un « Accès refusé », suppose le skew par heuristique — ce n’est pas une mesure. Les DC étaient à l’heure.

Le vrai déclic est venu de la lecture patiente des métadonnées de réplication et des tickets Kerberos, pas d’une hypothèse séduisante.

La cause racine

En remettant les pièces en ordre :

  • Les secrets d’infra (krbtgt, comptes machine, clé de trust) étaient fondamentalement sains. Rien n’avait été corrompu.
  • Ce qui a tout enclenché, c’est un écart d’horloge entre les deux arbres — invisible tant que Kerberos tolérait 5 minutes, fatal une fois le durcissement passé. Les horloges, disciplinées chacune dans leur coin par la GPO Type = NTP, n’avaient plus la hiérarchie auto-correctrice qui aurait maintenu tout le monde aligné.
  • Et comme l’authentification inter-arbres reposait sur ces horloges, sa mise en échec a bloqué la réplication AD elle-même — qui, du coup, ne pouvait plus réaligner automatiquement ce qui avait glissé. Un cercle vicieux : la réplication était morte parce que Kerberos échouait, et Kerberos échouait parce que le temps avait glissé sans que rien ne le rattrape.

Le vrai fil rouge, ce n’était pas un composant cassé. C’était une dette technique invisible (la GPO NTP de 2012) + un changement de plateforme qui retire le filet (le durcissement Kerberos de juillet 2026). Le contournement n’était pas une bombe tant que Kerberos était permissif ; le durcissement l’a amorcé, en même temps que deux ou trois autres raccourcis du même âge.

C’est le vrai enseignement : « ça part en vrille d’un coup » est presque toujours le symptôme d’une dette latente qu’un changement externe vient déclencher — pas d’un événement isolé.

La remédiation

1. Débloquer l’urgence

Réalignement des clés de confiance sur le trust intra-forêt (méthode netdom trust … /resetOneSide avec le même /passwordT des deux côtés — elle fonctionne même réplication à terre, puisqu’elle impose la valeur des deux côtés), suivi d’un cycle propre des KDC et d’une purge des tickets du compte SYSTEM :

klist -li 0x3e7 purge
net stop kdc & net start kdc
repadmin /syncall /AdeP

Une fois les clés réalignées, la réplication est repartie et l’accès aux partages est revenu.

2. Corriger le vrai coupable : la GPO de temps

Le correctif tient en un seul paramètre. Dans la GPO « Date et heure », passer les serveurs membres et stations de Type = NTP à Type = NT5DS :

Configurer le client NTP Windows :
  Type               = NT5DS
  CrossSiteSyncFlags = 2      (utile pour un futur DC/GC sur site distant)

Puis, la source externe ne doit vivre que sur le PDCe racine de forêt. La bonne pratique est de la porter par une GPO dédiée, filtrée en WMI pour ne cibler que le PDCe, de sorte qu’elle suive le rôle s’il est déplacé :

Filtre WMI : SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5

Sur le PDCe racine uniquement :
  Type      = NTP
  NtpServer = 10.0.10.10,0x8 10.0.10.5,0x8
  reliable  = yes

Sur les DC de test / membres / stations : Type = NT5DS, reliable = no.

3. Vérifier la hiérarchie

w32tm /query /source

État sain attendu :

  • DC-A1 (PDCe racine) → 10.0.10.10
  • DC-A2, DC-B1, DC-B2, serveurs, stations → le nom de leur DC, jamais l’IP de l’appliance.

4. Deux garde-fous spécifiques à la virtualisation

  • Désactiver la synchronisation de temps de l’intégration Hyper-V sur les VM contrôleurs de domaine. Sinon l’hôte réinjecte son heure par-dessous et court-circuite toute la hiérarchie — d’autant plus dangereux après un changement de carte mère ou une pile CMOS fatiguée.
  • Fiabiliser les sources amont (NTP-1 / NTP-2) : puisque toute la forêt en dépend via le PDCe, l’idéal est qu’au moins l’une soit sur une source stratum‑1 (GPS ou équivalent). C’est là qu’est la vraie robustesse, pas dans le fait de multiplier les autorités.

À faire avant l’enforcement final : la chasse au RC4

Puisque le durcissement de juillet 2026 est ce qui a tout révélé, autant en tirer la bonne action de fond. Les nouveaux événements KDC (introduits début 2026) signalent l’usage RC4 résiduel dans le journal Système des DC :

Get-WinEvent -FilterHashtable @{LogName='System';Id=201,202,203,204,205} -MaxEvents 100 |
  Select TimeCreated, Id
  • Journal vide → on peut basculer les comptes concernés en AES seul (msDS-SupportedEncryptionTypes = 0x18) sereinement.
  • Événements présents → il reste des dépendances RC4 (comptes de service, applications, comptes machine restaurés en null) à corriger avant que l’Enforcement ne le fasse à votre place, avec un arrêt de service à la clé.

Ce que je retiens

  • Un contournement n’est pas un correctif. Celui de 2012 a « marché » dix ans en masquant un défaut structurel. Le jour où la plateforme a durci, la dette est arrivée à échéance — d’un coup.
  • Les migrations propagent les vieux réglages sans les questionner. 2012 → 2016 → 2022 : la GPO a suivi, invisible, jamais auditée.
  • Le code d’erreur prime sur l’intuition. RC4, trust, skew : trois hypothèses séduisantes, trois fausses pistes. Ce sont les métadonnées et les tickets qui ont tranché.
  • En temps AD, une seule règle : un sommet, tout le reste en NT5DS. Forcer Type = NTP partout, c’est fabriquer un split-brain d’horloges qui n’attend qu’un durcissement pour tomber.
  • NTP n’est pas un détail, c’est une fondation. On le soigne partout — switches, bornes, NAS, hyperviseurs — ne serait-ce que pour des logs corrélables entre équipements. Mais on n’applique pas à un domaine Windows la recette d’un chrony.conf : AD a sa hiérarchie à lui, et la respecter n’est pas optionnel.

Si votre infra traîne encore une GPO de temps « historique » qui pousse une source manuelle sur autre chose que le PDCe racine : profitez de la vague de durcissement Kerberos 2026 pour la nettoyer. C’est cinq minutes de GPO aujourd’hui, ou une soirée de diagnostic le jour où Microsoft retirera le prochain filet.