Après la mise à jour de postes Windows 11 vers 24H2, le tableau de bord Windows Server 2016 Essentials peut afficher tous les clients « Hors connexion ». Voici une méthode éprouvée et pérenne pour diagnostiquer et corriger le problème (Kerberos/GPO), sans rester bloqué en 23H2.
Symptômes observés après migration vers 24H2
- Dans Devices du tableau de bord Windows Server 2016 Essentials (ou Standard avec l’expérience Essentials), tous les PC sont marqués Offline.
- Dans l’explorateur Windows, l’onglet Réseau ne liste plus (ou presque plus) les autres ordinateurs, alors que les partages SMB restent accessibles par nom ou adresse IP.
- Un retour à Windows 11 23H2 restaure l’affichage « Online » dans le tableau de bord, mais les clients affichent alors « Mises à jour nécessaires », sans mise à jour disponible.
Analyse : pourquoi l’état « Hors connexion » apparaît
Windows 11 24H2 renforce plusieurs contrôles de sécurité. Si la stratégie Kerberos côté clients n’est pas alignée (en particulier les types de chiffrement autorisés), l’authentification Kerberos entre le poste et les composants Essentials ne se négocie pas correctement. Résultat : le connecteur Essentials ne parvient pas à prouver l’identité de la machine et le tableau de bord classe le poste en « Offline ». Le partage de fichiers reste néanmoins accessible, car SMB peut tomber sur NTLM ou exploiter des tickets déjà valides, d’où l’apparente contradiction.
Cause identifiée dans ce cas : un paramétrage Kerberos (types de chiffrement autorisés) n’était pas correctement appliqué par GPO sur les clients. Avec 24H2, ce décalage empêche la négociation Kerberos attendue par le connecteur Essentials, d’où l’état « Offline ».
Chemin rapide de résolution
- Corriger la GPO pour autoriser explicitement les types de chiffrement Kerberos requis (RC4, AES128, AES256, futurs types).
- Vérifier/corriger la clé Registre locale si elle force des valeurs plus restrictives que la GPO.
- Réinitialiser l’inscription du client Essentials (désinstallation du connecteur, sortie du domaine, mise à niveau 24H2 si besoin, réinstallation, réintégration au domaine).
- Valider avec
gpresult,klist, Observateur d’événements, et le retour « Online » dans le tableau de bord.
Mettre à jour la stratégie Kerberos par GPO
Où trouver le paramètre
Dans la console de gestion des stratégies de groupe :
- Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Options de sécurité.
- Stratégie : Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos.
Valeurs à activer
- RC4_HMAC_MD5
- AES128_HMAC_SHA1
- AES256_HMAC_SHA1
- Types de chiffrement futurs
Déployez d’abord la GPO vers une OU pilote, forcez la mise à jour (gpupdate /force), puis généralisez.
| Élément | Recommandation | Objectif |
|---|---|---|
| RC4_HMAC_MD5 | Cocher | Assurer la compatibilité avec le connecteur/serveur Essentials |
| AES128_HMAC_SHA1 | Cocher | Négociation sécurisée par défaut avec 24H2 |
| AES256_HMAC_SHA1 | Cocher | Renforcer la confidentialité des tickets |
| Types de chiffrement futurs | Cocher | Préparer l’environnement aux évolutions |
Bon à savoir : si une GPO à un niveau supérieur (domaine/racine) définit déjà ce paramètre, assurez-vous que votre GPO d’ajustement ait une priorité supérieure sur l’OU des postes concernés (LSDOU). Évitez de dupliquer des paramètres contradictoires.
Vérifier et corriger la clé Registre côté client
Si un poste possède une valeur locale SupportedEncryptionTypes trop restrictive, elle peut « écraser » la GPO. Vérifiez et corrigez si nécessaire.
Chemin et valeur
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
Valeur : SupportedEncryptionTypes (REG_DWORD)
Remédiation : si la valeur est 1, 2 ou 3 (trop restrictive), remplacez-la par 0x7FFFFFFC (décimal 2147483644) afin d’autoriser les types requis.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters ^
/v SupportedEncryptionTypes /t REG_DWORD /d 2147483644 /f
Puis redémarrez le poste et exécutez gpupdate /force.
| Valeur | Interprétation | Impact 24H2/Essentials |
|---|---|---|
| 1, 2, 3 | Jeu de chiffres très restreint (exclut AES/RC4 selon le cas) | Risque d’échec Kerberos → clients « Offline » |
| 2147483644 (0x7FFFFFFC) | Autorise RC4, AES128, AES256 et futurs types (sans DES) | Recommandé pour rétablir la négociation Kerberos |
Astuce : si la stratégie de domaine définit déjà SupportedEncryptionTypes, préférez la GPO et supprimez la valeur locale conflictuelle. L’objectif est de centraliser la configuration.
Réinscrire correctement le connecteur Essentials
Une fois la GPO corrigée et appliquée, réalisez l’opération suivante sur chaque poste afin de repartir sur une inscription propre.
- Désinstaller le connecteur Windows Server Essentials.
- Sortir du domaine (revenir temporairement en groupe de travail), puis redémarrer.
- Mettre à niveau vers Windows 11 24H2 (si ce n’est pas déjà fait), puis redémarrer.
- Réinstaller le connecteur et rejoindre de nouveau le domaine.
Retour terrain : après cette séquence — et avec la GPO en place — les postes repassent « Online » dans le tableau de bord. Dans l’incident à l’origine de cet article, un seul PC conservait une mauvaise valeur de Registre ; la corriger a suffi.
Contrôles et validations
gpresult /h C:\Temp\gp.html: vérifier l’application de la stratégie Kerberos et l’ordre de priorité des GPO.- Observateur d’événements → Journaux Windows → Sécurité / Système : recherchez les erreurs Kerberos (par ex. échec de négociation, etype not supported).
klist: inspecter les tickets (TGT/TGS) et les etypes réellement utilisés.nltest /sc_verify:MONDOMAINE: valider la relation d’approbation et la communication sécurisée avec le contrôleur de domaine.
| Outil | Commande | Ce que vous devez voir |
|---|---|---|
| GPResult | gpresult /h C:\Temp\gp.html | La GPO « types de chiffrement Kerberos » appliquée à l’ordinateur |
| Klist | klist tickets | Des tickets valides avec etype : AES128/AES256/RC4 (selon négociation) |
| NLTest | nltest /sc_verify:MONDOMAINE | « Trusted DC connection status Status = 0x0 NERR_Success » |
Script d’audit et de remédiation (PowerShell)
Le script ci-dessous vérifie la clé Registre, corrige la valeur si nécessaire, force une mise à jour de stratégie, puis journalise le résultat.
# Exécuter en tant qu'administrateur
$log = "C:\Temp\Kerberos-Fix-$(Get-Date -Format yyyyMMdd-HHmmss).log"
$path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
$name = "SupportedEncryptionTypes"
$target = 2147483644 # 0x7FFFFFFC
New-Item -Path \$path -Force | Out-Null
\$current = (Get-ItemProperty -Path \$path -Name \$name -ErrorAction SilentlyContinue).\$name
"\[\$(Get-Date)] Valeur actuelle : \$current" | Out-File \$log -Encoding utf8
if (\$null -eq \$current -or \$current -lt 4) {
Set-ItemProperty -Path \$path -Name \$name -Value \$target -Type DWord
"\[\$(Get-Date)] Valeur corrigée en \$target" | Out-File \$log -Append -Encoding utf8
} else {
"\[\$(Get-Date)] Aucune correction nécessaire" | Out-File \$log -Append -Encoding utf8
}
gpupdate /force | Out-File \$log -Append -Encoding utf8
klist purge -li 0x3e7 | Out-File \$log -Append -Encoding utf8 # purge tickets LSA (SYSTEM)
"\[\$(Get-Date)] Terminé" | Out-File \$log -Append -Encoding utf8
Write-Host "Journal : \$log" Option : si vous préférez supprimer la valeur locale et laisser la GPO s’exprimer :
Remove-ItemProperty -Path $path -Name $name -ErrorAction SilentlyContinue
gpupdate /force
Pourquoi le retour en 23H2 affiche « Mises à jour nécessaires »
Du point de vue du connecteur Essentials, un poste redescendu en 23H2 mais inscrit sous 24H2 (ou inversement) peut apparaître non conforme et réclamer des « mises à jour » qui ne sont pas réellement proposées. C’est un symptôme d’incohérence entre l’état du client et les attendus de la console, et non un problème de catalogue Windows Update. Une réinscription propre après correction Kerberos supprime ces faux positifs.
Contournements fréquents (non pérennes)
- Fixer des IP statiques, forcer la découverte réseau, mettre à jour les pilotes NIC : utile pour la couche réseau, mais n’adresse pas l’échec Kerberos.
- Autoriser les insecure guest logons : à éviter en production, impacte la posture de sécurité.
- Réinitialisation réseau de Windows : peut lever des blocages locaux mais ne résout pas la cause.
- Accès direct par
\\NomPCou\\IP: bon en dépannage uniquement.
Bonnes pratiques de déploiement
- Utiliser une OU pilote avec un échantillon représentatif de postes (modèles, drivers, usage).
- Documenter les dépendances Kerberos (temps/NTP, DNS, SPN, pare-feu) ; corriger d’éventuels décalages d’horloge.
- Préférer la GPO au Registre local ; minimiser les paramètres locaux persistants.
- Redémarrer après modification Kerberos et attendre la réplication GPO avant de conclure.
- Conserver un journal (
gpresult, exports d’événements) par vague de déploiement.
FAQ express
Faut-il absolument activer RC4 ?
Dans certains environnements historiques (comme Essentials), l’activation de RC4 garantit la compatibilité du connecteur et évite des négociations bloquées. Vous pouvez progressivement auditer et réduire l’usage de RC4 si l’ensemble des composants supporte pleinement AES.
Pourquoi les partages sont accessibles alors que le PC est « Offline » ?
Car l’état « Online/Offline » du tableau de bord repose sur l’inscription du client, qui s’appuie sur Kerberos. L’accès SMB peut suivre un autre chemin (tickets existants, mécanismes de repli), d’où la divergence.
Dois-je toucher aux contrôleurs de domaine ?
Non, dans la plupart des cas la correction côté clients (GPO + Registre) suffit. Assurez-vous toutefois que les DC sont en bonne santé (DNS, temps, réplication).
Annexes : repères sur les types de chiffrement Kerberos
| Nom | Libellé GPO courant | Bit/masque (indicatif) | Conseil |
|---|---|---|---|
| RC4_HMAC_MD5 | RC4_HMAC_MD5 | 0x00000004 | Activer pour compatibilité Essentials |
| AES128_HMAC_SHA1 | AES128_HMAC_SHA1 | 0x00000008 | Activer |
| AES256_HMAC_SHA1 | AES256_HMAC_SHA1 | 0x00000010 | Activer |
| Types futurs | Future encryption types | Réservé | Activer |
| 0x7FFFFFFC | — | Masque global recommandé | Autorise RC4/AES et exclut DES |
Checklist avant de réinscrire un poste
- La GPO Kerberos est active et prioritaire sur l’OU du poste.
- La valeur Registre SupportedEncryptionTypes est absente ou à 2147483644.
- Le poste a été redémarré et
gpupdate /forceexécuté. klistaffiche des tickets utilisant AES ou RC4.- Pas d’erreur Kerberos bloquante dans l’Observateur d’événements.
Plan de déploiement recommandé
- Créer/ajuster la GPO Kerberos et cibler une OU pilote (5–10 % du parc).
- Attendre la réplication, redémarrer les postes pilotes, vérifier gpresult et journaliser.
- Réinscrire 1–2 postes pilotes ; confirmer l’état Online dans le tableau de bord.
- Étendre par vagues (par site ou par département), avec point d’arrêt si anomalie.
- Nettoyer les paramètres locaux résiduels (scripts de remédiation), puis basculer en maintenance courante.
Points de vigilance
- Temps/DNS : une dérive d’horloge (>5 min) ou un DNS mal résolu suffit à briser Kerberos.
- Pare-feu : vérifier les flux Kerberos (TCP/UDP 88), RPC/SMB et les ports Essentials.
- SPN en doublon : rares mais possibles ; surveiller les erreurs d’authentification inhabituelles.
Résumé opérationnel
Le passage à Windows 11 24H2 peut révéler une configuration Kerberos incomplète ou trop restrictive côté clients, ce qui empêche le connecteur Essentials d’authentifier correctement les machines. En autorisant RC4, AES128, AES256 et types futurs via GPO, en corrigeant la clé Registre si nécessaire (SupportedEncryptionTypes = 2147483644), puis en réinscrivant proprement le poste au domaine/au connecteur, les PC repassent « Online » dans le tableau de bord Windows Server 2016 Essentials, sans rester bloqués sur 23H2.
Contrôles utiles — mémo commandes
gpresult /h C:\Temp\gp.html
eventvwr.msc # examiner Sécurité/Kerberos et Système
klist tickets
nltest /sc_verify:MONDOMAINE
Commande Registre — correction rapide
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters ^
/v SupportedEncryptionTypes /t REG_DWORD /d 2147483644 /f
Après correction : redémarrez, forcez les GPO, réinstallez le connecteur si nécessaire, puis vérifiez le retour « Online » dans Devices.