• Guide, Sicurezza, Sistemi Operativi
• 3 Giugno 2026

Negli ambienti Windows, l’autenticazione non è solo un dettaglio tecnico ma un meccanismo che definisce la fiducia nei servizi e nei dispositivi. Per decenni il protocollo NT LAN Manager (NTLM) ha rappresentato il “piano B”: una soluzione di ripiego quando il metodo consigliato, Kerberos, non era disponibile. Negli ultimi mesi Microsoft ha iniziato un percorso di modernizzazione che mira a ridurre, fino a eliminare, la dipendenza da NTLM introducendo due componenti chiave: IAKerb e Local KDC.

L’obiettivo di questo articolo è spiegare perché NTLM è stato così importante, cosa offre Kerberos in più e come le nuove funzionalità cambieranno la gestione dell’autenticazione. Per chi amministra infrastrutture Active Directory (AD), si tratta di un cambiamento radicale che va preparato oggi.

Perché NTLM è ancora qui

NTLM è nato come protocollo challenge/response per autenticare utenti e computer su reti Windows e per sistemi standalone. Ne abbiamo parlato tantissimo qui su ICTPower. La documentazione di Microsoft ricorda che NTLM fornisce autenticazione, integrità e confidenzialità alle applicazioni ed è usato per autenticare utenti e computer in domini Windows o su sistemi isolati. Le credenziali NTLM sono basate sulla combinazione di dominio, nome utente e un hash a senso unico della password. La procedura non invia la password in chiaro: il server sfida il client con un numero casuale, il client calcola una risposta con l’hash della password e il controller di dominio verifica che la risposta sia corretta.

NTLM è rimasto vitale perché risolve alcuni casi in cui Kerberos, per come è stato concepito, non è adatto:

• Account locali: le macchine non appartenenti a un dominio usano solo NTLM per l’autenticazione.
• Assenza di connettività diretta al controller di dominio: se il client non può raggiungere un KDC, Kerberos non riesce a emettere il ticket.
• Applicazioni legacy: molti software invocano direttamente NTLM invece di usare la modalità Negotiate, che dovrebbe scegliere Kerberos dove possibile.
• Accessi tramite indirizzi IP: la risoluzione basata su Service Principal Name (SPN) richiede nomi DNS; chi accede tramite IP spesso ricade su NTLM.

Per anni le aziende hanno preferito accettare questo compromesso piuttosto che mappare e correggere tutte le dipendenze. NTLM è quindi diventato un protocollo invisibile: se qualcosa non funziona con Kerberos, il sistema ripiega su NTLM e tutto continua a funzionare, nascondendo i problemi.

I limiti di NTLM e i vantaggi di Kerberos

Kerberos è il protocollo di autenticazione raccomandato da Microsoft. Come spiega la documentazione tecnica, Windows implementa la versione 5 di Kerberos, integra estensioni per l’uso di chiavi pubbliche, il trasporto di dati di autorizzazione e la delega. Il KDC è integrato nel controller di dominio e usa il database di Active Directory Domain Services come archivio degli account. Il modello Kerberos consente alcuni vantaggi chiave:

• Delegated authentication: un servizio frontend può impersonare il client quando accede a un backend, cosa che NTLM non permette senza autenticarsi nuovamente.
• Single signon: l’utente o il servizio si autentica una sola volta e usa i ticket per accedere ad altre risorse nel dominio senza nuove richieste di credenziali.
• Efficienza: con NTLM ogni autenticazione richiede una comunicazione con il controller di dominio; Kerberos usa ticket rinnovabili e riduce le comunicazioni, tranne quando è necessario validare un PAC (Privilege Attribute Certificate).
• Mutual authentication: Kerberos permette a ciascuna parte di verificare l’identità dell’altra; NTLM, invece, presuppone la genuinità del server e non consente al client di verificarne l’identità. In un’ottica zero trust, continuare a usare un protocollo che dà per scontato che il server sia legittimo appare contraddittorio.

Che cosa sono IAKerb e Local KDC

NTLM resta un’opzione solo perché in alcuni scenari Kerberos non può funzionare. Le funzionalità IAKerb e Local KDC nascono proprio per colmare queste lacune.

• IAKerb (Initial and Pass Through Kerberos): consente al client di completare l’autenticazione Kerberos anche quando non può contattare direttamente un KDC. In pratica il server applicativo si comporta da proxy, inoltrando al KDC la richiesta del client. Il server non ottiene la password o l’hash: passa soltanto i messaggi Kerberos, così il client riceve comunque un ticket valido. Questo meccanismo evita il fallback automatico a NTLM quando un controller di dominio non è raggiungibile.
• Local KDC: affronta il problema degli account locali e degli ambienti non basati su dominio. Introduce un KDC locale che permette di usare Kerberos per l’autenticazione ai servizi locali senza la necessità di comunicare con un controller di dominio. In questo modo, scenari che oggi usano NTLM (perché l’account non è nel dominio) potranno sfruttare ticket Kerberos.

Queste funzionalità sono disponibili nelle versioni Insider Preview di Windows 11 e Windows Server 2025, ma rappresentano un primo assaggio di un cambiamento più ampio. Microsoft ha annunciato che l’autenticazione NTLM di rete verrà disabilitata per impostazione predefinita in future major release. Nel frattempo, viene resa disponibile una fase di audit e di transizione per aiutare le organizzazioni a mappare le dipendenze.

Audit e mappatura delle dipendenze NTLM

La prima tappa del percorso è scoprire dove NTLM viene ancora utilizzato. Microsoft suggerisce di non disabilitare NTLM all’improvviso, ma di avviare il monitoraggio e l’audit. Ecco alcuni passaggi pratici per identificare le dipendenze.

Abilitare i log operativi di NTLM

1. Aprire una Elevated PowerShell su un Domain Controller o su un client di test.
2. Abilitare il log operativo NTLM:

Figura 1 – Gestione log

1. Per verificare quali eventi sono stati registrati, eseguire:

Figura 2 – Verifica log

Gli eventi includono dettagli sul tipo di autenticazione NTLM e sull’host che l’ha richiesta. In base agli ID, è possibile distinguere tra autenticazioni in ingresso e in uscita, autenticazioni locali o remote e scenari di fallback.

Analizzare gli eventi di sicurezza

Gli eventi della log Security forniscono ulteriori indicazioni. Ad esempio, l’evento 4776 indica la validazione di un account da parte del controller di dominio e può essere filtrato per vedere quali account usano NTLM:

Figura 3 – Verifica log

Per individuare dove NTLM viene usato per l’accesso a risorse, è utile filtrare gli eventi 4624 in cui il campo Authentication Package è NTLM:

Figura 4 – Verifica log

Queste analisi rivelano quali server, dispositivi o applicazioni sono ancora legati a NTLM e consentono di preparare un piano di migrazione.

Simulare l’uso di Kerberos e NTLM su una share SMB

Un modo semplice per capire come Kerberos e NTLM si comportano è testare l’accesso a una share SMB:

1. Configurare un server membro FS01.lab.local e creare una share \\FS01.lab.local\share.
2. Dal client, svuotare il ticket cache Kerberos:

Figura 5 – Eliminazione ticket

3. Accedere alla share utilizzando il nome DNS (Kerberos dovrebbe essere usato):

Figura 6 – Verifica share

4. Richiedere esplicitamente il ticket