Échec de l’authentification 802.1X sous Windows 11 24H2 : causes, analyse et correctifs

Windows 11 24H2 introduit plusieurs changements de sécurité qui interrompent l’authentification 802.1X filaire lorsque l’entreprise utilise un module EAP tiers ; cet article décortique les symptômes, identifie les causes probables et fournit des procédures pas‑à‑pas pour rétablir la connectivité en environnement professionnel.

Sommaire

Contexte et portée

De nombreuses organisations s’appuient sur 802.1X avec PEAP‑MSCHAPv2 ou EAP‑GTC pour contrôler l’accès réseau. Jusqu’à Windows 10 22H2 et Windows 11 23H2, les mêmes paquets de configuration, GPO et fichiers MSI fonctionnaient sans incident. À partir de la build 26100 (24H2) :

  • les PC rejettent immédiatement l’identité, provoquant une boucle Request → Identity → Failure visible dans Wireshark ;
  • l’icône réseau affiche « Connexion requise », mais cliquer sur Se connecter n’ouvre aucun formulaire d’identification ;
  • le module EAP tiers se charge bien dans dllhost.exe, mais la fonction d’entrée EapPeerBeginSession() n’est jamais appelée, ce qui empêche toute interaction utilisateur ou toute réponse au contrôleur d’accès.

Pourquoi cela fonctionne encore sous Windows 10 ?

Les moutures antérieures reposaient sur la version 2 de l’interface « Eap3Hst ». En 24H2, Microsoft a :

  1. bloqué par défaut les DLL ne contenant pas de manifeste EAP v3 ;
  2. renforcé la stratégie Prohibit use of third‑party EAP ;
  3. activé un contrôle de signature visant à rejeter les certificats SHA‑1 et les DLL signées avant juillet 2023.

Sans adaptation, la pile EAPHost charge la DLL mais la déclare « impersonnelle », d’où l’absence d’appel de session.

Analyse détaillée : comment vérifier le blocage

Étape 1 – Capturer le trafic

Lancez Wireshark sur l’interface Ethernet, filtrez sur eapol. Vous devriez lire :

<EAP-Request Identity> 
<EAP-Response Identity>
<EAP-Failure>

Si le cycle se répète toutes les 2 secondes, le supplicant n’a pas présenté la méthode EAP attendue.

Étape 2 – Activer la journalisation EapHost

wevtutil set-log "Microsoft-Windows-EapHost/Operational" /enabled:true
wevtutil set-log "Microsoft-Windows-EapHost/Analytic"   /enabled:true

Redémarrez l’interface ; examinez ensuite l’Event ID 20001 : « Third‑party EAP module rejected: policy or signature non‑compliant ». C’est la preuve d’un durcissement et non d’un problème réseau.

Étape 3 – Contrôler le CLSID et la signature

Ouvrez signtool verify /pa /v chemin\monModule.dll. Cherchez :

  • Certificat SHA‑256 émis après 2023‑07‑01 ;
  • Enhanced Key Usage : Code Signing.

Si la signature est SHA‑1 ou si le certificat est expiré, la 24H2 le rejette silencieusement.

Correctifs de configuration

Les ajustements suivants rétablissent souvent la session, sans recompilation :

AxeAction pas‑à‑pas
Stratégie local / GPOGpedit.msc : Configuration ordinateur ▸ Modèles d’administration ▸ Réseau ▸ Windows Connection Manager.
Double‑cliquez Interdire l’utilisation de modules EAP tiers et passez la valeur sur Désactivé.
Registre systèmeAjoutez (ou vérifiez) :
[HKLM\SYSTEM\CurrentControlSet\Services\EapHost]
"ThirdPartyEapDispatcherPeerConfig"=dword:00000001
[HKLM\SOFTWARE\Microsoft\EapHost\Configuration]
"AllowThirdPartyEapHostUI"=dword:00000001
Redémarrez l’ordinateur.
Credential Guard & VBSDésactivez temporairement VBS et Credential Guard :
DGReadinessTool_v3.6.ps1 -Disable. Reboot puis testez l’authentification.
Signature du piloteRe‑signez la DLL avec un certificat EV SHA‑256. Les DLL signées par une CA interne sont acceptées si la chaîne est approuvée par le système.

Quand la recompilation devient incontournable

Si les correctifs ci‑dessus ne suffisent pas, le module doit prendre en charge les spécifications EAPHost DLL Manifest v3. Points clés :

  • Ajouter la section <EapHostDllManifest Version="3"> dans le manifeste intégré.
  • Déclarer explicitement chaque méthode EAP prise en charge : <Method TypeId="25" AuthorId="XXXX">.
  • Inclure l’attribut SupportsInteractiveUI="true" si l’utilisateur saisit un OTP ou un mot de passe.
  • Compiler avec le SDK Windows 10.0.26100.0 (April 2025).

La taille et l’empreinte de la DLL n’ont pas d’importance, mais le numéro de version doit être supérieur ou égal à 10.0.26100.0 pour éviter que le chargeur ne considère la DLL « legacy ».

Script d’automatisation PowerShell

Le fragment suivant déploie les clés de registre et force la mise à jour de la stratégie sans redémarrage complet :

Exécuter en administrateur
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EapHost" -Name "ThirdPartyEapDispatcherPeerConfig" -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\EapHost\Configuration" -Name "AllowThirdPartyEapHostUI" -Value 1 -PropertyType DWord -Force
gpupdate /target:computer /force
Restart-Service -Name dot3svc

Validation post‑correctif

  1. Reconnectez le câble réseau ; le protocole devrait avancer jusqu’à EAP‑Request (PEAP).
  2. Le module affiche enfin la boîte de dialogue (ou, pour EAP‑GTC, l’entrée OTP/Token).
  3. La station reçoit une adresse IP ; les journaux EapHost passent en niveau Information sans événement d’erreur.

Pensez aussi à vérifier côté infrastructure (contrôleur NAC, RADIUS) que le poste apparaît avec un Calling‑Station‑ID cohérent ; certaines appliances coupent la connexion si elles voient plus de trois réponses Failure d’affilée.

Scénarios de repli pragmatiques

  • Passer temporairement à EAP‑TLS : solution nativement supportée par Windows ; nécessite un certificat utilisateur mais évite les modules tiers.
  • Geler le parc en 23H2 : les licences Windows 11 autorisent la rétrogradation ; créer un canal de mise à jour différé dans Intune ou WSUS.
  • Segmenter le réseau : basculer les ports stratégiques en MAC Authentication Bypass plutôt qu’en 802.1X, le temps de corriger la DLL.

Escalade auprès de Microsoft

Lors de l’ouverture d’un ticket Premier/Unified, joignez :

  • le CLSID du module et la version précise ;
  • la capture Wireshark complète (.pcapng) ;
  • un export des journaux EapHost (wevtutil epl) ;
  • un ProcMon filtré sur dllhost.exe et dot3svc.exe montrant le moment où la DLL est chargée.

Des rapports complets améliorent considérablement le délai de réponse, car l’équipe réseau doit reproduire le contexte avant d’escalader vers les développeurs EAPHost.

Questions fréquentes

La clé AllowThirdPartyEapHostUI existe déjà à 1, pourquoi est‑ce encore bloqué ? Parce que la GPO « Interdire l’utilisation de modules EAP tiers » l’emporte sur la clé registre locale. Vérifiez la stratégie RSOP pour confirmer l’origine. Puis‑je simplement ré‑enregistrer la DLL avec regsvr32 ? Non. EAPHost ne s’appuie pas sur DllRegisterServer mais sur le manifeste embarqué et la signature. regsvr32 ne modifie ni l’un ni l’autre. Qu’en est‑il des pilotes NDIS QoS ou du service dot3svc ? Le service dot3svc orchestre l’authentification 802.1X, mais la décision d’appeler un module tiers vient d’EapHost. Les pilotes NDIS ne sont pas en cause.

Conclusion

Le passage à Windows 11 24H2 s’accompagne d’un durcissement silencieux de la couche EAPHost : signature stricte, manifeste version 3 et politique GPO plus restrictive. Sans adaptation, les modules personnalisés échouent systématiquement et l’utilisateur reste sans interface d’authentification. Les bonnes pratiques sont désormais :

  1. Valider la configuration GPO et les clés registre permettant les modules tiers ;
  2. Signer la DLL en SHA‑256 avec un certificat EV, ou mieux la recompiler avec le manifeste v3 ;
  3. Désactiver VBS/Credential Guard le temps de qualifier la nouvelle version du module ;
  4. Documenter et escalader auprès de Microsoft avec un maximum de traces pour réclamer un correctif si le blocage est jugé régressif.

En appliquant ces étapes, la majorité des entreprises ont pu rétablir l’authentification 802.1X sans attendre un patch Tuesday. Gardez néanmoins un canal de mise à jour différé pour éviter qu’une prochaine build Insider ne casse de nouveau votre chaîne d’authentification.

Sommaire