Vous devez appliquer les correctifs de durcissement Netlogon, mais sans interrompre NTLM ? Voici un guide pratico‑pratique pour déployer les mises à jour récentes tout en gardant les authentifications NTLM opérationnelles grâce au RPC sealing sur le canal sécurisé.
Vue d’ensemble : pourquoi Netlogon a été durci et ce que cela change
La vulnérabilité CVE‑2022‑38023 a conduit Microsoft à renforcer progressivement le protocole Netlogon. Les mises à jour publiées à partir du 8 novembre 2022 exigent que les canaux sécurisés Netlogon établis par les membres du domaine (postes, serveurs, appliances, comptes d’approbation) ne se contentent plus d’une signature RPC (RPC signing), mais utilisent un chiffrement RPC (RPC sealing). Depuis l’été 2023, ce comportement est en application finale sur les contrôleurs de domaine : les connexions Netlogon qui ne chiffrent pas le canal sont rejetées par défaut.
Conséquence immédiate : NTLM n’est pas désactivé. Ce qui change, c’est la façon dont NTLM (et d’autres opérations de machine account) dialoguent avec le DC via Netlogon. Tant que vos clients négocient correctement RPC sealing, NTLM continue de fonctionner. Les échecs observés après patch viennent de clients qui ne chiffrent pas le canal Netlogon ou de liens d’approbation (trusts) restés en simple signature.
Résumé exécutif
- Objectif : appliquer les mises à jour Microsoft récentes sans casser NTLM.
- Idée clé : exiger RPC sealing pour Netlogon (côté clients et trusts). Les DC modernes refusent les connexions Netlogon signées seulement.
- Approche : 1) auditer les événements Netlogon, 2) mettre à jour et configurer les clients pour chiffrer, 3) déployer les patchs DC par vagues, 4) surveiller et finaliser le durcissement (optionnel : blocage RC4/MD5).
Ce qui casse typiquement après patch
Après l’installation des correctifs de durcissement Netlogon (y compris ceux liés à KB5021130), les symptômes suivants apparaissent si des clients ne scellent pas le canal Netlogon :
- “The trust relationship between this workstation and the primary domain failed” lors d’ouverture de session machine ou de changements de mot de passe machine.
- Domain join/rename ou opérations d’approbation (inter‑domain/forest trusts) qui échouent de manière intermittente.
- NAS, imprimantes, appliances de sauvegarde, solutions de proxy/VDI ou matériels OT/IoT qui n’ont pas reçu de firmware récent.
- Relations d’approbation externes (ou anciennes forêts) non mises à niveau.
Cartographier rapidement les risques : exploiter les événements Netlogon
Sur chaque contrôleur de domaine, le journal System (source NETLOGON) remonte des événements très parlants. Ils constituent la base de l’audit.
| Événement | Signification | Action de remédiation |
|---|---|---|
| 5838 | Un client utilise la signature RPC au lieu du chiffrement RPC (RPC sealing) pour le canal Netlogon. | Mettre à jour/configurer le client pour forcer le RPC sealing. |
| 5839 | Une relation d’approbation (trust) utilise seulement la signature. | Mettre à niveau les DC des deux côtés du trust, vérifier les paramètres d’inter‑forest trust. |
| 5840 | Canal Netlogon chiffré avec RC4 (crypto faible). Non bloquant pour CVE‑2022‑38023, mais à traiter. | Planifier la réduction de la crypto faible (voir RejectMd5Clients plus bas) après inventaire. |
| 5841 | Client RC4 refusé car RejectMd5Clients = TRUE. | Mettre à jour/remplacer le client qui ne sait pas négocier mieux que RC4/MD5. |
Exemple d’extraction multi‑DC en PowerShell (14 jours de rétention) :
Get-WinEvent -ComputerName (Get-ADDomainController -Filter *).HostName `
-FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5838,5839,5840,5841; StartTime=(Get-Date).AddDays(-14)} `
| Select MachineName,TimeCreated,Id,Message
Avant de patcher les DC : préparer les clients
Le succès du déploiement dépend de l’assainissement en amont. Concentrez‑vous sur les machines identifiées par 5838/5839/5840/5841, et plus globalement sur tout ce qui consomme Active Directory :
- Mises à jour OS/firmware : patcher Windows (clients/serveurs) vers des versions supportées, et appliquer les derniers CUs. Pour les équipements tiers (NAS, appliances, imprimantes, solutions Samba, hyperviseurs), installer un firmware ou un package qui supporte explicitement le RPC sealing Netlogon.
- Activer le chiffrement du canal sécurisé côté membres de domaine : via Stratégie de sécurité locale ou GPO :
- Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Domain member: Digitally encrypt or sign secure channel data (always) = Enabled
- (Recommandé) Domain member: Digitally encrypt secure channel data (when possible) = Enabled
- (Renforcement) Domain member: Require strong (Windows 2000 or later) session key = Enabled
- Produits et stacks non‑Windows : pour Samba et dérivés, vérifier que la configuration client/serveur schannel impose bien le chiffrement (paramètres schannel/require seal selon la distribution), et que la version est supportée.
- Approvals/trusts : recenser les relations d’approbation externes et inter‑forêts, patcher les DC de part et d’autre, puis valider la création du canal sécurisé.
Comprendre le comportement côté contrôleur de domaine
Les versions récentes de Windows Server appliquent l’exigence de RPC sealing par défaut. Historiquement, une clé registre permettait de piloter la phase :
| Clé (DC) | Valeur | Effet | Disponibilité actuelle |
|---|---|---|---|
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSeal | 0 | Désactivé (legacy) | Obsolète (non pris en charge sur builds récents) |
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSeal | 1 | Compatibilité : journalise, mais n’interdit pas | Obsolète depuis la phase d’application finale |
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSeal | 2 | Application : seules les connexions RPC sealing passent | État par défaut des builds actuels |
À retenir : sur les contrôleurs de domaine modernes, vous ne pouvez plus revenir à un mode “compatibilité” via le registre. La seule voie pour préserver NTLM est de mettre en conformité les clients.
Plan de déploiement recommandé
- Audit : collecter et centraliser 5838/5839/5840/5841 sur l’ensemble des DC (cf. script ci‑dessous). Classer par type d’actif (Windows, NAS, imprimante, applicatif), criticité, site.
- Mise en conformité des clients :
- Déployer les mises à jour OS/firmware.
- Appliquer la GPO “Digitally encrypt or sign secure channel data (always)”.
- Corriger les trusts (les deux côtés à jour).
- Pilote : sélectionner un site/contrôleur de test, appliquer les CUs, surveiller finement les journaux Netlogon et les échecs d’authentification.
- Généralisation par vagues : patcher progressivement les DC en garantissant la redondance au sein de chaque site AD, tout en continuant de traiter les exceptions détectées.
- Durcissement optionnel : quand l’inventaire 5840 est maîtrisé, activer le blocage des clients RC4/MD5 (voir ci‑après RejectMd5Clients).
Réduire la crypto faible : RC4/MD5 et RejectMd5Clients
La correction de CVE‑2022‑38023 n’interdit pas automatiquement RC4. Si votre politique sécurité exige de l’éradiquer, vous pouvez activer le rejet des clients incapables de signer avec mieux que MD5/RC4. La bascule doit être pilotée par l’audit (événements 5840 et 5841), et testée par vague pour éviter les interruptions de service.
- Étape 1 : surveiller 5840 (usage RC4) sur 2–4 semaines, corriger/mettre à jour les postes concernés.
- Étape 2 : activer le paramètre de rejet (GPO/registre selon vos standards), vérifier l’absence de 5841 (clients refusés) en production.
Playbook de diagnostic : valider que NTLM fonctionne encore
Une fois les patchs et les GPO déployés, validez que les canaux sécurisés sont bien scellés et que NTLM reste utilisable pour les scénarios légitimes.
Commandes côté client
# Vérifie le canal sécurisé de la machine
Test-ComputerSecureChannel -Verbose
# Vérifie la relation de confiance avec le domaine
nltest /sc\_verify:\
# Forcer un reset du mot de passe machine si nécessaire
Reset-ComputerMachinePassword -Server \ -Credential (Get-Credential) Commandes côté DC
# Filtrage des événements Netlogon les plus utiles
wevtutil qe System /q:"*[System[Provider[@Name='NETLOGON'] and (EventID=5838 or EventID=5839 or EventID=5840 or EventID=5841)]]" /f:text /c:1000
# Vérifier l'état effectif des paramètres Netlogon
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
# Liste synthétique des DC et OS pour repérer les versions legacy
Get-ADDomainController -Filter \* | Select-Object HostName,OperatingSystem,Site,IPv4Address Script d’inventaire Netlogon prêt à l’emploi
Le script ci‑dessous interroge tous les DC du domaine, collecte les événements 5838/5839/5840/5841 sur une période donnée et génère un CSV permettant de prioriser les corrections.
$days = 21
$outCsv = "C:\Temp\Netlogon-Audit.csv"
$eventIds = 5838,5839,5840,5841
\$controllers = (Get-ADDomainController -Filter \*).HostName
\$results = foreach (\$dc in \$controllers) {
try {
Get-WinEvent -ComputerName \$dc -FilterHashtable @{
LogName='System'; ProviderName='NETLOGON'; Id=\$eventIds; StartTime=(Get-Date).AddDays(-\$days)
} -ErrorAction Stop | ForEach-Object {
\[PSCustomObject]@{
DomainController = \$dc
TimeCreated = \$*.TimeCreated
EventId = \$*.Id
ClientOrTrust = ($\_ | Select-Object -ExpandProperty Message) -replace '\r?\n',' ' # compact
RawMessage = \$*.Message
}
}
} catch {
Write-Warning "Impossible d'interroger \$dc : \$(\$*.Exception.Message)"
}
}
\$results | Sort-Object TimeCreated | Export-Csv -NoTypeInformation -Path \$outCsv
Write-Host "Inventaire exporté vers \$outCsv" Cas particuliers et bonnes pratiques terrain
Appareils tiers (NAS, imprimantes, sauvegarde, VDI, OT)
- Vérifiez la prise en charge explicite de Netlogon RPC sealing dans les notes de version. Sans cela, l’équipement pourra toujours parler SMB/LDAP, mais les opérations dépendant du canal sécurisé échoueront (changement de mot de passe machine, validation de session NTLM par le DC, etc.).
- Planifiez des fenêtres de mise à niveau par lot par site pour limiter l’impact en cas de régression.
- Si le fournisseur n’a pas de mise à jour, isolez l’actif : comptes locaux, proxy d’authentification applicatif, ou remplacement planifié.
Samba et environnements Unix/Linux
- Mettez à niveau Samba vers une version prise en charge par votre distribution et par votre fournisseur.
- Activez les paramètres qui imposent un schannel chiffré pour le rôle concerné (client membre de domaine ou serveur DC/AD‑compatible).
- Vérifiez l’horloge (NTP) et les canaux RPC dynamiques (ports éphémères) côté pare‑feu.
Relations d’approbation (trusts)
- Patch bilateral : les deux côtés du trust doivent être à jour pour négocier RPC sealing.
- Validez avec
nltest /domain_trustset des tests d’ouverture de session inter‑forêts. - Ré‑établissez la clé secrète du trust si nécessaire (
netdom trust).
RODC (Read‑Only Domain Controllers)
- Mêmes exigences de RPC sealing que pour les DC en lecture/écriture.
- Surveillez les sites distants à faible connectivité (latence/MTU) car le chiffrement peut révéler des MTU mal ajustées.
Matrix de compatibilité : ce que le DC autorise
| État DC | Client Netlogon “signé seulement” | Client Netlogon “scellé (chiffré)” | Client RC4/MD5 |
|---|---|---|---|
| Avant durcissement (legacy) | Autorisé (non recommandé) | Autorisé | Autorisé |
| Phase de compatibilité (historique) | Autorisé + journalisé | Autorisé | Autorisé (év. 5840) |
| Application finale (état actuel) | Refusé (év. 5838/5839) | Autorisé | Autorisé par défaut, mais bloquable via RejectMd5Clients |
Erreurs fréquentes et parades
- “On vient d’installer les CUs sur les DC et des postes ne se connectent plus” : vous avez révélé des clients en RPC signing only. Appliquez la GPO “Digitally encrypt or sign… (always)” et mettez à jour/replacez les stacks obsolètes.
- “Un trust inter‑forêts tombe aléatoirement” : patch bilateral et validation du schannel. Vérifiez aussi l’ordre des contrôleurs préférés pour ce trust (sites/site‑link).
- “Des 5840 apparaissent en masse” : RC4 usage. Inventoriez, corrigez, puis activez RejectMd5Clients par lot.
- “Peut‑on revenir en arrière le temps d’un projet ?” : non, le mode compatibilité n’est plus disponible sur les builds récents. La seule stratégie sans dégrader la sécurité est de corriger les clients.
Check‑list opérationnelle
- ✅ Scripts d’audit 5838/5839/5840/5841 prêts et automatisés (tâche planifiée/SIEM).
- ✅ GPO “Digitally encrypt or sign secure channel data (always)” déployée sur les OU concernées.
- ✅ Parc Windows/firmwares à jour, exceptions identifiées et sponsorisées.
- ✅ Trusts patchés et vérifiés des deux côtés.
- ✅ Pilote validé (site, BU ou lot représentatif).
- ✅ Vagues de patch DC orchestrées avec plan de retour arrière procédural (non technique sur RequireSeal).
- ✅ (Optionnel) Stratégie d’élimination RC4/MD5 prête (métriques 5840 → 5841 = 0).
Modèle de communication interne (exemple)
Objet : Durcissement Netlogon (CVE‑2022‑38023) – Préservation de NTLM
Contexte :
Microsoft impose le chiffrement RPC ("RPC sealing") sur le canal sécurisé Netlogon.
Les DC refuseront toute connexion Netlogon signée uniquement.
Ce qui change :
* NTLM continue de fonctionner dès lors que le canal Netlogon est chiffré.
* Les clients/équipements non conformes seront refusés (événements 5838/5839).
Ce que nous allons faire :
1. Audit et correction des clients identifiés (GPO + mises à jour).
2. Patch par vagues des DC.
3. Surveillances rapprochées et remédiations.
Action demandée :
* Tenants applicatifs : recenser équipements AD/NTLM (NAS, agents, imprimantes, proxys).
* Equipes build : intégrer la GPO "Digitally encrypt or sign… (always)" au baseline.
* Fournir un contact run pour les fenêtres de mise à jour firmware.
Calendrier :
* Audit : Semaine S.
* Pilote : S+1.
* Vague 1 : S+2/S+3.
* Vague 2 : S+4/S+5. FAQ
Ces correctifs désactivent‑ils NTLM ?
Non. Ils imposent que le canal Netlogon soit chiffré (RPC sealing). Si vos clients sont correctement configurés/à jour, NTLM reste fonctionnel.
Comment savoir quels clients poseront problème ?
Collectez les événements 5838/5839 (signing only) et 5840/5841 (RC4). Ils vous donnent la liste précise des actifs à corriger.
Puis‑je forcer côté clients sans attendre les patchs DC ?
Oui : déployez la GPO “Digitally encrypt or sign secure channel data (always)” sur vos membres de domaine. Cette configuration pousse les clients à négocier un canal Netlogon chiffré.
Et si un équipement critique ne supporte pas le RPC sealing ?
Deux options : 1) obtenir un firmware pris en charge, 2) isoler/remplacer l’équipement. Revenir à un mode de compatibilité côté DC n’est pas possible sur les versions récentes.
Quid du chiffrement RC4/MD5 ?
RC4 peut persister dans certains environnements. Utilisez l’audit 5840 pour préparer l’activation de RejectMd5Clients quand plus aucun client n’en dépend.
Conclusion
Le durcissement Netlogon lié à CVE‑2022‑38023 ne condamne pas NTLM : il élève le niveau de sécurité en imposant le RPC sealing. En procédant dans le bon ordre — audit, mise à jour des clients, GPO d’encryption du canal sécurisé, patch par vagues des DC, puis surveillance — vous appliquez les mises à jour Microsoft récentes sans interrompre les authentifications NTLM légitimes, tout en réduisant durablement la surface d’attaque.
Annexe : le mémo technique en une page
- Objectif : respecter l’application finale du RPC sealing Netlogon.
- Impacts : échecs d’authentification NTLM/operations machine si canal non chiffré.
- Détection : événements 5838/5839/5840/5841 (source NETLOGON).
- Remédiation : GPO “Digitally encrypt or sign… (always)” + mises à jour OS/firmware + trusts patchés.
- État DC : Application par défaut (RequireSeal=2) sur builds actuels.
- Durcissement complémentaire : planifier RejectMd5Clients une fois RC4 éradiqué.
Résumé actionnable
- Avant de patcher les DC, inventorie et corrige : collecte 5838/5839/5840/5841, GPO “Digitally encrypt or sign… (always)”, mises à jour OS/firmware, trusts bilatéraux à jour.
- Pendant le patch DC, surveille : nouveaux 5838/5839, pics d’échecs NTLM, latence RPC.
- Après le patch, finalise : traiter les derniers cas, planifier RejectMd5Clients pour éliminer RC4, pérenniser la collecte dans le SIEM.
Avec cette méthode, vous déployez les mises à jour Microsoft les plus récentes sans interrompre NTLM, tout en neutralisant les faiblesses ciblées par CVE‑2022‑38023.