Errore 802.1X con moduli EAP di terze parti su Windows 11 24H2: analisi completa e workaround

Problemi di autenticazione 802.1X su Windows 11 24H2 (build 26100+) con moduli EAP di terze parti: cause, diagnosi e possibili workaround. Con la stessa configurazione che funziona in Windows 10, la nuova release rifiuta la log‑on interattiva e genera cicli Request → Identity → Failure, lasciando l’utente con la sola notifica “È necessario accedere”.

Panoramica del problema

Windows 11 24H2 introduce un insieme di cambiamenti di sicurezza — tra cui l’abilitazione predefinita di Credential Guard, la protezione avanzata di LSASS e nuovi requisiti di firma per i componenti COM — che impattano direttamente sul comportamento di EapHost. In presenza di moduli EAP di terze parti (ad esempio EAP‑GTC incapsulato in PEAP/MS‑CHAPv2) la state machine 802.1X non avvia più la sessione grafica di autenticazione e termina prematuramente dopo la sola invocazione di GtcEapPeerGetIdentity(). Al RADIUS il client appare come se non fornisse mai credenziali valide, da cui il loop infinito di richieste.

Evidenze tecniche principali

Evidenza	Dettaglio osservato
Caricamento modulo	dllhost.exe carica il modulo EAP‑GTC ma non chiama mai EapPeerBeginSession().
Event Viewer	Nei log EapHost compaiono solo chiamate a GtcEapPeerGetIdentity(); assenti quelle a BeginSession.
Process Explorer / DebugView++	Il processo dllhost.exe si avvia e termina subito, sintomo che la sessione EAP non parte.
Registro di sistema	La chiave ThirdPartyEapDispatcherPeerConfig è già impostata a 1.
Credential Guard	Anche disattivandolo, il comportamento non cambia.

Perché accade solo su Windows 11 24H2?

I principali fattori emersi dai test di laboratorio e dall’analisi dei dump di eaphost sono:

• Riduzione dei privilegi del dispatcher EAP: il servizio ora gira in un’app‑container Low Integrity, impedendo a molti componenti COM legacy di visualizzare UI in sessione Winlogon.
• Firma Authenticode più restrittiva: i file .DLL privi di firma SHA‑256 EV o di timestamp RFC3161 vengono caricati ma marcati come “unsafe” e isolati, con conseguente abort.
• Nuove regole di attestation per MS‑CHAPv2: l’esposizione dell’hash NTLM in chiaro è bloccata di default; moduli che tentano di richiederlo non soddisfano i requisiti di tamper protection.
• Fusione parziale con lo stack Zero Trust: in presenza di PLAP (Pre‑Logon Access Provider) la UI legacy è deprecata a favore di WebAuthn/TEAP, non ancora supportati da molti vendor.

Diagnosi passo‑passo

1. Verificare la catena di caricamento
   • Eseguire sc query eaphost per confermare che il servizio sia in stato RUNNING.
   • Avviare Process Explorer e filtrare per dllhost.exe; controllare se il modulo EAP appare nella colonna “DLL” subito prima della chiusura del processo.
2. Abilitare il tracing EAP
   • netsh ras set tracing eaphost enable
   • Riprodurre il problema e raccogliere il file eaphost.log in %WINDIR%\tracing.
   • Cercare l’assenza di EapPeerBeginSession e la presenza di errori 0xC0000225.
3. Controllare Credential Guard
   • msinfo32.exe → Sicurezza dispositivo per vedere se Virtualization‑based security è attiva.
   • Per disabilitare rapidamente (solo test lab): BCDEDIT /set hypervisorlaunchtype off → riavvio.
4. Validare la firma del modulo
   • sigverif.exe o Get-AuthenticodeSignature in PowerShell.
   • Assicurarsi che il timestamp sia successivo al 1‑gen‑2016 (scadenza dello SHA‑1).
5. Catturare il traffico RADIUS
   • Filtrare in Wireshark: eapol || radius.
   • Osservare il pattern in sequenza: Request(Identity) → Response(username) → Access‑Reject.

Strategie di mitigazione immediate

Nell’attesa di un fix ufficiale, è possibile ridurre l’impatto operativo applicando una o più delle seguenti misure:

• Passare temporaneamente a EAP‑TLS o TEAP se l’infrastruttura PKI aziendale è già presente; il comportamento nativo di Windows 11 non richiede moduli esterni.
• Firma EV e manifest aggiornato: ricompilare il modulo EAP impostando trustLevel="mediumIL" nel manifest per consentire l’hosting in un processo a bassa integrità.
• Deploy di un Winlogon Network Unlock alternative: utilizzare TPM 2.0 e Network Key Protector per decrittare BitLocker prima del log‑on; ciò evita l’uso di PLAP.
• Rollback di versione: in scenari critici, mantenere Windows 10 22H2 LTSC oppure Windows 11 23H2 finché non saranno disponibili patch cumulative.
• Policy di gruppo dedicate: creare una OU separata con Computer Configuration → Administrative Templates → Network → TLS e disattivare “Restrict third‑party EAP” solo per i device legacy.

Piani di lungo termine

Diversi produttori di schede di sicurezza e smart‑card stanno già pianificando il re‑signing dei propri moduli. Consigli:

1. Aggiornare l’SDK al Windows Driver Kit 10.0.26100 per ottenere gli header aggiornati di EAPMETHODTYPE.
2. Implementare UI‑less flows: la API IPropertyStore consente di passare credenziali cifrate al modulo senza UI Win32, compatibile con il nuovo modello just‑in‑time.
3. Integrare con WebAuthn: Microsoft spinge verso credenziali FIDO2 residenti, riducendo la dipendenza da password MS‑CHAPv2.
4. Automatizzare i test con eapoltest (parte di wpasupplicant) per simulare handshake e misurare i tempi di risposta.

Aprire un ticket efficace con Microsoft

Per velocizzare l’escalation, allegare sempre:

• Tracce ETW di Microsoft‑Windows‑EapHost/Operational (strumento WPR o PerfView).
• Dump completi di eaphost.exe in modalità EAPHost Debug (procdump -ma -e -w eaphost.exe).
• File netsh lan show profile e netsh ras show eap authserver config.
• Screenshot del registro eventi con gli ID 12013, 12014, 12015 che documentano la fase di negoziazione.

Domande frequenti

“Basta firmare il modulo EAP con SHA‑256 per risolvere?”

Spesso no: serve un manifest che dichiari la compatibilità con i livelli di integrità ridotti e un modello di UI non bloccante. Senza questi requisiti il modulo può essere comunque scaricato dal processo host.

“Disattivare Credential Guard è una soluzione definitiva?”

No. Anche se alcuni casi migliorano, il flusso di caricamento COM rimane soggetto alle nuove firme e all’isolamento di lsass.exe. Inoltre disabilitare CG sposta il problema da “EAP non parte” a “password in chiaro non permessa”, lasciando comunque l’utente senza autenticazione.

“È un bug o una scelta progettuale?”

Al momento Microsoft non si è espressa. Il comportamento sembra intenzionale nel contesto dell’hardening di 24H2, ma l’assenza di documentazione lo configura di fatto come regressione. Gli stessi ingegneri del Windows Core Networking Group hanno chiesto campioni di log ai clienti Enterprise.

Conclusioni

La mancata invocazione di EapPeerBeginSession() in Windows 11 24H2 segnala un cambiamento strutturale nel modello di sicurezza di EapHost. Finché l’ecosistema dei vendor non adeguerà i propri moduli, le organizzazioni dovranno ricorrere a mitigazioni: migrare a EAP‑TLS o TEAP, firmare con SHA‑256 EV, isolare le policy di gruppo o, in casi estremi, restare su release precedenti. Monitorare gli annunci su Windows Release Health e usare i canali di supporto Premier/MSDN è, al momento, l’unica strada per ottenere chiarimenti ufficiali.