Archiviazione degli hash LM disabilitata in Active Directory

Verificare che l’archiviazione degli hash LM sia disabilitata in Active Directory solleva due domande distinte: Windows è configurato per smettere di creare hash LM delle password e le password interessate sono cambiate da quando tale configurazione è diventata effettiva? Una policy delle password più rigorosa o un’impostazione di rete NTLMv2, da sole, non possono rispondere a entrambe.

Questa guida spiega il controllo di archiviazione di Microsoft, tre verifiche di configurazione documentate e un piano di correzione graduale. Esplicita anche un limite del prodotto: il controllo EtcSec denominato ANSSI_R23_LM_HASH_NOT_DISABLED valuta LmCompatibilityLevel, non NoLMHash. Il suo risultato non è un inventario dei segreti LM archiviati.

Archiviazione degli hash LM in Active Directory: che cosa significa disabilitarla

Microsoft distingue due rappresentazioni delle password: il precedente hash LM e l’hash NT. Possono risiedere nel database locale Security Accounts Manager (SAM) o in Active Directory. La rappresentazione LM è più debole e più vulnerabile al recupero offline delle password. La KB 299656 di Microsoft sulla prevenzione dell’archiviazione degli hash LM descrive la generazione storica di dati LM per password con meno di 15 caratteri.

Questa descrizione storica non dimostra che ogni installazione attuale di Windows crei hash LM per password brevi. Il riferimento Microsoft della policy di archiviazione elenca valori predefiniti effettivi abilitati per i ruoli di sistema nella propria tabella, mentre le voci delle GPO predefinite del dominio e dei controller di dominio non sono definite. Sono valori predefiniti documentati, non osservazioni del vostro dominio.

La policy di archiviazione agisce quando cambia una password. Un account la cui password precede la distribuzione effettiva deve quindi essere incluso in un elenco da esaminare. È una deduzione condizionale basata sul momento in cui agisce la policy: la vecchia password potrebbe avere già evitato dati LM utilizzabili grazie alla lunghezza, alla configurazione precedente o al comportamento del sistema operativo. L’età della password, da sola, non ne dimostra né la presenza né l’assenza.

Questo articolo si concentra sull’archiviazione LM e sul rinnovo. Gli altri indicatori relativi alle password e le dipendenze dei servizi sono trattati in Sicurezza delle password in Active Directory e gestione dei relativi account di servizio. Usate quella guida per l’esame generale degli account; mantenete qui una decisione di chiusura separata per la questione dell’archiviazione.

Come funziona: hash archiviati e risposte di rete sono controlli distinti

La procedura di archiviazione Microsoft documenta NoLMHash come DWORD impostato a 1 sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa per Windows XP e Windows Server 2003. La procedura per Windows 2000 SP2 e successivi utilizza invece una chiave. Queste procedure storiche del registro richiedono un riavvio e differiscono nella gestione della cronologia delle password; non generalizzate i dettagli di eliminazione tra versioni. La KB 299656 descrive inoltre le password di almeno 15 caratteri come capaci di produrre un valore LM inutilizzabile per l’autenticazione. Aumentare la lunghezza minima in una policy non dimostra che una vecchia password sia stata rinnovata. Consultate i metodi Microsoft specifici per versione.

Il valore indipendente LmCompatibilityLevel controlla il comportamento dell’autenticazione di rete. La tabella seguente parafrasa il riferimento Microsoft sul livello di autenticazione LAN Manager. Qui NTLMv1 indica la variante precedente di NTLM nella tabella Microsoft.

Il livello 3 modifica le risposte del client senza imporre il rifiuto lato server del livello 5. Il livello 5 continua a consentire NTLMv2 e non cancella i segreti dei database. Trattate il rafforzamento della rete e la soppressione dell’archiviazione come attività separate.

Guida ANSSI correlata: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. Il controllo di archiviazione LM descritto qui è documentato da Microsoft.

Rilevamento: raccogliere prove di configurazione e rinnovo

I comandi seguenti sono esempi adattati dalla documentazione Microsoft. Non sono stati eseguiti in un ambiente Active Directory di un cliente. Eseguite ogni misura separatamente sul sistema Windows interessato e conservatene identità, data e ora, output ed eventuali errori.

1. Esaminare il valore del controllo di archiviazione

Questo comando combina la sintassi reg query di Microsoft con il percorso e il valore della KB 299656:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Cercate il valore DWORD documentato 0x1 dove si applica la procedura DWORD. La query legge la configurazione locale, non i dati delle password in SAM o AD. Un valore mancante o una query non riuscita richiede un’interpretazione rispetto al sistema operativo e alla policy effettiva. Non dimostra l’esistenza di un hash LM. Microsoft documenta il codice restituito 0 per una query del registro riuscita e 1 per un errore.

2. Esaminare separatamente il valore del controllo di rete

Questo comando utilizza la stessa sintassi di query e la posizione nel registro della policy di autenticazione:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Registratelo in un campo diverso da NoLMHash. Un valore di rete pari a 0x5 non dimostra la soppressione dell’archiviazione o il rinnovo delle password. Mantenere separate le due letture facilita anche l’indagine su un risultato inatteso del collector.

3. Generare il rapporto delle policy del computer

Il riferimento Microsoft di gpresult documenta l’ambito computer e l’output HTML:

gpresult /scope computer /h lm-policy.html

Esaminate il rapporto risultante delle policy del computer insieme alle letture del registro. Microsoft documenta un requisito SysWow64 per i rapporti HTML su ARM64 e requisiti del firewall per i rapporti remoti. L’esempio locale qui sopra evita i parametri di destinazione remota. Un rapporto delle policy fornisce il contesto di configurazione; non esamina gli hash archiviati.

Creare un elenco di candidati senza sovrastimare il segnale

Confrontate le date di rinnovo delle password degli account con le date verificate di distribuzione della policy di archiviazione. Dove le date di distribuzione effettiva differiscono, conservate questa incertezza invece di assegnare una comoda data unica a tutto il dominio. Questo confronto è un metodo di revisione dedotto dal comportamento al cambio successivo, non un rilevatore diretto di LM né un riscontro misurato nel vostro ambiente.

Correzione: disabilitare l’archiviazione e rinnovare le password interessate (Remediation)

1. Identificare le dipendenze e assegnare i responsabili

Prima di modificare qualsiasi cosa, create un elenco con un ambito definito di DC, versioni Windows applicabili e account da esaminare. Aggiungete i sistemi pertinenti con account locali se l’archiviazione SAM locale rientra nella missione. Nominate un responsabile per ogni modifica degli account di servizio e uno per la verifica della distribuzione della policy.

I riferimenti Microsoft su archiviazione e autenticazione descrivono gli effetti di compatibilità sui client precedenti e su alcune applicazioni. Usate tale avvertenza per pianificare test delle dipendenze effettive della vostra infrastruttura. Non dimostra che una particolare applicazione richieda ancora LM. Registrate una dipendenza solo dopo che il responsabile l’ha identificata; evitate di trasformare un timore non verificato in un’eccezione permanente.

2. Abilitare la policy di archiviazione Microsoft

Nelle opzioni di sicurezza del computer, abilitate "Network security: Do not store LAN Manager hash value on next password change". Microsoft la colloca sotto configurazione computer, impostazioni Windows, impostazioni di sicurezza, criteri locali e opzioni di sicurezza. La pagina della policy di archiviazione documenta che questa policy non richiede un riavvio.

Se serve una procedura del registro specifica per versione, usate le istruzioni applicabili della KB 299656, comprese le indicazioni sul backup del registro. La sequenza storica XP/Server 2003 include un riavvio seguito dal cambio della password. Non unite questa sequenza al comportamento distinto relativo al riavvio descritto nella pagina della policy.

3. Confermare la distribuzione effettiva prima di pianificare la chiusura

Ripetete le tre misure di rilevamento su ogni DC interessato e sistema applicabile con account locali. Conservate insieme il rapporto e le letture del registro. Per ogni sistema, registrate una data effettiva verificata oppure indicatela come non risolta.

Non usate la presenza di una sola GPO conforme come criterio di accettazione della distribuzione. L’implementazione del collector descritta più avanti può dare esito conforme quando una qualsiasi GPO inventariata contiene il livello di rete, senza dimostrare la copertura. Il registro della correzione deve quindi identificare quali sistemi sono stati controllati direttamente e quali restano non verificati.

4. Organizzare il rinnovo delle password con i responsabili dei servizi

La guida Microsoft della policy di archiviazione richiede agli utenti di impostare nuove password al successivo accesso al dominio. Pianificate il rinnovo corrispondente degli account dopo che il controllo di archiviazione è diventato effettivo.

Per gli account che non accedono regolarmente, assegnate un’attività esplicita di rinnovo invece di attendere un normale accesso utente. Per gli account di servizio, coordinate servizi dipendenti, attività pianificate e applicazioni tramite i loro responsabili. La sequenza pratica deve identificare l’account, preparare gli aggiornamenti delle dipendenze, eseguire la modifica approvata, testare il servizio e conservarne il risultato. È un piano operativo di distribuzione, non un’affermazione che sia stata eseguita una rotazione di massa.

Un problema correlato del ciclo di vita è spiegato in Fallback Kerberos RC4 e generazione delle chiavi AES dipendente dalla password. La lezione comune per la pianificazione è includere il rinnovo degli account nei progetti di configurazione. La generazione delle chiavi AES e la soppressione di LM restano meccanismi diversi con requisiti di validazione differenti.

5. Gestire il rafforzamento della rete come una modifica autonoma

Selezionate e testate separatamente il livello di rete LAN Manager previsto, usando le indicazioni Microsoft sulla compatibilità. Non considerate una distribuzione riuscita del livello 5 come la chiusura della pulizia dell’archiviazione LM.

Mantenete la negoziazione NTLMv1, le protezioni contro il relay, l’esposizione in memoria di WDigest e le restrizioni NTLM in uscita di Tier 0 nelle attività già esistenti. Ripetere questi progetti qui nasconderebbe il risultato mancante: una distribuzione documentata della policy di archiviazione seguita dal rinnovo degli account nell’ambito definito.

Validazione: chiudere la revisione con un registro di prove dall’ambito definito

Usate un registro di chiusura che un secondo amministratore possa comprendere senza ricostruire il progetto da conversazioni o schermate. Quello seguente è un formato suggerito per le prove, non uno schema di output Windows né un’attestazione che siano stati esaminati i segreti.

Descrivete la conclusione al livello supportato dalle prove. Per esempio, un registro può stabilire che l’impostazione di archiviazione prevista è stata verificata sui DC elencati e che gli account elencati sono stati rinnovati in seguito. Non deve estendere tale affermazione ad account non esaminati, alla cronologia delle password di tutte le versioni Windows o a un inventario di tutti i segreti archiviati.

Ripetete i controlli di configurazione dopo la modifica e riconciliate eventuali sistemi o account ancora in sospeso. Mantenete visibili le prove incomplete: un DC irraggiungibile, un servizio non testato o una data di rinnovo sconosciuta devono avere un responsabile e una prossima azione.

Come EtcSec rileva questa situazione

Il codice attuale di etc-collector fornisce due controlli correlati delle policy di rete. Nessuno legge NoLMHash o inventaria i segreti LM in SAM o AD. L’analisi seguente è una revisione statica del codice al commit del collector b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; non è il risultato di una scansione di un cliente.

ANSSI_R23_LM_HASH_NOT_DISABLED

Nonostante l’identificatore storico e l’etichetta del catalogo riferita all’archiviazione, questo rilevatore valuta LmCompatibilityLevel. In internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17, il ciclo alle righe 30–43 salta policy o impostazioni nil e considera la condizione soddisfatta non appena una qualsiasi GPO inventariata ha un valore definito maggiore o uguale a 5.

Restituisce Count = 0 quando la condizione è soddisfatta e Count = 1 altrimenti, anche con un insieme di policy vuoto o valori mancanti. L’implementazione non calcola la precedenza effettiva delle GPO né dimostra la copertura di ogni DC o OU. Usa inoltre una soglia numerica invece di validare l’intervallo 0–5 documentato da Microsoft: un valore raccolto pari a 6 soddisferebbe il confronto senza diventare un livello Windows documentato.

La condizione decisiva nel codice è:

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

È un estratto formattato delle righe 35–38, non un programma autonomo. Un conteggio pari a zero significa che questa condizione di policy di rete è stata trovata nei dati forniti. Non conferma la soppressione dell’archiviazione, il rinnovo degli account o un rafforzamento completo della rete; il rilevatore non verifica le impostazioni minime di sicurezza delle sessioni NTLM.

NTLMV1_ALLOWED

Il rilevatore vicino in internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 legge lo stesso campo alle righe 32–34. Le righe 37–38 impostano Count = 1 quando il valore selezionato è assente o inferiore a 5; altrimenti il conteggio resta zero.

La selezione è diversa. La funzione ausiliaria internal/audit/helpers/gpo_policy.go:130 cerca prima un valore definito nella policy predefinita dei DC, poi nella policy predefinita del dominio e infine in un’altra policy. È la regola di selezione della funzione, non un calcolo completo della policy risultante Windows.

Di conseguenza, questi controlli possono discordare. In un input ipotetico con una policy predefinita dei DC a 3 e un’altra GPO a 5, il controllo con nome ANSSI restituisce zero mentre NTLMV1_ALLOWED restituisce uno. L’esempio segue la logica del codice; non è stata osservata alcuna configurazione di cliente di questo tipo.