Windows senza NTLM:
IAKerb, LocalKDC e cosa fare ora

In breve: Microsoft ha annunciato che disabiliterà NTLM — il vecchio protocollo di autenticazione di Windows — per impostazione predefinita nelle future versioni del sistema. Due novità, IAKerb e LocalKDC, portano Kerberos negli scenari dove prima si ricadeva su NTLM. Non è un cambio da rimandare: oggi conviene scoprire dove la tua azienda usa ancora NTLM e mettere in ordine le basi (DNS, SPN, orologi).

Come funziona NTLM, spiegato semplice

NTLM serve a dimostrare che conosci la tua password senza mai inviarla. Funziona come un test a sorpresa, con tre attori: il tuo PC (client), il server che vuoi raggiungere e il domain controller (DC), che custodisce le password in Active Directory.

• 1Il client bussa al server: «sono Mario, fammi entrare».
• 2Il server lancia una sfida: un numero casuale, diverso ogni volta.
• 3Il client mescola quel numero con l’impronta della password (l’hash) e rimanda il risultato. La password non parte mai: resta sul client.
• 4Il server non può verificare da solo (non ha l’hash): gira la richiesta al DC, che in AD custodisce l’impronta. Il DC rifà il calcolo e, se combacia, conferma. Per un account locale, invece, è la macchina stessa a verificare nel proprio database (SAM), senza alcun DC.

In sintesi: il client parla solo con il server, ed è il server a parlare con il DC. NTLM esiste in due versioni: oggi si usa NTLMv2 (NTLMv1 va disattivato perché molto più debole), ma il meccanismo a tre attori — e i problemi che vedremo — vale per entrambe.

Perché NTLM è un problema

Sembra solido — la password non viaggia mai in chiaro — ma ha due crepe che oggi pesano:

• Nessuno verifica il server. Tu dimostri chi sei, ma il server non deve dimostrare niente a te. Se qualcuno si infila fingendosi il server, il gioco salta. È l’opposto della logica zero trust.
• Basta l’impronta, non serve la password vera. L’hash resta nella memoria dei PC e dei server dove l’utente si collega, e — per tutti gli utenti — sul domain controller. Chi compromette una macchina con privilegi elevati può rubare l’hash e riusarlo per autenticarsi come la vittima (pass-the-hash), senza conoscere la password. In una variante diversa l’attaccante non ruba nulla: intercetta e inoltra l’autenticazione di una vittima verso un terzo server (NTLM relay). In entrambi i casi un singolo PC compromesso diventa l’ingresso per l’intera rete: la dinamica tipica degli attacchi ransomware.

Kerberos: il modello a biglietti

Kerberos cambia approccio. Invece di rifare il test a ogni porta, vai una volta sola a uno «sportello fiducia» (il KDC, sul domain controller), dimostri chi sei e ricevi un biglietto firmato e a scadenza. A ogni servizio mostri il biglietto — come un braccialetto rilasciato a un banco centrale, invece di esibire i documenti a ogni cancello. I vantaggi:

• Autenticazione reciproca — non solo tu dimostri chi sei: anche il server prova a te di essere autentico. La porta mostra un sigillo che solo il locale vero può produrre.
• Single sign-on ed efficienza — ti autentichi una volta e riusi i biglietti; i servizi li verificano da soli, senza telefonare al DC a ogni accesso come fa NTLM.

Lo stesso principio «verifica, non fidarti» è alla base anche di altre evoluzioni recenti dell’autenticazione Windows, come l’ addio alla cifratura RC4 in Kerberos.

Perché NTLM sopravvive ancora

Se Kerberos è migliore, perché NTLM è ancora ovunque? Perché in alcuni scenari Kerberos, per come è concepito, non riesce a lavorare e Windows ripiega automaticamente su NTLM:

• Account locali e macchine non in dominio — senza un dominio non c’è un KDC che emetta i biglietti.
• Nessuna linea di vista al domain controller — se il client non raggiunge un KDC, Kerberos non riesce a emettere il ticket.
• Accesso per indirizzo IP — Kerberos ragiona per nome (l’SPN, es. cifs/server.azienda.local). Chi accede per IP non ha un SPN corrispondente e ricade su NTLM.
• Ambienti eterogenei — PC di un dominio che accedono a risorse di un altro dominio, NAS non aggregati ad Active Directory, postazioni macOS fuori dominio. È il mondo reale di moltissime PMI, ed è proprio lì che NTLM resiste.

Cosa cambia: IAKerb e LocalKDC

Le due novità Microsoft (in anteprima su Windows 11 e Windows Server 2025) attaccano proprio i buchi dove prima serviva NTLM:

• 1IAKerb — quando il client non raggiunge il KDC, il server fa da fattorino: inoltra lui i messaggi Kerberos al domain controller e riporta il biglietto. Non vede mai password o hash, passa solo i messaggi. Risultato: niente più ripiego su NTLM «perché non vedo il DC».
• 2LocalKDC — uno «sportello fiducia» in miniatura installato sulla macchina stessa, che emette biglietti Kerberos per gli account locali. Così i sistemi non in dominio possono usare Kerberos al posto di NTLM.

Applicate ai casi reali, però, vanno lette con onestà:

• PC di dominio che non vede il DC (rete segmentata o sede remota): IAKerb risolve, il server inoltra al KDC.
• Accesso a una risorsa di un altro dominio con le credenziali di quel dominio: se il KDC remoto è raggiungibile e risolvibile, Kerberos funziona già oggi senza trust; se non lo è, oggi è NTLM e domani potrà esserlo via IAKerb (il server fa da proxy).
• NAS non Windows e postazioni macOS: LocalKDC è una funzione Windows e IAKerb è lato Windows — il supporto dei client e dispositivi di terze parti non è garantito e va verificato col fornitore. Spesso questi restano l’ultimo bastione di NTLM.

Cosa fare oggi: audit, igiene e mitigazioni

1. Scopri dove usi ancora NTLM. Prima di toccare qualsiasi cosa, fai un audit: attiva il log operativo NTLM e analizza gli eventi di sicurezza — in particolare il 4624 con pacchetto di autenticazione NTLM e il 4776 sui domain controller — per capire quali applicazioni, server e dispositivi dipendono ancora da NTLM. Non si disattiva alla cieca.

2. Sistema le fondamenta di Kerberos. In molti casi il problema non è «manca una funzione di Microsoft», ma igiene di base: nomi DNS risolvibili (anche verso domini diversi, con i conditional forwarder), SPN registrati correttamente, accesso alle risorse per nome e non per IP, e orologi sincronizzati entro pochi minuti. Sistemate queste basi, molti accessi che oggi cadono su NTLM tornano a Kerberos da soli.

3. Riduci il rischio finché NTLM c’è ancora. Non puoi spegnerlo da un giorno all’altro, ma puoi mitigarlo: attiva l’SMB signing e il signing con channel binding (EPA, Extended Protection for Authentication) su LDAP e servizi web per neutralizzare gran parte degli attacchi NTLM relay; usa le policy di restrizione NTLM (prima in audit, poi in blocco selettivo) per stringere progressivamente; e fai invocare alle applicazioni il pacchetto Negotiate invece di NTLM diretto, così Kerberos viene scelto quando possibile.

NTLM, segmentazione e zero trust

La fine di NTLM non è solo «patch management»: è un tassello dello zero trust, il modello «non fidarti, verifica sempre». Qui IAKerb mostra il suo lato migliore: invece di appiattire due ambienti (aprendo DNS e porte verso i domain controller di un’altra rete), il server fa da proxy e non esponi il cuore identità ai client esterni. Meno connettività implicita, e — passando da NTLM a Kerberos — la verifica reciproca al posto della fiducia cieca.

Attenzione a non confondere i piani: IAKerb e LocalKDC sono meccanismi on-premise e non c’entrano con Microsoft Entra ID, che è l’identità cloud (esiste un «Entra Kerberos», ma serve a casi specifici come Azure Files, non a una share on-premise o a un NAS). Per gli ambienti davvero eterogenei la risposta non è una singola funzione, ma una scelta architetturale: trust mirati, segmentazione e, dove serve, un accesso Zero Trust Network Access (ZTNA) che governa l’accesso per identità e dispositivo, anche per i client non Windows.

Come AtWorkStudio aiuta

Accompagniamo le aziende nel percorso verso un’autenticazione moderna: audit delle dipendenze NTLM, bonifica di DNS, SPN e sincronizzazione, riduzione degli account locali, gestione dell’identità digitale e segmentazione della rete. Per gli ambienti eterogenei progettiamo l’accesso in ottica zero trust, coerente con i requisiti di NIS2 e con le best practice ISO/IEC 27001.

Operiamo da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, qualificati ACN per servizi cloud, membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.