Da NTLM a Kerberos: Guida Pratica di Troubleshooting per Amministratori di Rete e Infrastrutture

Se sei un amministratore di rete o un sysadmin, ti sarai sicuramente scontrato con la necessità di mettere in sicurezza l’autenticazione del tuo dominio Active Directory. Questa guida pratica descrive l’intero percorso logico per diagnosticare, monitorare e forzare il passaggio dal vecchio e insicuro protocollo NTLM v2 al moderno Kerberos, risolvendo anche le problematiche più comuni legate ai NAS e alle cartelle condivise di rete.

NTLM vs Kerberos: Le Differenze Chiave

Molti pensano che l’autenticazione in un dominio Windows sia un meccanismo opaco. In realtà, la differenza tra i due protocolli principali è netta:

• NTLM (NT LAN Manager): Utilizza un meccanismo di Challenge-Response (Sfida-Risposta) diretto client-server. Il server invia una stringa casuale (sfida), il client la cifra con l’hash della password e la restituisce. È un protocollo obsoleto (creato nel 1993), vulnerabile ad attacchi di tipo Pass-the-Hash, Relay e cracking offline. Microsoft lo ha ufficialmente deprecato.
• Kerberos: Utilizza un terzo attore fidato, il KDC (Key Distribution Center) integrato nel Domain Controller. Il client ottiene un ticket iniziale (TGT) e poi richiede ticket di servizio specifici (TGS) per accedere alle singole risorse, supportando nativamente l’autenticazione reciproca e il vero Single Sign-On (SSO). È estremamente più sicuro.

Fonti: https://techcommunity.microsoft.com/blog/windows-itpro-blog/retiring-ntlm-frequently-asked-questions/4550522

https://learn.microsoft.com/it-it/troubleshoot/windows-server/windows-security/audit-domain-controller-ntlmv1

Controlliamo le impostazioni Kerberos del nostro DC

Se navighi nella Group Policy del tuo dominio sotto Account Policies -> Kerberos Policy, potresti vedere tutte le voci impostate su “Not Defined” (Non definito).
Non significa che Kerberos sia spento! Active Directory applica silenziosamente i suoi valori di fabbrica standard, che includono la validità del ticket TGT a 10 ore e la tolleranza massima per la sincronizzazione dell’orologio (Clock Skew) a 5 minuti. Se l’orario tra client, server e DC differisce di oltre 5 minuti, Kerberos fallisce istantaneamente per sicurezza.

Altrimenti puoi abilitarle e mettere i cambi come nell’immagine.

2. Configurazione delle Porte del Firewall (Policy User-to-DC)

Affinché Kerberos funzioni in automatico, i firewall interni e di rete non devono bloccare la comunicazione tra i client e il Domain Controller. Ecco le porte tassative da includere nella policy:

3. Caccia al traffico NTLM tramite il SIEM Wazuh

Anche se la rete è configurata, alcuni client o software potrebbero continuare a usare NTLM in background (ad esempio, se si mappa un’unità di rete usando l’indirizzo IP anziché il nome DNS completo FQDN). Con il SIEM Wazuh possiamo intercettare questo comportamento in tempo reale.

Quando un account effettua un accesso di rete tramite NTLM, il Domain Controller genera l’evento di Windows 4624 (Logon Riuscito) con il pacchetto di autenticazione specifico.

Query di ricerca su Wazuh (Sezione Discover):

Per isolare gli accessi NTLM avvenuti nel dominio, usa la seguente query filtrata:

"4624" AND "NTLM"

Analisi del Log su Wazuh:

All’interno del log JSON raccolto da Wazuh, espandendo i dettagli troverai l’identikit perfetto dell’anomalia:

• win.eventdata.targetUserName: L’utente che sta effettuando l’accesso.
• win.eventdata.targetDomainName: Il dominio (se mostra il nome del PC locale, l’account è fuori dominio; se mostra il nome del dominio, c’è un fallback in corso).
• win.eventdata.ipAddress: L’IP del computer client di origine.
• win.eventdata.authenticationPackageName: Segnerà espressamente NTLM e NTLM V2.

Se noti che utenti reali del dominio generano log NTLM verso il DC o verso un File Server (i server membri delegano la verifica NTLM al DC tramite Pass-Through Authentication), significa che c’è una condivisione di rete configurata male tramite indirizzo IP.

Bonifica Definitiva tramite GPO Dedicata (Il trucco dello Shortcut)

Se hai un NAS (es. Synology o QNAP) integrato nel dominio, e gli utenti vi accedono tramite scorciatoie o collegamenti configurati con l’indirizzo IP (es. \192.168.1.150\condivisione), Windows escluderà a priori Kerberos e userà NTLM.

Per sanare la situazione centralmente, dobbiamo mappare la radice del cluster o del NAS usando il suo nome DNS (FQDN). Tuttavia, Windows non permette di mappare una lettera di unità (es. S:) sulla radice pura di un server (\nas-cluster.azienda.local). Richiede obbligatoriamente una sotto-cartella condivisa.

Per aggirare questo limite e dare agli utenti un punto di accesso Kerberos generale sul Desktop, useremo una GPO dedicata impostata come Shortcut di tipo URL:

Procedura passo-passo:

• Crea una nuova GPO dedicata e collegala alla OU (Unità Organizzativa) dove risiedono i tuoi UTENTI (non i computer!). Nominala ad esempio Shortcut_NAS_Kerberos.

• Modifica la GPO e naviga su: User Configuration -> Preferences -> Windows Settings -> Shortcuts.
• Fai clic destro nel pannello vuoto e seleziona New -> Shortcut.
• Configura i campi esattamente così:
  • Action: Update
  • Name: Archivio Condiviso (o il nome aziendale scelto)
  • Target type: Seleziona URL dal menu a tendina.
  • Location: Seleziona Desktop.
  • Target URL: Inserisci il percorso di rete puro preceduto dal protocollo file: file://nas-cluster.azienda.local
  • Icon file path: Puoi lasciarlo vuoto (Windows userà l’icona di rete standard) oppure inserire shell32.dll con Index 275.

Verifica e Forzatura della Sessione sul Client

Una volta distribuita la GPO, possiamo testarla sulla nostra macchina per assicurarci che il ticket Kerberos venga generato correttamente e che non ci siano vecchie sessioni memorizzate nella cache a falsare i risultati.

• Apri un Prompt dei comandi standard (ATTENZIONE: NON eseguire come Amministratore, altrimenti controllerai la cache del token amministrativo isolato, che risulterà vuota).
• Chiudi cartelle di rete e tutto quello che può essere un collegamento con il server.
• Pulisci la cache dei ticket Kerberos correnti per evitare falsi positivi:klist purge
• Esegui il comando per forzare l’applicazione della nuova Group Policy senza riavviare il PC:gpupdate /force
• Controlla il Desktop: apparirà la nuova icona. Fai doppio clic su di essa per aprire la radice del NAS ed entra all’interno di una sotto-cartella qualsiasi per scatenare lo scambio effettivo dei permessi di rete.

• Torna sul prompt dei comandi e interroga la cache digitando il percorso assoluto (utile se le variabili PATH utente sono corrotte o le hai cambiate): C:\Windows\System32\klist.exe

Il Risultato Perfetto:

Se la configurazione è andata a buon fine, tra i ticket memorizzati nella cache vedrai finalmente apparire il ticket di servizio SMB protetto da Kerberos:

Server: cifs/nas-cluster.azienda.local @ AZIENDA.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
KDC chiamato: DC01.azienda.local

La dicitura cifs/ unita all’algoritmo AES-256 certifica che la tratta di rete verso il tuo storage aziendale è ora protetta secondo i massimi standard moderni. Gli alert NTLM su Wazuh per questa postazione smetteranno immediatamente di apparire, aumentando il livello di sicurezza complessivo dell’intera infrastruttura.

Se hai problemi di configurazione e nell’esecuzione scrivi pure nei commenti saremo felici di aiutarti!