Perché il fallback da Kerberos a NTLM è un problema in Active Directory (e come eliminarlo davvero)

Contesto

In Active Directory, Kerberos è il protocollo di riferimento. NTLM resta supportato per compatibilità, ma in molti ambienti non viene usato in modo esplicito: entra in gioco come fallback silenzioso quando Kerberos non riesce a completare la negoziazione. Microsoft documenta chiaramente che, quando Kerberos non può essere usato, Windows può ricadere su altri protocolli abilitati, incluso NTLM. 1 2 3

Il punto importante è questo: il fallback non è una strategia di autenticazione sana, è un segnale di debolezza. Se un servizio “funziona lo stesso”, spesso significa soltanto che sta cadendo su NTLM invece di usare Kerberos come previsto. Questo è il motivo per cui la rimozione di NTLM o l'introduzione dei Protected Users fa emergere problemi che per mesi erano rimasti invisibili.

---

Il punto chiave: non stai eliminando un protocollo, stai scoprendo dipendenze nascoste

Molti progetti di hardening falliscono perché partono dalla domanda sbagliata. La domanda non è solo "come blocco NTLM?". La domanda utile è: dove Kerberos non sta arrivando davvero fino in fondo?

In pratica, il fallback si presenta quando il client non riesce a costruire un contesto Kerberos valido. Le cause più comuni sono banali ma diffuse:

• SPN mancanti o duplicati
• connessioni tramite indirizzo IP invece che nome host
• alias, CNAME o bilanciatori che non sono stati modellati correttamente
• servizi che girano con account non allineati alla configurazione Kerberos
• keytab, password o configurazioni stale su sistemi non Windows
• applicazioni legacy che hanno sempre tollerato NTLM e non sono mai state testate senza

Questa lista è importante perché spiega perché lo stesso problema si ripresenta in contesti diversi. Non è quasi mai "un errore di NTLM". È un errore di progettazione o configurazione che NTLM maschera.

---

Casi reali che conviene correggere per primi

1. SQL Server raggiunto via IP o con SPN incompleto

Microsoft documenta che, se lo SPN non è registrato correttamente, Kerberos non viene usato e l'autenticazione può ricadere su NTLM. Questo è uno dei casi enterprise più frequenti, soprattutto quando SQL Server viene raggiunto con nome breve, alias o IP anziché con il nome coerente con lo SPN. 2 3

Indicazioni pratiche:

• controlla che il servizio sia raggiunto con FQDN stabile
• verifica che lo SPN esista ed sia unico
• usa auth_scheme per confermare se la sessione è davvero Kerberos

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

Se il risultato non è KERBEROS, il problema non è il client: è quasi sempre il naming del servizio o la registrazione dell'SPN.

2. IIS, application pool e servizi HTTP dietro alias o load balancer

Un'applicazione web può sembrare completamente sana finché non provi a imporre Kerberos. Se il servizio HTTP espone un nome diverso da quello usato nel ticket, oppure se l'app pool gira con un account non allineato allo SPN, il browser cade facilmente su NTLM.

Questo caso è particolarmente ingannevole perché l'utente vede solo che "la pagina si apre". In realtà l'infrastruttura sta già degradando il livello di autenticazione.

Da controllare subito:

• SPN HTTP/hostname e HTTP/fqdn
• alias DNS e CNAME usati dall'applicazione
• account dell'application pool
• configurazione di delega, se presente

3. File server, appliance NAS e stampanti che puntano a un nome non coerente

Molti dispositivi legacy non sono il problema in sé. Il problema è il modo in cui vengono integrati: percorsi SMB configurati con IP, nomi brevi o alias non allineati allo SPN del computer account.

Questi sistemi sono spesso i primi a mostrare fallback perché non hanno stack moderni, non gestiscono bene la negoziazione e restano attivi solo grazie alla tolleranza di NTLM.

Segnali tipici:

• accessi a share con \\IP\share
• autenticazioni che funzionano solo con nome breve, non con FQDN
• dispositivi che falliscono quando NTLM viene auditato o limitato

4. Server Linux domain-joined con keytab o configurazione Kerberos non allineata

Su Linux il problema è spesso doppio: da un lato il computer account in Active Directory deve supportare AES e avere una configurazione coerente, dall'altro il file krb5.conf e la keytab locale devono riflettere la stessa realtà. Se la keytab è stale o il profilo Kerberos permette ancora algoritmi non desiderati, l'autenticazione può degradare o fallire in modi poco chiari. 6 7

Qui il fallback non sempre è verso NTLM nello stesso modo di un client Windows, ma il risultato è analogo: il sistema resta dipendente da una configurazione fragile e non uniforme.

5. Protected Users che fanno emergere il problema al primo colpo

Cos'è il gruppo Protected Users

Protected Users è un gruppo di sicurezza in Active Directory introdotto da Microsoft per aumentare la protezione degli account privilegiati o critici. Microsoft documenta che i membri di questo gruppo sono soggetti a restrizioni rigorose e non configurabili su come possono autenticarsi. 4 5

Le restrizioni principali per i membri di Protected Users sono:

• Niente NTLM: l'account non può autenticarsi con NTLM, NTLMv2, Digest o altre forme deboli di autenticazione.
• Kerberos con AES: deve usare Kerberos e DEVE supportare AES-CTS-HMAC-SHA1-96 o AES256-CTS-HMAC-SHA1-96. Non sono permessi RC4, DES o algoritmi deboli.
• No delega Kerberos: non può essere oggetto di delega unconstrained o constrained.
• TGT più breve: la durata del ticket concesso dal KDC è ridotta.
• Richiesta di pre-autenticazione Kerberos: è obbligatoria, il che rende il ticket più difficile da ottenere illegalmente.

Queste limitazioni sono assolute e non by-passabili. Non esistono workaround, non ci sono eccezioni, non ci sono registry key per aggirare il vincolo.

Quando usare Protected Users

Protected Users è utile principalmente in due scenari:

1. Fase di test e validazione: aggiungi un account di test al gruppo per scoprire immediatamente quali servizi, applicazioni o alias di rete dipendono da NTLM o da Kerberos configurato male. È il modo più diretto per fare "stress test" della tua infrastruttura Kerberos.

2. Account critici che possono permettersi una migrazione controllata: account amministrativi di dominio, account di backup, account di security monitoring. Se l'account è importante ma puoi gestire un fallimento durante una finestra di test, Protected Users è ottimo.

Quando NON usare Protected Users

Microsoft avverte esplicitamente contro l'uso di Protected Users in certi contesti:

• Account di servizio: non aggiungere account di servizio a Protected Users senza test approfonditi. Se il servizio non è configurato correttamente per Kerberos, l'intero servizio smette di funzionare.
• Account computer: i computer account raramente vanno in Protected Users perché le protezioni locali non hanno senso per le macchine.
• Account di servizio gestiti (MSA) o account virtuali: se usi MSA o virtual account, il test deve essere ancora più severo prima di aggiungere Protected Users.
• Bulk addition: non aggiungere in massa account al gruppo senza test caso per caso. Le restrizioni non hanno workaround e possono causare lockout totali.
• Ambienti con dipendenze legacy sconosciute: se non hai una mappa completa di chi accede a cosa e come, Protected Users rischia di bloccare percorsi critici.

Perché NTLM non è disponibile (e questo è il punto)

Quando un account è membro di Protected Users, il sistema operativo lo applica in questo modo:

1. Il client tenta Kerberos: il client Windows attiva il percorso Kerberos e genera un ticket request.
2. Il KDC valida i vincoli Protected Users: il Domain Controller verifica che l'account sia membro del gruppo e applica le restrizioni.
3. NTLM è esplicitamente bloccato: se per qualsiasi motivo Kerberos non riesce (SPN mancante, IP usato invece di FQDN, account di servizio non allineato), il sistema non ricade su NTLM. Il fallback è disabilitato completamente. 4

Il messaggio di errore che vedrai è solitamente cryptico: "The referenced account is a member of the Protected Users group in Active Directory Domain Services. Your computer cannot use Kerberos to authenticate to it." Oppure l'applicazione vedrà semplicemente un errore di autenticazione senza dire il motivo.

Quali servizi si rompono e perché

Quando aggiungi un account a Protected Users, questi servizi spesso iniziano a fallire:

SQL Server con account di servizio in Protected Users:

• Se lo SPN è registrato male o se i client si connettono via IP, la connessione fallisce immediatamente.
• NTLM non è disponibile come fallback, quindi non c'è tolleranza.
• Il log di SQL Server registra un errore di autenticazione.

IIS e applicazioni web con app pool account in Protected Users:

• Se il CNAME o l'alias non corrisponde all'SPN, i client (browser, API caller) non riescono ad autenticarsi.
• Kerberos delegation non funziona, il che causa problemi soprattutto su applicazioni multi-tier.
• I client Windows vedono spesso un errore 401 (Unauthorized) anche se le credenziali sono corrette.

Servizi di backup e replicazione (SQL replication, DFS, Backup Exec, Commvault):

• Questi servizi spesso usano account di servizio con SPN complessi o con configurazioni legacy.
• Con Protected Users, il fallback a NTLM viene bloccato e il servizio smette di comunicare con il target.

File sharing e SMB (file server, Hyper-V live migration, replica storage):

• Se l'account di servizio è in Protected Users e il file server non ha lo SPN corretto registrato, l'accesso fallisce.
• Non è permesso scaricare il livello di autenticazione a un protocollo più debole.

Servizi di integrazione e middleware (SAP connectors, Oracle database links, JEE application servers):

• Molti di questi servizi sono stati scritti quando Kerberos non era ben supportato e dependono da NTLM.
• Con Protected Users, il fallback viene tolto e il servizio scopre che non ha mai funzionato davvero con Kerberos.

Come avviene l'impatto operativo

L'impatto di aggiungere un account a Protected Users è immediato e totale:

1. Fase 0 - Nulla cambia finché l'account non è in Protected Users: il servizio funziona normalmente, probabilmente usando NTLM come fallback silenzioso.

2. Fase 1 - Aggiungi l'account a Protected Users: cambio effettuato, il gruppo si replica in pochi minuti nei DC.

3. Fase 2 - Primo tentativo di connessione (entro pochi minuti): il client tenta di autenticarsi, il KDC verifica che l'account sia in Protected Users, applica le restrizioni, e blocca NTLM.

   • Se Kerberos funziona → autenticazione OK, niente cambia per l'utente.
   • Se Kerberos non funziona → autenticazione fallisce, il servizio è down.

4. Non c'è "quasi funzionante": o Kerberos funziona completamente, o il servizio è completamente bloccato. Non ci sono gradi intermedi.

Come testare Protected Users in modo controllato

Il modo corretto per usare Protected Users come strumento di validazione è questo:

1. Crea un test account non critico (esempio: TEST_KERB_VALIDATION) in una OU isolata.

2. Assegna al test account gli stessi SPN e privilegi che avrebbero un account reale (per esempio, se vuoi testare SQL Server, registra lo stesso SPN).

3. Aggiungi il test account a Protected Users.

4. Prova a usare i servizi che dipendono da quell'account:

   # Esempio: testa SQL Server
   runas /user:domain\TEST_KERB_VALIDATION cmd.exe
   # Poi da quel prompt: sqlcmd -S server.domain.com -E
   

5. Se fallisce, registra l'errore esatto:

   • Controlla che lo SPN sia registrato correttamente
   • Verifica che il client usi il nome coerente con l'SPN
   • Controlla che l'account di servizio supporti i giusti algoritmi Kerberos

6. Dopo il test, rimuovi l'account da Protected Users:

   Remove-ADGroupMember -Identity "Protected Users" -Members TEST_KERB_VALIDATION
   

Non è invasivo, non blocca il vero servizio, e ti da tutta l'informazione di cui hai bisogno.

Perché Protected Users è il test migliore per il fallback Kerberos-to-NTLM

In breve: Protected Users è il modo più diretto per scoprire dove il tuo ambiente sta ancora dipendendo da NTLM per mascherare problemi Kerberos.

Senza Protected Users, un servizio continua a "funzionare" ma in realtà sta usando NTLM come paracadute invisibile. Con Protected Users, il paracadute è tolto e vedi esattamente cosa non era configurato bene. Per questo motivo, se vuoi fare un hardening serio di Kerberos in ambienti enterprise, Protected Users non è una misura di sicurezza aggiuntiva: è uno strumento di auditing fondamentale. 4 5

---

Come capire se stai ancora usando NTLM

Microsoft mette a disposizione auditing dedicato sia a livello di domain controller sia a livello di server membro.

Per i domain controller, la policy "Network security: Restrict NTLM: Audit NTLM authentication in this domain" consente di vedere il traffico NTLM senza bloccarlo. Per i server membri, la policy "Network security: Restrict NTLM: Audit incoming NTLM traffic" svolge lo stesso ruolo sul traffico in ingresso. La raccomandazione di Microsoft è esplicita: prima audit, poi blocco. 8 9

Anche l'Event ID 4776 è utile perché registra le validazioni credenziali effettuate tramite NTLM sui domain controller. Se vuoi capire chi sta ancora cadendo su NTLM, questo è uno dei punti di partenza più semplici. 10

Se l'obiettivo è trovare gli ultimi residui di NTLMv1, Microsoft documenta anche l'uso di Event ID 4624 con il campo Package Name (NTLM only) per identificare NTLM V1. Ma per un hardening serio il punto non è solo NTLMv1: è tutto il traffico NTLM che non dovrebbe esistere più. 11

NTLMv1 e NTLMv2: la distinzione che serve davvero

Vale la pena separare i due casi, ma senza cambiare il focus dell'articolo.

NTLMv1 è il residuo più vecchio e più fragile, e Microsoft lo tratta come qualcosa da identificare e rimuovere. NTLMv2 è sicuramente migliore, ma non risolve il problema di fondo: resta comunque un fallback da auditare, ridurre e, dove possibile, eliminare. In altri termini, NTLMv2 non è il punto di arrivo, è solo una fase meno debole del problema.

Se vuoi chiudere bene questo tema in ambienti enterprise, la lettura utile è questa: prima trovi dove Kerberos cade, poi elimini il motivo per cui cade, e solo dopo restringi NTLM. La distinzione NTLMv1/NTLMv2 è importante, ma non deve spostare l'attenzione dal fatto che il vero obiettivo è far funzionare Kerberos senza paracadute.

HOST o FQDN per Kerberos?

Qui il ricordo giusto è: FQDN è la scelta raccomandata.

Per andare in Kerberos non basta un nome qualsiasi: serve che il nome usato dal client corrisponda a uno SPN valido e univoco. In molti casi un nome HOST breve può funzionare, ma solo se l'SPN è registrato in modo coerente per quel nome. Quando vuoi ridurre ambiguità e problemi di alias, FQDN è la forma più affidabile e quella che Microsoft usa come riferimento negli esempi di SPN. L'uso dell'IP, invece, è il caso più problematico perché Windows non tenta Kerberos di default e può cadere su NTLM. 2 3

---

Come eliminare il fallback in modo realistico

La sequenza corretta non è "disabilita tutto e spera". È questa:

1. Auditare dove NTLM è ancora usato. 8 9
2. Correggere le cause tecniche del fallback: SPN, naming, alias, IP, account di servizio, keytab, configurazioni non coerenti. 2 3
3. Validare con account protetti o con profili di test che non possano più usare NTLM. 4 5
4. Restringere NTLM gradualmente solo quando la mappa delle dipendenze è chiara. 8 9

Questa è la parte che spesso manca nei progetti enterprise: non serve solo una policy di blocco, serve un lavoro di ricostruzione delle dipendenze reali.

---

Consigli pratici da applicare subito

• Preferisci sempre FQDN coerenti e evita connessioni via IP quando vuoi Kerberos.
• Verifica e documenta gli SPN dei servizi critici prima di cambiare policy.
• Tratta SQL Server, IIS, file server e appliance legacy come priorità alta, perché sono i punti in cui il fallback tende a restare nascosto più a lungo.
• Usa Protected Users come strumento di diagnosi, non solo come misura di sicurezza.
• Non considerare NTLMv2 come obiettivo finale: è ancora una dipendenza, non una chiusura del problema.
• Per distinguere il fallback NTLM dalla cifratura RC4 nei ticket Kerberos e seguire il rollout Microsoft, consulta la timeline e le fasi della dismissione RC4 in Active Directory.

---

La lezione più utile

Il fallback Kerberos-to-NTLM è importante non perché NTLM "esista ancora", ma perché rivela ciò che Kerberos non sta riuscendo a fare.

Se rimuovi NTLM senza aver prima ripulito SPN, naming, account di servizio e dipendenze legacy, il problema emerge tutto insieme. Se invece usi audit, casi reali e account protetti nel modo giusto, il fallback diventa una lista di remediation concreta e non un'incognita generica.

In breve: il vero obiettivo non è solo spegnere NTLM. È fare in modo che Kerberos funzioni davvero come standard, non come promessa.

---

Hai bisogno di aiuto?

Il fallback Kerberos-to-NTLM è uno di quei problemi che sembra complicato finché non lo metti a fuoco. Se stai affrontando incidenti di autenticazione difficili da tracciare, account bloccati dopo aver abilitato Protected Users, oppure semplicemente vuoi validare che la tua infrastruttura Kerberos sia pronta per l'hardening, spesso bastano poche ore di analisi dei log e delle configurazioni per sbloccare la situazione.

Contattami: sarò felice di aiutarti a navigare SPN, Protected Users, Event ID 4776 e tutto il resto del puzzle.

---