Criteri password AD: perché i controlli ANSSI e CIS differiscono

Che cos’è la conformità dei criteri password AD?

La conformità dei criteri password AD dipende dalla regola precisa che viene valutata. Un dominio può soddisfare i criteri numerici citati per il controllo ANSSI dei criteri password di EtcSec e fallire comunque il controllo CIS sulla stessa configurazione. I controlli leggono attributi in parte comuni, ma applicano soglie diverse e coprono impostazioni differenti.

La domanda utile è quindi: quale attributo non ha superato il controllo, rispetto a quale riferimento documentato e con quale versione del rilevatore? Un risultato etichettato ANSSI o CIS dovrebbe condurre a queste prove. Da solo, non può stabilire la conformità a un’intera pubblicazione.

Questo confronto distingue i due predicati dei rilevatori documentati in una revisione del collector di settembre 2026 dalle raccomandazioni sottostanti. Il confronto documentale utilizza CIS Microsoft Windows Server 2012 R2 Benchmark v2.2.0, datato 28 aprile 2016, sezioni 1.1 e 1.2. Si tratta di un’edizione storica. Il catalogo CIS attuale elenca Server 2022 v5.1.0, che non è stato letto per questo articolo.

La nostra guida pratica ANSSI per Active Directory spiega perché un programma di sicurezza AD richiede un insieme definito di documenti complementari, anziché una dichiarazione di conformità basata su un solo PDF.

In cosa differiscono i controlli ANSSI e CIS

La tabella seguente distingue le raccomandazioni delle fonti dalle condizioni citate per Detect(). I valori descrivono la configurazione che soddisfa le condizioni numeriche citate, anziché le espressioni di fallimento stesse.

La revisione del collector cita ad/compliance/anssi/r1-password-policy.go e ad/compliance/cis/password-policy.go. I file Go completi non erano disponibili per questo confronto. La tabella consente quindi di trarre conclusioni su questi estratti; non dimostra i rami non citati, la gestione degli errori o la copertura dei dati di raccolta mancanti.

Le fonti delle colonne documentali sono ANSSI-PG-078 e il PDF storico CIS Server 2012 R2 v2.2.0. Le colonne dei rilevatori derivano dai predicati citati riprodotti di seguito. Sono soglie di implementazione, non un’attribuzione di ogni numero ad ANSSI. Le differenze di 60/365 giorni e di 10/5 tentativi mostrano anche perché una dichiarazione riferita a un documento debba specificarne l’edizione.

La complessità è una questione distinta

Microsoft definisce pwdProperties come un campo di bit dei criteri di dominio relativo alla complessità e alle restrizioni di archiviazione. Il suo flag DOMAIN_PASSWORD_COMPLEX ha valore 1. Esaminare lunghezza, cronologia e durata non consente di stabilire lo stato di quel flag.

Una valutazione completa deve quindi registrare esplicitamente la complessità. Gli estratti forniti per questi due controlli non mostrano una condizione di complessità. È un limite delle prove di implementazione disponibili, non una prova che i rilevatori completi la ignorino. Non trasformate un campo non documentato in un esito positivo presunto.

Casi in cui i risultati divergono

Questi esempi sono configurazioni ipotetiche valutate rispetto ai predicati numerici citati. Non sono risultati di un ambiente cliente né di un’esecuzione reale del collector. Per questi esempi, si presume che le durate siano espresse in giorni, che l’assenza di scadenza sia rappresentata da maxPwdAge == 0 e che gli altri campi contengano valori validi. Queste ipotesi corrispondono ai confronti citati; la conversione dei valori della directory da parte del collector non è stata verificata.

Ogni riga isola una ragione del disaccordo. Criteri reali possono non soddisfare più condizioni contemporaneamente, quindi conservate tutti gli attributi che falliscono invece di segnalare soltanto il primo incontrato. Questo rende preciso il piano di correzione: un problema di cronologia richiede una modifica alla cronologia, mentre un problema di durata richiede una decisione esplicita sulla scadenza.

Può accadere il contrario?

Per questi predicati citati sugli stessi input validi, soddisfare le condizioni numeriche CIS implica soddisfare le condizioni numeriche ANSSI. Una lunghezza minima di 14 soddisfa anche 12; una cronologia di 24 soddisfa 12; una soglia di blocco compresa tra 1 e 5 rientra anche tra 1 e 10. Le condizioni di durata proprie del CIS aggiungono requisiti senza attenuare quelli condivisi.

Non esiste quindi un esempio dimostrato di esito positivo CIS ed esito negativo ANSSI per questa coppia di estratti. Se un audit segnala questa combinazione, confrontate i valori raccolti, la versione del rilevatore e i dettagli completi del rilievo prima di spiegarla come una differenza tra standard. Input, implementazioni o ambiti di audit diversi richiedono prove proprie.

Nemmeno l’ultima riga stabilisce la conformità completa al benchmark. Dice soltanto che questi cinque input numerici soddisfano le espressioni citate. La complessità rimane una verifica distinta e un benchmark completo contiene controlli aggiuntivi.

Rilevamento: leggere i criteri password predefiniti del dominio

Utilizzate il modulo PowerShell di Active Directory per raccogliere i criteri predefiniti del dominio. Sostituite il dominio di esempio con quello in esame:

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' |
    Select-Object DistinguishedName, MinPasswordLength, PasswordHistoryCount,
        LockoutThreshold, MaxPasswordAge, MinPasswordAge, ComplexityEnabled

Si tratta di una sola pipeline in lettura basata sulla documentazione Microsoft di Get-ADDefaultDomainPasswordPolicy. Non è stata eseguita su un dominio reale per questo articolo.

Leggete l’output come prova per un dominio e un momento di raccolta specifici. Conservate il nome distinto insieme ai valori, così una revisione successiva potrà determinare se i due risultati di audit descrivono davvero gli stessi criteri. Non confrontate un’impostazione GPO ricordata con un risultato recente del collector presumendo che abbiano input identici.

MinPasswordLength è un numero di caratteri. PasswordHistoryCount corrisponde al numero di password conservate; la pagina dello schema pwdHistoryLength di Microsoft documenta l’attributo della directory. Le proprietà relative alla durata sono intervalli temporali, mentre lunghezza, cronologia e soglia di blocco sono conteggi. Mantenete esplicite queste unità quando trasferite le prove in un foglio di audit.

Il comando restituisce i criteri predefiniti del dominio. Non stabilisce i criteri effettivi di ogni utente quando si applicano criteri password granulari. Microsoft documenta una query distinta dei criteri password risultanti per gli utenti; non estendete un risultato predefinito del dominio a una dichiarazione di conformità per ogni account.

Correzione e hardening: modificare l’attributo che fallisce rispetto a un riferimento identificato

Decidete prima quale riferimento e quale edizione governano la modifica. Documentate l’esito richiesto, poi modificate gli attributi che non lo soddisfano. Un’impostazione che elimina un rilievo può lasciarne un altro intatto, come mostra la tabella di esempi.

Per un esempio che soddisfi entrambi i predicati numerici citati e i criteri numerici della tabella storica, utilizzate lunghezza 14, cronologia 24, soglia di blocco 5, durata massima 60 giorni e durata minima 1 giorno. Il valore di 60 giorni proviene dalla sezione storica CIS 1.1.2; la scelta più restrittiva di 5 tentativi proviene dall’estratto del rilevatore CIS. Abilitate la complessità per il criterio di complessità distinto del documento citato. È un esempio di confronto, non una raccomandazione di adottare oggi un benchmark storico.

Il seguente esempio di configurazione utilizza parametri documentati da Microsoft per Set-ADDefaultDomainPasswordPolicy:

Set-ADDefaultDomainPasswordPolicy -Identity 'example.com' `
    -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 5 `
    -MaxPasswordAge '60.00:00:00' -MinPasswordAge '1.00:00:00' `
    -ComplexityEnabled $true -WhatIf

-WhatIf mostra un’anteprima dell’operazione proposta senza applicarla. Questo esempio è stato verificato rispetto alla documentazione; non è stato eseguito in un dominio reale. Un amministratore dovrebbe testare la modifica prevista, applicarla attraverso il processo aziendale di gestione dei criteri e ripetere la query in sola lettura riportata sopra. Un’anteprima non è un risultato di correzione riuscita.

Decidere deliberatamente la scadenza

ANSSI-PG-078 R24 sconsiglia la scadenza predefinita per gli account non sensibili quando password robuste e sistemi di supporto lo consentono; R25 mantiene la scadenza per gli account privilegiati. Il testo precedente favorisce l’autenticazione a due fattori per questi account e tratta la scadenza quando si utilizza un’autenticazione basata soltanto sulla password. Questa distinzione tra account non può essere stabilita da un unico valore di durata per l’intero dominio. L’assenza di un rilievo sulla durata del rilevatore ANSSI non convalida tutti i criteri di scadenza.

Se il riferimento scelto richiede una durata massima diversa da zero, mantenete questo requisito o documentate l’eccezione attraverso il processo di audit. Eliminare un rilievo dalla dashboard e giustificare un’eccezione sono esiti diversi; registrate quale avete ottenuto.

Verificare la modifica e l’esposizione residua

Conservate l’output dei criteri prima e dopo la modifica, l’edizione del riferimento e il motivo di ogni attributo modificato. Eseguite di nuovo entrambi i controlli sulla stessa raccolta recente ed esaminate singolarmente i rilievi rimasti. Se la configurazione è cambiata ma il rilievo no, riconciliate il momento di raccolta e i valori segnalati prima di modificare nuovamente i criteri.

La conformità dei criteri password richiede anche un contesto operativo. Il nostro articolo sul password spraying spiega come pochi tentativi distribuiti tra molti account possano evitare blocchi evidenti per singolo account e perché la mitigazione combini controlli password, autenticazione più robusta e monitoraggio correlato. Superare un controllo della soglia di blocco non dovrebbe essere usato come prova che lo spraying sia stato eliminato.

Come EtcSec rileva questi problemi

Il catalogo del sito contiene sia ANSSI_R1_PASSWORD_POLICY sia CIS_PASSWORD_POLICY. La revisione del collector fornisce le seguenti condizioni di fallimento per le rispettive implementazioni di Detect():

ANSSI_R1_PASSWORD_POLICY
ad/compliance/anssi/r1-password-policy.go
minPwdLength < 12 OR pwdHistoryLength < 12
OR lockoutThreshold == 0 OR lockoutThreshold > 10

CIS_PASSWORD_POLICY
ad/compliance/cis/password-policy.go
minPwdLength < 14 OR pwdHistoryLength < 24
OR maxPwdAge > 365 OR maxPwdAge == 0
OR minPwdAge < 1 OR lockoutThreshold > 5 OR lockoutThreshold == 0

Le soglie di durata riportate sopra sono espresse in giorni per questo confronto, coerentemente con l’esempio maxAge=120j della revisione (riga 127). Gli estratti non stabiliscono come il collector converta gli intervalli LDAP grezzi o rappresenti i criteri senza scadenza. Spiegano perché gli stessi criteri possano produrre rilievi diversi e perché ogni rilievo debba indicare l’attributo che fallisce.

La prova di implementazione è la revisione del collector in docs/research/ad/2026-09-13-ad-catalogue-gap-diff.md, righe 123 e 124 rispettivamente. Queste righe citano i file Go indicati; i numeri di riga del codice Go non erano disponibili. I file sorgente completi non erano disponibili in questa revisione. La copertura della complessità, il comportamento in caso di dati mancanti e ogni altro ramo non citato rimangono non verificati. Questi rilievi sono segnali di configurazione utili; i loro nomi non trasformano un predicato parziale in una valutazione ANSSI o CIS completa.

Riferimenti primari

• ANSSI: Recommandations de sécurité relatives à Active Directory, DAT-NT-17 v1.1, 10 settembre 2014; R1, pagina stampata 8.
• ANSSI: raccomandazioni su autenticazione e password, ANSSI-PG-078 v2.0, 8 ottobre 2021; R10 e R21–R25.
• CIS: catalogo dei benchmark Microsoft Windows Server e selezione dell’edizione. Confronto storico: Server 2012 R2 v2.2.0, 28 aprile 2016; sezioni 1.1.1–1.1.5 e 1.2.2, PDF collegato sopra. Server 2022 v5.1.0 non è stato letto.