Eliminare NTLM in azienda: audit, compatibilità e dismissione per fasi
NTLM è ancora presente in molte infrastrutture Windows perché applicazioni legacy, accessi tramite indirizzo IP, nomi non risolvibili, trust, dispositivi di rete e configurazioni incomplete impediscono l’uso di Kerberos. Il problema non si risolve attivando una GPO di blocco senza conoscere le dipendenze: una dismissione sicura parte dall’audit, corregge le cause e applica restrizioni progressive.
Microsoft ha rimosso NTLMv1 da Windows 11 24H2 e Windows Server 2025. LANMAN e NTLMv2 sono deprecati e non ricevono nuovo sviluppo funzionale; NTLMv2 continua a funzionare, ma Microsoft ne prevede la rimozione in una versione futura. La roadmap deve quindi eliminare subito LM/NTLMv1 e ridurre progressivamente NTLMv2.
Principio di sicurezza
Non confondere “disabilitare NTLMv1” con “eliminare NTLM”. Il primo è un controllo minimo; il secondo richiede inventario delle autenticazioni, correzione delle dipendenze e blocco progressivo con eccezioni temporanee governate.
Perché NTLM aumenta il rischio
- Supporta scenari di relay se i protocolli e i servizi non applicano protezioni adeguate.
- Espone hash e challenge-response ad attacchi offline e password cracking.
- Riduce i vantaggi di Kerberos, mutual authentication e protezione dei ticket.
- Mantiene dipendenze legacy difficili da osservare e controllare.
- Può essere sfruttato in catene di attacco che coinvolgono SMB, LDAP, HTTP, AD CS e altri servizi.
- Rende più complesso applicare segmentazione, tiering amministrativo e identity security.
Per una visione più ampia delle configurazioni che amplificano il rischio, consulta le vulnerabilità Active Directory più comuni.
Definire il perimetro e i criteri di successo
- Domini, foreste, trust, server membri, client, appliance e segmenti inclusi.
- Flussi business-critical che non possono essere interrotti.
- Periodo di audit sufficiente a coprire attività mensili, batch e chiusure contabili.
- Responsabili delle applicazioni e processo di gestione delle eccezioni.
- Obiettivo iniziale: rimozione NTLMv1, riduzione NTLMv2, blocco su sistemi pilota e misurazione.
Attivare l’audit senza bloccare
Le policy di sicurezza “Network security: Restrict NTLM” permettono di osservare traffico in ingresso, in uscita e autenticazioni nel dominio senza applicare subito il deny. Gli eventi vengono registrati nel log operativo Applications and Services Logs > Microsoft > Windows > NTLM. La raccolta centralizzata evita di analizzare manualmente ogni server.
- Sui domain controller: “Audit NTLM authentication in this domain”.
- Su server membri: “Audit Incoming NTLM Traffic”.
- Sui client e server: audit del traffico NTLM in uscita verso server remoti.
- Raccolta degli eventi con SIEM, Windows Event Forwarding o piattaforma equivalente.
- Correlazione con log applicativi, account, host sorgente, server destinazione e fascia oraria.
Attenzione
L’audit non riduce il rischio da solo. Serve a costruire una matrice delle dipendenze e a prevedere l’impatto delle policy di blocco. I log devono essere protetti e accessibili solo ai ruoli autorizzati.
Classificare ogni dipendenza
| Causa | Segnale | Remediation | Priorità |
|---|---|---|---|
| Accesso con IP o alias | Kerberos non ottiene SPN valido | Usare FQDN, correggere DNS/SPN | Alta |
| Applicazione legacy | Autenticazione solo NTLM | Aggiornare, riconfigurare o sostituire | Alta |
| Servizio con account errato | SPN mancante/duplicato | Correggere service account e SPN | Alta |
| Workgroup/appliance | Fuori dal dominio | Valutare protocolli moderni, certificati o segregazione | Media |
| Trust/configurazione | Fallback inatteso | Correggere trust, time sync, DNS e deleghe | Media |
| Eccezione temporanea | Blocco non immediato | Owner, scadenza, compensazioni e piano di rimozione | Controllata |
Eliminare LM e NTLMv1
Sui sistemi supportati deve essere applicata una baseline coerente che impedisca l’uso di LM e NTLMv1 e richieda NTLMv2 quando il fallback è ancora necessario. La configurazione va prima testata su OU pilota, con verifica di autenticazioni locali, servizi, dispositivi e applicazioni. Sistemi non aggiornabili devono essere isolati e gestiti con un piano di sostituzione.
Correggere le cause che impediscono Kerberos
- DNS e sincronizzazione oraria affidabili.
- SPN corretti, non duplicati e associati all’account di servizio appropriato.
- Accesso tramite nomi coerenti, non indirizzi IP o alias non registrati.
- Applicazioni configurate per Negotiate/Kerberos.
- Account di servizio dedicati o gMSA quando applicabile.
- Deleghe e vincoli configurati secondo il minimo privilegio.
- Hardening di SMB e LDAP, inclusi signing/channel binding dove compatibile.
Per comprendere i componenti e le dipendenze dell’infrastruttura, consulta la guida Active Directory e la guida alle Group Policy Windows.
Applicare il blocco progressivo
- Applicare policy di deny su server pilota a basso rischio e verificare eventi di blocco, ticket e processes.
- Estendere a gruppi omogenei, iniziando dai sistemi moderni e meglio conosciuti.
- Usare liste di eccezione solo quando documentate con owner, motivazione e data di scadenza.
- Bloccare progressivamente autenticazioni NTLM nel dominio dopo aver verificato i flussi residui.
- Rimuovere le eccezioni e monitorare la ricomparsa di dipendenze dopo aggiornamenti e nuove applicazioni.
Controlli compensativi durante la transizione
- SMB signing e LDAP signing/channel binding secondo matrice di compatibilità.
- Extended Protection for Authentication dove supportata.
- Segmentazione dei sistemi legacy e limitazione delle sorgenti autorizzate.
- Riduzione dei privilegi degli account che usano NTLM.
- MFA e protezione delle identità per risorse legacy tramite soluzioni compatibili.
- Monitoraggio di relay, anomalie di autenticazione e uso inatteso di account privilegiati.
Nexsys integra queste verifiche nel servizio di Active Directory Security Assessment & Hardening e nei progetti di Identity Security.
KPI per misurare la dismissione
- Autenticazioni NTLM giornaliere per sorgente e destinazione.
- Numero di applicazioni con owner e remediation definita.
- Percentuale di server con audit attivo e log centralizzato.
- Sistemi con NTLMv1/LM impossibile o disabilitato.
- Eccezioni aperte, età media e scadenze superate.
- Eventi di blocco e incidenti causati dalla transizione.
- Riduzione mensile dei flussi NTLMv2 residui.
Assessment NTLM e Active Directory
Nexsys mappa le autenticazioni residue, identifica le cause, definisce il piano di remediation e accompagna il blocco progressivo senza interrompere i processi critici.
Domande frequenti
NTLMv2 è già stato rimosso?
No. È deprecato e continua a funzionare, ma Microsoft ne prevede la rimozione futura. NTLMv1 è invece rimosso da Windows 11 24H2 e Windows Server 2025.
Posso bloccare NTLM con una sola GPO?
No (o meglio, non direttamente senza rischi). Tecnicamente esistono policy di deny, ma applicarle senza audit può interrompere applicazioni, dispositivi e servizi. La sequenza corretta è audit, remediation, pilot e blocco progressivo.
Perché viene usato NTLM se Kerberos è disponibile?
Cause comuni sono accesso tramite IP, DNS/SPN errati, applicazioni non configurate per Negotiate, trust e dispositivi non integrati nel dominio.
Le eccezioni sono accettabili?
Sì, ma solo temporaneamente, con owner, motivazione, controlli compensativi, scadenza e piano di rimozione.
Qual è il primo obiettivo?
Eliminare LM/NTLMv1, centralizzare l’audit e costruire una mappa affidabile delle dipendenze NTLMv2.