IAKerb e LocalKDC su Windows: meno dipendenza da NTLM, più Kerberos

Perché NTLM è ancora vivo (e quanto è difficile eliminarlo)

In ambienti Active Directory, Kerberos è il protocollo di autenticazione preferito da Microsoft da oltre vent’anni. Eppure, NTLM continua a essere presente in quasi ogni infrastruttura Windows perché esistono tre scenari in cui Kerberos non funziona e il sistema ricade inevitabilmente su NTLM:

Il client non ha visibilità di rete diretta su un Domain Controller (DC)
L’autenticazione coinvolge un account locale invece di un account di dominio
L’ambiente è un workgroup o una macchina standalone, senza infrastruttura di dominio

Sono esattamente questi tre gap che Microsoft sta affrontando con IAKerb e LocalKDC, due funzionalità oggi in public preview su Windows Insider (Canary Channel) e previste in disponibilità generale su Windows 11 24H2 e Windows Server 2025 nella seconda metà del 2026.

IAKerb: Kerberos anche senza visibilità sul Domain Controller

IAKerb (Initial and Pass-Through Authentication using Kerberos) è un meccanismo definito nella bozza IETF draft-ietf-kitten-iakerb-03. Si implementa come sotto-meccanismo GSS-API, inserendosi nel protocollo SPNEGO che Windows già utilizza per la negoziazione dell’autenticazione.

Nel flusso Kerberos standard, il client deve contattare direttamente il KDC (Key Distribution Center, il servizio che gira su ogni DC) sulla porta TCP/UDP 88 per ottenere un ticket prima di potersi autenticare su un servizio. Se nessun DC è raggiungibile, Kerberos fallisce e Windows scade su NTLM.

IAKerb risolve questo problema rendendo il server di destinazione un proxy trasparente per i messaggi Kerberos. Il client tunnel i messaggi Kerberos all’interno della connessione esistente verso il server applicativo (ad esempio, sulla porta TCP 445 per SMB), e il server li inoltra al DC per conto del client. Il server non vede mai la password o l’hash: si limita a fare da relay ai messaggi di protocollo.

Il risultato pratico è che l’autenticazione rimane su percorso Kerberos anche quando:

Il client si trova in una subnet segmentata senza accesso diretto ai DC
L’accesso avviene via VPN o accesso remoto con routing limitato
L’architettura cloud restringe la connettività diretta ai controller di dominio

LocalKDC: Kerberos anche per gli account locali

LocalKDC affronta il secondo grande limite: gli account locali. Kerberos richiede un KDC per emettere i ticket, e gli account locali (quelli nel SAM della macchina) non hanno nessun KDC a cui rivolgersi. Di conseguenza, qualunque autenticazione remota che coinvolgesse un account locale era storicamente vincolata a NTLM.

LocalKDC è un KDC leggero integrato direttamente in Windows, che opera esclusivamente sugli account del SAM locale. Emette ticket Kerberos basati su AES per le identità locali, abilitando l’autenticazione Kerberos anche in ambienti workgroup, macchine standalone e qualsiasi scenario con credenziali locali.

Stato attuale e configurazione via registro

Le due funzionalità hanno default diversi nel preview corrente:

IAKerb: abilitato per default
LocalKDC: disabilitato per default

La configurazione avviene tramite valori di registro di tipo REG_DWORD:

DisableIAKerb: impostare a 0 per abilitare, 1 per disabilitare
DisableLocalKDC: impostare a 0 per abilitare, 1 per disabilitare

Group Policy e gestione tramite MDM (Intune incluso) saranno aggiunti quando le funzionalità usciranno dalla fase di preview.

Prima di testare: auditing NTLM

Prima di attivare IAKerb e LocalKDC in produzione, è fondamentale capire dove NTLM viene ancora usato nell’ambiente. Windows 11 24H2 e Windows Server 2025 includono log operativi NTLM migliorati, accessibili in Event Viewer sotto:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Gli Event ID rilevanti sono:

4020, 4021: eventi client (includono nome processo, IP di destinazione, codice motivo per cui Kerberos non è stato usato)
4022, 4023: eventi server (nome processo e IP client)
4030–4033: eventi sui domain controller (dettagli client e server)

I log client sono i più informativi perché riportano il motivo del fallback a NTLM, permettendo di identificare i workload che richiedono intervento prima di pensare a disabilitare NTLM.

L’abilitazione del logging si gestisce via Group Policy:

Per client e server: Administrative Templates > System > NTLM > NTLM Enhanced Logging
Per i domain controller: Administrative Templates > System > Netlogon > Log Enhanced Domain-wide NTLM Logs

Limiti attuali e roadmap Microsoft

IAKerb e LocalKDC non eliminano ogni dipendenza da NTLM. Rimangono scenari che continuano a richiedere NTLM:

Applicazioni con NTLM hardcoded nel codice
Infrastrutture che assumono NTLM come default nella loro logica di autenticazione
Alcune interazioni tra account di dominio e account locali sulla stessa macchina

La roadmap Microsoft per la disabilitazione di NTLM si articola in tre fasi:

Fase 1 (già in produzione): miglioramenti all’auditing NTLM
Fase 2 (H2 2026): disponibilità generale di IAKerb e LocalKDC
Fase 3 (~2027–2028): NTLM disabilitato per default nella prossima versione major di Windows Server

Cosa fare adesso

Per un amministratore di sistema che vuole prepararsi al cambiamento in anticipo, il percorso consigliato è: abilitare i log NTLM migliorati oggi (già disponibili su 24H2/Server 2025), analizzare gli event ID nei prossimi mesi per mappare i workload con dipendenza NTLM, e pianificare i test con IAKerb e LocalKDC su ambienti non produttivi non appena la disponibilità generale sarà confermata. Affrontare questa transizione gradualmente è molto più gestibile che trovarsi a fare remediation d’emergenza quando NTLM verrà disabilitato per default.

Fonte originale: Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops.com