Should I disable NTLM before auditing it?

No. Enable the Restrict NTLM audit policies first (domain, incoming, and outgoing traffic), collect at least 2-4 weeks of events, and fix the resolvable Kerberos fallback causes before switching any policy to Deny.

Which Event IDs show NTLM authentication in Active Directory?

Event 4624 with Authentication Package NTLM shows successful NTLM logons on the target server. Event 4776 on the domain controller shows NTLM credential validation. The Restrict NTLM policies also log detailed audit and block events in Applications and Services Logs > Microsoft > Windows > NTLM > Operational.

Where are the Restrict NTLM Group Policy settings located?

All Restrict NTLM and LAN Manager authentication level settings are under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

Why does a client still use NTLM even though Kerberos is configured correctly?

The most common causes are connecting by IP address or short name instead of a name matching the registered SPN, missing or duplicate SPNs, a service account that does not own the SPN, or missing Kerberos delegation on a multi-tier application.

Does blocking NTLM behave the same way across domain trusts?

No. Parent-child and other intra-forest trusts are transitive and secured by default. External trusts and forest trusts add SID filtering and, if enabled, selective authentication, which can block authentication independently of the NTLM/Kerberos protocol choice.

← Field Guides

Active DirectoryAuthenticationDomain ControllersHardeningKerberosNTLMSecurity

Audit NTLM in Active Directory: dal monitoraggio al blocco

Pubblicato: 24 agosto 2026

Topic

La guida segue il principio Microsoft piu importante per questo tema: prima osservare l'uso reale di NTLM, poi correggere le dipendenze, infine applicare restrizioni progressive. Un blocco eseguito senza una fase di audit non è hardening: è un test di compatibilita fatto direttamente in produzione, quello che amichevolemente chiamiamo "scream test".

Contesto: NTLM non e il piano di migrazione

In un dominio Active Directory, Kerberos è il protocollo preferenziale per l'autenticazione. NTLM resta disponibile per compatibilità, ma spesso nasconde problemi di naming, SPN, delega, applicazioni legacy o configurazioni non documentate.

Il punto non è chiedersi soltanto "come blocco NTLM?". Le domande operative sono:

quali account, client, server e applicazioni stanno usando NTLM?
quale lato della connessione sta negoziando NTLM?
il fallback è causato da un errore Kerberos correggibile?
la dipendenza è realmente legacy oppure è solo un accesso via IP o alias?
chi è owner del servizio e quale test dimostra che il cambio è sicuro?

Microsoft documenta le impostazioni di restrizione NTLM nella security policy e raccomanda di usare l'audit per identificare le dipendenze prima di bloccare il protocollo. 1 2 3

Il modello corretto: quattro fasi, non un singolo flag

Fase 1: baseline e audit

Raccogli una fotografia del dominio e definisci il periodo di osservazione. Una finestra troppo breve puo perdere job notturni, processi di backup, batch mensili, accessi amministrativi e flussi di disaster recovery.

La baseline deve includere almeno:

Domain Controller e versione del sistema operativo;
client e server Windows rilevanti;
trust e domini coinvolti;
applicazioni pubblicate e servizi multi-tier;
account di servizio e loro owner;
appliance, NAS, stampanti e sistemi Linux domain-joined;
GPO che modificano NTLM, LAN Manager o protocolli di autenticazione;
finestre operative e sistemi che non possono essere riavviati senza change.

Fase 2: triage degli eventi

Non trattare ogni evento NTLM come una causa uguale. Il record va arricchito con almeno:

timestamp e Domain Controller che ha registrato l'evento;
client e server coinvolti;
account usato;
servizio o protocollo interessato;
applicazione o processo, quando disponibile;
workstation, server o appliance di origine;
frequenza e distribuzione temporale;
owner tecnico e owner applicativo;
azione proposta e criterio di verifica.

Un conteggio aggregato del tipo "ci sono 10.000 eventi" non basta. Il dato utile è una mappa di dipendenze che permetta di rispondere a una domanda concreta: quale servizio smetterà di funzionare se questo percorso NTLM viene bloccato?

Fase 3: remediation della causa

Prima di classificare una dipendenza come legacy, verifica se è un fallback Kerberos risolvibile. Le cause frequenti includono:

accesso tramite indirizzo IP;
nome breve usato al posto del nome coerente con il servizio;
alias DNS o CNAME senza SPN coerenti;
SPN mancante o duplicato;
servizio eseguito con un account diverso da quello che possiede lo SPN;
delega Kerberos necessaria ma non progettata;
keytab o configurazione Kerberos non allineata sui sistemi non Windows;
applicazione che supporta solo NTLM;
appliance o protocollo che non supporta Kerberos.

Microsoft segnala che i client Windows normalmente non tentano Kerberos quando la destinazione è un indirizzo IP e possono quindi ricadere su altri protocolli abilitati. La correzione preferibile è usare un nome DNS stabile e coerente con gli SPN; il supporto agli IP-based SPN va valutato solo quando il naming non puo essere corretto. 4

Per un approfondimento diagnostico su SPN mancanti, duplicati e casi KCD/RBCD, vedi la guida SPN in Active Directory. Per capire perche il fallback verso NTLM non e mai "innocuo" e quali Event ID lo rendono visibile, vedi Fallback Kerberos -> NTLM in Active Directory. Per i limiti e i casi d'uso corretti di Protected Users come strumento di test, vedi Protected Users: limiti in produzione.

Casi reali osservati sul campo

Questi sono esempi concreti incontrati durante attivita di assessment, utili per riconoscere pattern simili nel proprio ambiente:

Drive mapping via GPO con indirizzo IP: una Group Policy Preference mappa un'unita come \\192.168.10.7\dati invece di \\fileserver.dominio.local\dati. Il client non tenta mai Kerberos verso quella destinazione e ricade su NTLM ogni volta che l'unita viene montata, per ogni utente del dominio interessato dalla policy.
Applicazione line-of-business con stringa di connessione storica: un gestionale configurato anni prima punta a un IP fisso perche, all'epoca, il DNS interno non era affidabile. Nessuno ha piu rivisto la stringa di connessione dopo la stabilizzazione del DNS.
Backup job che usa il nome NetBIOS breve: uno script pianificato si collega con \\FS01\backup invece di \\fs01.dominio.local\backup; funziona, ma passa sempre da NTLM anche se il file server è perfettamente in grado di negoziare Kerberos.
Load balancer con VIP non registrato come SPN: i client raggiungono un servizio web tramite un virtual IP o un nome pubblicato dal bilanciatore, ma lo SPN è registrato solo sul nome reale del server dietro al balancer.

In tutti questi casi la causa non è "il servizio è vecchio": è un naming che non è mai stato allineato agli SPN, spesso invisibile finché non si osservano gli eventi NTLM in audit.

Compatibilita NTLM/NTLMv2 per tipo di sistema

La tabella seguente riprende i livelli documentati da Microsoft per l'impostazione Network security: LAN Manager authentication level (LmCompatibilityLevel). Va letta come riferimento per capire quali protocolli un sistema può inviare o accettare, non come indicazione automatica di quale livello impostare: la scelta dipende dai client e dai servizi realmente presenti in dominio.

Livello registro	Impostazione	Comportamento client	Comportamento Domain Controller
0	Send LM & NTLM responses	Invia LM e NTLM, mai NTLMv2 session security	Accetta LM, NTLM e NTLMv2
1	Send LM & NTLM - use NTLMv2 session security if negotiated	Invia LM e NTLM, usa NTLMv2 session security se il server la supporta	Accetta LM, NTLM e NTLMv2
2	Send NTLM response only	Invia solo NTLMv1 (con NTLMv2 session security se supportata)	Accetta LM, NTLM e NTLMv2
3	Send NTLMv2 response only	Invia solo NTLMv2	Accetta LM, NTLM e NTLMv2
4	Send NTLMv2 response only. Refuse LM	Invia solo NTLMv2	Rifiuta LM, accetta NTLM e NTLMv2
5	Send NTLMv2 response only. Refuse LM & NTLM	Invia solo NTLMv2	Rifiuta LM e NTLM, accetta solo NTLMv2

Microsoft documenta che, dal punto di vista dei default effettivi, i server standalone e i member server moderni si attestano gia su "Send NTLMv2 response only" (livello 3), mentre sui client la policy risulta "Not Defined" salvo configurazione esplicita. Verifica sempre il valore effettivo con Get-ItemProperty sul registro o tramite RSOP prima di alzare il livello, perche sistemi molto datati o appliance legacy potrebbero non supportare NTLMv2 e smettere di autenticarsi. 6

Fase 4: enforcement progressivo

L'enforcement deve essere applicato per scope e per fasi, con un gruppo pilota, monitoraggio e rollback già definito. La sequenza esatta dipende dalla versione del sistema operativo e dal perimetro che si vuole proteggere.

Per decidere quali dipendenze emerse dall'audit correggere subito e quali affrontare nel pilota, usa il framework per dare priorità ai finding di hardening Active Directory.

Un modello prudente è:

audit senza blocco;
remediation dei fallback Kerberos evidenti;
test su client e account rappresentativi;
restrizione su una OU pilota o su un perimetro tecnico controllato;
verifica di autenticazioni, servizi, job e accessi interattivi;
estensione per gruppi di sistemi con owner identificato;
gestione esplicita delle eccezioni residue;
revisione periodica delle eccezioni e loro eliminazione quando possibile.

Come fare l'audit: policy, GPO e Event ID da controllare

Questa sezione traduce le Fasi 1 e 2 in configurazioni concrete: quali policy attivare, dove si trovano nella GPO e quali Event ID correlare. Va verificata contro la build di Windows Server e Windows client realmente in uso prima di essere applicata.

Il log da monitorare

La maggior parte degli eventi generati dalle policy Restrict NTLM non finisce nel log Security, ma in un log dedicato:

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

Microsoft documenta esplicitamente che gli eventi di audit e di blocco delle policy Restrict NTLM vengono registrati in questo log operativo, e non tramite una security audit policy configurabile a parte. Va quindi abilitato e raccolto separatamente rispetto al log Security. 8

# Abilita il log NTLM operational (disabilitato di default) su un host di test
wevtutil set-log "Microsoft-Windows-NTLM/Operational" /enabled:true

# Esporta gli eventi raccolti per analisi
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Select-Object TimeCreated, Id, Message |
    Export-Csv ntlm-operational.csv -NoTypeInformation -Encoding UTF8

Policy da configurare in Fase 1 (audit, nessun blocco)

Tutte le policy seguenti si trovano nello stesso percorso GPO:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Policy	Dove si applica	Valore consigliato in audit	Cosa produce
Network security: Restrict NTLM: Audit NTLM authentication in this domain	Domain Controller	Enable all	Log di ogni autenticazione NTLM verso i DC del dominio
Network security: Restrict NTLM: Audit incoming NTLM traffic	Server membri	Enable auditing for all accounts	Log delle richieste NTLM in ingresso su quel server
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	Client e server che avviano connessioni	Audit all	Log dei server remoti verso cui il client invia richieste NTLM
Network security: LAN Manager authentication level	Tutti i sistemi	Verificare il valore effettivo prima di modificarlo	Non genera log di per se, ma determina se LM/NTLMv1 sono ancora inviati o accettati

Queste tre policy di audit non bloccano nulla: servono solo a costruire la mappa di dipendenze descritta nella Fase 1 e nella Fase 2. Vanno sempre attivate prima delle rispettive policy di blocco. Non confondere l'audit con il blocco: una policy di audit produce solo evidenza, mentre una policy di restrizione cambia il comportamento di autenticazione e può causare errori applicativi.

Policy di enforcement (Fase 4, solo dopo il pilota)

Policy di blocco	Corrispondente policy di audit da usare prima	Valori
Network security: Restrict NTLM: NTLM authentication in this domain	Restrict NTLM: Audit NTLM authentication in this domain	Deny for domain accounts to domain servers / Deny for domain accounts / Deny for domain servers / Deny all
Network security: Restrict NTLM: Incoming NTLM traffic	Restrict NTLM: Audit incoming NTLM traffic	Deny all domain accounts / Deny all accounts
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	stessa policy, valore Audit all in fase precedente	Deny all

Prima di passare a Deny, usa le liste di eccezione dedicate per i sistemi che restano legittimamente su NTLM durante la transizione:

Network security: Restrict NTLM: Add server exceptions in this domain (per il blocco lato dominio);
Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication (per il blocco outgoing lato client).

Attenzione: come per RC4, l'ordine conta. Non attivare le policy di blocco prima di aver raccolto almeno 2-4 settimane di audit e aver corretto le cause risolvibili viste nella Fase 3.

Event ID da correlare

Event ID	Log	Cosa indica
4624 con Authentication Package = NTLM	Security, sul server di destinazione	Logon riuscito che ha usato NTLM invece di Kerberos; il campo `Package Name (NTLM only)` distingue NTLMv1/NTLMv2/LM
4776	Security, sul Domain Controller (o sistema autoritativo per l'account)	Validazione delle credenziali NTLM; utile per vedere account, Source Workstation e codice di errore
Eventi della famiglia Restrict NTLM (audit e blocco)	Applications and Services Logs > Microsoft > Windows > NTLM > Operational	Dettaglio per singola richiesta NTLM audita o bloccata dalle policy Restrict NTLM

# Correlazione rapida: eventi 4624 con NTLM come pacchetto di autenticazione, ultimi 30 giorni
$startDate = (Get-Date).AddDays(-30)

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4624
    StartTime = $startDate
} -ErrorAction SilentlyContinue |
Where-Object { $_.Properties[8].Value -eq "NTLM" } |
Select-Object TimeCreated,
    @{ N="Account";       E={ $_.Properties[5].Value } },
    @{ N="LogonType";     E={ $_.Properties[8].Value } },
    @{ N="AuthPackage";   E={ $_.Properties[9].Value } },
    @{ N="SourceHost";    E={ $_.Properties[11].Value } } |
Export-Csv ntlm-logons-4624.csv -NoTypeInformation -Encoding UTF8

# Evento 4776 sui Domain Controller, per vedere validazioni NTLM delle credenziali
$dcs = (Get-ADDomainController -Filter *).Name
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = "Security"
        Id        = 4776
        StartTime = $startDate
    } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated,
        @{ N="Account";           E={ $_.Properties[1].Value } },
        @{ N="SourceWorkstation"; E={ $_.Properties[2].Value } },
        @{ N="ErrorCode";         E={ $_.Properties[3].Value } },
        @{ N="DC";                E={ $dc } }
} | Sort-Object TimeCreated -Descending | Export-Csv ntlm-4776.csv -NoTypeInformation -Encoding UTF8

Gli indici delle proprietà (Properties[n]) variano in base alla versione del sistema operativo e alla localizzazione: vanno sempre validati con Get-WinEvent ... | Select-Object -First 1 -ExpandProperty Properties su un evento reale prima di usarli in uno script di raccolta su larga scala.

Come leggere un evento senza saltare alla conclusione

Per ogni evento, costruisci una scheda di triage:

Campo	Domanda operativa
Client	Quale macchina ha iniziato la richiesta?
Target	Quale server o servizio ha ricevuto la richiesta?
Account	E un utente, un account di servizio o un computer account?
Protocollo	L'evento identifica NTLMv1, NTLMv2 o una categoria piu generale?
Applicazione	Quale processo o servizio ha originato la connessione?
Naming	Il target è stato raggiunto con IP, alias, short name o FQDN?
Frequenza	E un flusso continuo, un job schedulato o un evento isolato?
Owner	Chi può modificare il servizio o l'applicazione?
Piano	Qual è la correzione, il test e il rollback?

Un evento isolato non dimostra da solo una dipendenza critica. Al contrario, un flusso raro ma legato a backup, payroll, produzione o disaster recovery puo essere più importante di migliaia di accessi ordinari.

Triage delle cause: la prima domanda è: Kerberos sarebbe possibile?

Accesso via IP

Sostituisci, quando possibile, il riferimento IP con un nome DNS stabile. Poi verifica che il nome utilizzato dal client corrisponda al servizio e alla registrazione SPN prevista.

Non registrare SPN basati su IP come riflesso automatico. Microsoft documenta questa possibilità, ma richiama i rischi di conflitto e il fatto che gli IP possono cambiare. Deve essere un'eccezione tecnica motivata, non il percorso standard di naming.

Controlli rapidi da eseguire dal client che genera la connessione, prima e dopo aver riprodotto l'accesso:

rem risolve il nome host associato all'IP (reverse DNS)
ping -a 192.168.10.7

rem mostra se esiste gia un ticket Kerberos per il servizio target
klist

# verifica la risoluzione DNS inversa e diretta per confrontare i nomi
Resolve-DnsName -Name 192.168.10.7
Resolve-DnsName -Name fileserver.dominio.local

# elenca gli SPN registrati sull'account del servizio target
setspn -L fileserver

Come leggere il risultato: se ping -a o Resolve-DnsName non restituiscono un nome coerente con quello usato negli SPN, oppure se dopo aver riprodotto l'accesso klist non mostra un ticket di servizio (krbtgt a parte) per la destinazione, la connessione sta quasi certamente negoziando NTLM invece di Kerberos. Ripeti klist prima e dopo il test per isolare il ticket generato dalla connessione specifica.

SPN mancante o duplicato

Controlli iniziali da eseguire in un ambiente di test o durante una finestra approvata:

setspn -Q HTTP/app01.contoso.com
setspn -X

La correzione deve essere fatta sul servizio e sull'account proprietario corretti. Non aggiungere SPN "finchè funziona": un SPN duplicato può spostare il problema invece di risolverlo.

SQL Server

Per SQL Server, verifica il nome usato dalla connessione, l'account del servizio e gli SPN. Una verifica applicativa utile è controllare lo schema di autenticazione della sessione:

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Il risultato deve essere interpretato nel contesto della connessione testata. Una singola sessione Kerberos non dimostra che tutti i client e tutti gli alias siano corretti.

Per questo tipo di diagnosi, Microsoft mette a disposizione un tool gratuito dedicato: Kerberos Configuration Manager for SQL Server (Microsoft download 39046). Il tool si collega a un'istanza SQL Server (motore, SSRS o SSAS) e analizza automaticamente:

quali SPN sono registrati e su quale account;
se esistono SPN duplicati o mancanti per il servizio interrogato;
se l'account che esegue il servizio ha i permessi necessari per registrare o aggiornare gli SPN;
una proposta guidata di correzione, con la possibilita di generare i comandi setspn corretti invece di scriverli a mano.

E particolarmente utile perchè riduce l'errore umano nella fase più delicata (capire quale account possiede davvero lo SPN) e fornisce un report leggibile anche a chi non gestisce SQL Server quotidianamente. Resta comunque necessario validare il risultato con un test di connessione reale (auth_scheme) dopo la correzione, perche il tool segnala lo stato degli SPN ma non garantisce che ogni client si connetta con il nome corretto.

IIS e applicazioni multi-tier

Questa parte richiede qualche premessa per chi non lavora quotidianamente con IIS (Internet Information Services, il web server di Windows Server).

Quando un browser o un client accede a un sito ospitato su IIS, il sito viene legato a un application pool, cioe il processo Windows che esegue effettivamente il codice dell'applicazione. Quel processo gira sotto un'identità (un account di dominio, un account virtuale o un account di sistema): è quell'identità, non l'utente che naviga, a dover possedere lo SPN corretto se si vuole usare Kerberos.

Un secondo concetto chiave è l'host header: lo stesso server IIS puo rispondere a piu nomi diversi (per esempio intranet.contoso.com e intranet come nome breve). Se l'utente digita un nome per cui non esiste uno SPN HTTP/<nome> registrato sull'account dell'application pool, Windows non riesce a costruire un ticket Kerberos per quel nome specifico e il browser ripiega su NTLM, anche se lo stesso sito funziona perfettamente in Kerberos con un altro nome.

Punti pratici da verificare, in ordine:

con quale nome gli utenti raggiungono davvero il sito (FQDN, nome breve, alias, IP): spesso non è quello che il team che ha creato il sito si aspetta;
quale account esegue l'application pool in IIS Manager (Application Pools -> Advanced Settings -> Identity);
quali SPN HTTP esistono per quell'account, per esempio con setspn -L <account>;
se manca uno SPN HTTP/<nome-usato-dagli-utenti>, quello è quasi sempre il motivo del fallback su NTLM per quell'alias specifico;
se l'applicazione è multi-tier (per esempio un sito IIS che deve autenticarsi a sua volta su un database o un servizio a valle usando l'identità dell'utente originale): in questo caso non basta che il primo hop (browser -> IIS) funzioni in Kerberos. Serve anche la delega Kerberos (constrained o resource-based) configurata sull'account dell'application pool, altrimenti il secondo hop (IIS -> database) non può portare avanti l'identità dell'utente e tipicamente ricade su un account di servizio fisso o fallisce.

In sintesi: un sito IIS può risultare "a posto" su un nome e comunque cadere su NTLM su un altro nome dello stesso sito, ed essere corretto sul primo hop ma rotto sul secondo se manca la delega. Ogni nome pubblicato e ogni hop vanno verificati separatamente.

File server, NAS e appliance

Mappa share, script, job e dispositivi che usano \\IP\share o nomi non standard. Per le appliance, documenta esplicitamente se Kerberos è supportato dal firmware e dal protocollo realmente utilizzato.

Domini root-child e trust: cosa cambia

Un audit o un enforcement NTLM pensato per un singolo dominio può comportarsi in modo molto diverso se l'ambiente ha una struttura multi-dominio o relazioni di trust verso l'esterno. Questo aspetto va sempre verificato prima di estendere una restrizione oltre il perimetro di un singolo dominio.

Domini root-child e altri trust nella stessa foresta

I trust interni a una foresta (parent-child, tree-root, shortcut) sono transitivi e, secondo Microsoft, sono già protetti in modo adeguato per impostazione predefinita: non richiedono configurazioni aggiuntive per mitigare le minacce note. 7

Dal punto di vista pratico, questo significa che un client nel dominio child può normalmente ottenere un ticket Kerberos per una risorsa nel dominio root (o in un altro dominio della stessa foresta) tramite i referral automatici tra Key Distribution Center. Se in questo percorso compare comunque NTLM, la causa è quasi sempre la stessa vista finora: naming non coerente con lo SPN, accesso via IP, oppure un servizio che non ha mai negoziato Kerberos a prescindere dal dominio in cui si trova.

Trust esterni e trust di foresta (interforest)

La situazione cambia con i trust tra foreste diverse (forest trust) o con i trust esterni (external trust) verso domini non facenti parte della stessa foresta. Qui entrano in gioco due controlli di sicurezza che Microsoft documenta esplicitamente e che vanno sempre mappati prima di intervenire su NTLM:

SID filtering (quarantena): applicata di default sui trust esterni creati con versioni moderne di Windows Server; filtra i SID che non appartengono al dominio trusted, per prevenire elevazioni di privilegio tramite SID history. Va gestita con cautela: disabilitarla riduce la sicurezza della foresta. 7
Selective authentication: se abilitata su un trust esterno o di foresta, un utente proveniente dal dominio trusted deve avere il permesso esplicito Allowed to Authenticate sull'oggetto computer della risorsa, altrimenti l'autenticazione fallisce a prescindere dal protocollo. Microsoft segnala inoltre che, quando l'autenticazione avviene con NTLM invece che con Kerberos, questo permesso va concesso sull'account computer anche se il servizio gira con un account di dominio. 7

Il punto operativo più importante per un progetto NTLM è questo: l'autenticazione Kerberos attraverso un forest trust richiede che lo SPN della risorsa venga risolto tramite il global catalog e un referral verso il dominio corretto nell'altra foresta. Se questa risoluzione fallisce (SPN non pubblicato, suffisso di nome non registrato nel trust, client che non riesce a seguire il referral), il client può ripiegare su NTLM per quella connessione specifica, anche se localmente Kerberos funziona senza problemi.

Il diagramma seguente riassume i due percorsi possibili e dove intervenire in caso di problemi:

flowchart TD

C([Client nel dominio trusted<br/>richiede una risorsa nel dominio/foresta trusting]) --> R{SPN della risorsa<br/>risolvibile tramite<br/>Global Catalog + referral?}

R -- Si --> K[Percorso Kerberos]
K --> K1{Selective authentication<br/>abilitata sul trust?}
K1 -- No --> K2[Ticket emesso<br/>autenticazione Kerberos riuscita]
K1 -- Si --> K3{Utente/gruppo ha il permesso<br/>Allowed to Authenticate<br/>sull'oggetto computer?}
K3 -- Si --> K2
K3 -- No --> K4[Autenticazione negata<br/>non e un problema di NTLM/Kerberos]

R -- No --> N[Fallback su NTLM<br/>per questa connessione]
N --> N1{Selective authentication<br/>abilitata sul trust?}
N1 -- Si --> N2[Serve comunque Allowed to Authenticate<br/>sull'account computer]
N1 -- No --> N3[NTLM negoziato se il trust<br/>e il dominio target lo consentono]
N --> N4{SID filtering / quarantena<br/>sul trust esterno}
N4 --> N5[SID esterni al dominio trusted<br/>vengono filtrati]

style K2 fill:#1f8a4c,color:#fff
style K4 fill:#b3261e,color:#fff
style N4 fill:#b58900,color:#fff

Come leggere il diagramma: il ramo di sinistra (Kerberos) è quello desiderato ed è quello su cui puntare con la remediation di naming e SPN; il ramo di destra (NTLM) è quello da monitorare in audit e da correggere quando la causa è risolvibile. La selective authentication e il SID filtering non sono problemi di protocollo: sono controlli aggiuntivi che possono bloccare l'accesso anche quando Kerberos o NTLM avrebbero funzionato, e vanno diagnosticati separatamente.

Perché questo conta per l'audit e per l'enforcement

Prima di estendere una policy di restrizione NTLM oltre un singolo dominio, verifica sempre:

quali trust esistono (parent-child, tree-root, shortcut, forest, external, realm) e la loro direzione (uno o due sensi) e transitività;
se un trust esterno collega un dominio o una foresta che non supporta pienamente Kerberos (per esempio domini legacy o realm non Windows con configurazione limitata): in quel caso NTLM può essere l'unico protocollo disponibile per gli utenti che arrivano da quel trust, e bloccarlo interrompe tutta l'autenticazione proveniente da li;
se e dove è abilitata la selective authentication, perché introduce un ulteriore punto di fallimento indipendente da NTLM/Kerberos che può essere scambiato per un problema di protocollo;
se gli eventi NTLM raccolti in audit provengono da un dominio child, dal root, oppure da un trust esterno: la remediation e i rischi di enforcement sono molto diversi nei tre casi.

Non trattare l'ambiente come un dominio singolo se non lo è: un piano di enforcement corretto deve avere uno scope esplicito per dominio e, separatamente, uno scope esplicito per ogni trust verso l'esterno.

Cosa non usare come scorciatoia

Protected Users non è un sostituto dell'audit

Protected Users impone restrizioni forti agli account membri, tra cui l'impossibilità di usare NTLM e la necessità di supportare i requisiti Kerberos previsti. E uno strumento utile per test mirati e per account compatibili, ma aggiungere account senza una mappa delle dipendenze può causare un'interruzione immediata.

Per il dettaglio completo su come funziona il gruppo, quali restrizioni impone e in quali casi va evitato, vedi la guida Protected Users: limiti in produzione.

Non disabilitare NTLM nel dominio per "vedere cosa succede"

Il blocco globale senza una fase di audit può rompere autenticazioni interattive, servizi, script, backup, accessi a share, applicazioni legacy e flussi tra domini. La pressione per eliminare NTLM non sostituisce il change plan.

Non creare eccezioni permanenti senza owner

Un'eccezione deve avere almeno: sistema, account, destinazione, motivo, rischio accettato, owner, scadenza, controllo compensativo e piano di rimozione. Un allow-list senza scadenza diventa una nuova baseline invisibile.

Piano di change consigliato

Prima del cambio

esporta le GPO e documenta il link order;
salva la configurazione corrente delle policy NTLM;
definisci il perimetro pilota;
informa gli owner dei servizi critici;
verifica i log sui Domain Controller e sui target;
prepara test funzionali per autenticazione, accesso alle share, applicazioni e job;
definisci rollback e criteri di stop.

Durante il cambio

applica la policy solo al perimetro approvato;
forza l'aggiornamento delle policy secondo la procedura interna;
osserva errori di autenticazione e indisponibilita applicative;
non aggiungere eccezioni senza registrarle;
raccogli l'ora esatta del cambio per correlare gli eventi.

Dopo il cambio

ripeti i test funzionali;
confronta gli eventi con la baseline precedente;
verifica i sistemi che non hanno prodotto traffico durante la finestra;
controlla backup, monitoring, batch e accessi amministrativi;
registra i risultati per ogni owner;
pianifica la rimozione delle eccezioni.

Criteri di rollback

Il rollback non deve essere "ripristina la GPO" e basta. Definisci prima soglie osservabili, per esempio:

fallimento di un servizio critico senza workaround approvato;
perdita di accesso amministrativo a un gruppo di sistemi;
errore nei backup o nella replica;
autenticazioni fallite oltre la soglia concordata;
impatto su un flusso regolamentato o su un sistema Tier 0.

Il rollback deve ripristinare la configurazione precedente, mantenere l'audit attivo e generare un nuovo piano per la dipendenza che ha causato il blocco. Tornare indietro senza classificare la causa rimanda soltanto il problema.

Checklist di review

Conclusione

Ridurre NTLM non significa spostare un interruttore da Enabled a Disabled. Significa rendere visibili le dipendenze che il dominio ha tollerato per anni, correggere quelle che hanno una causa tecnica risolvibile e governare le poche eccezioni che restano.

Il percorso piu difendibile è quello misurabile: audit, classificazione, remediation, pilota, enforcement, verifica e revisione. La configurazione finale deve essere il risultato di prove raccolte sui servizi reali, non di una policy copiata da un altro dominio.

Fonti Microsoft da verificare prima della pubblicazione

I contenuti di questa guida sono forniti a titolo informativo, senza garanzie. L'applicazione di qualsiasi procedura è sotto la responsabilità dell'utente. Disclaimer.

Apprezzamento

Se questa guida ti è utile, lascia un like.

Guide correlate

Active Directory / Domain Controllers