Se in un dominio Active Directory con più controller di dominio ricevi “Your password does not meet the requirements” anche con password lunghe e complesse, questa guida spiega come diagnosticare e risolvere rapidamente la causa: policy in conflitto, replica guasta o filtri esterni.
Panoramica del problema
In ambienti Active Directory di media/grande dimensione (nell’esempio con 13 DC), utenti e perfino amministratori possono imbattersi in un rifiuto sistematico del cambio password: “Your password does not meet the requirements”. Il messaggio compare anche provando password molto lunghe e apparentemente compliant. I criteri “noti” dichiarati sono di solito:
- Lunghezza minima: 8 caratteri
- Complexity: abilitata
- Minimum password age: 0 giorni
Nonostante ciò, il cambio fallisce. Perché? La causa tipica è l’applicazione reale di criteri più restrittivi rispetto a quelli attesi (spesso tramite Fine-Grained Password Policies o filtri di terze parti), oppure replica o GPO disallineati che fanno sì che alcuni DC rifiutino quanto altri accettano.
Come funziona davvero l’enforcement delle password in AD
Prima di agire è utile ricordare alcuni concetti chiave:
- Account Policies a livello di dominio: lunghezza minima, history, età minima, lockout e complexity sono applicate a livello di domain root e solo le GPO linkate al dominio possono influenzare gli account di dominio. GPO su OU o siti non cambiano l’account policy degli utenti di dominio.
- Precedenza tra GPO linkate al dominio: se più GPO impostano Account Policies, vince quella con link order più alto. È buona pratica che una sola GPO (tipicamente Default Domain Policy) definisca questi valori.
- Fine‑Grained Password Policies (FGPP): dai livelli funzionali 2008+ è possibile applicare Password Settings Objects (PSO) a gruppi o utenti specifici, sovrascrivendo i valori del dominio. È il motivo numero uno di “sorprese”.
- Controller di dominio e PDC Emulator: il DC con ruolo FSMO PDC Emulator è riferimento per password, time skew e account policy. In caso di replica problematica, alcuni DC potrebbero “vedere” policy diverse e negare cambi password.
- Complexity nativa: la complessità richiede almeno 3 delle 4 categorie (maiuscole, minuscole, cifre, simboli), lunghezza ≥ min length e nessuna parte del nome utente o del nome completo con più di due caratteri consecutivi.
- Filtri esterni: prodotti di auditing/identity/SSPR possono introdurre DLL (LSA Notification Packages) che applicano regole extra (dizionari “banned passwords”, pattern vietati, ecc.).
Sintomi tipici e falsi positivi
- Utenti che non riescono a cambiare la password anche aumentando fortemente la complessità.
- Amministratori che riescono su un DC ma falliscono da workstation o viceversa (replica/target DC diverso).
- Alcune utenze colpite, altre no (indizio di FGPP applicate selettivamente o gruppi specifici con PSO).
- Messaggi generici ma Event Viewer con codici più informativi (es. tentativi di cambio/ reset 4723/4724 nel Security log).
Soluzioni già suggerite e perché funzionano
Area | Azione consigliata | Scopo |
---|---|---|
Criteri di gruppo (GPO) | Disabilitare temporaneamente “Passwords must meet complexity requirements”; provare il cambio password; in caso di successo, riattivare il criterio | Verificare se il problema dipende dal filtro di complessità |
Aggiornamento GPO | gpupdate /force sui client | Assicurarsi che le workstation ricevano i criteri corretti |
Replica DC | Controllare che tutti i DC abbiano criteri identici e che la replica sia in salute | Evitare conflitti tra GPO disallineati |
Profili utente | Creare un nuovo profilo o riparare la chiave HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList | Escludere profili corrotti lato client |
Client & rete | Aggiornare OS e driver; verificare la connettività verso i DC | Eliminare problemi di rete o software lato client |
Log di sistema | Analizzare Event Viewer su client e DC | Ottenere dettagli addizionali sull’errore |
Check rapido per capire se è un problema di complessità
Il modo più veloce per isolare il problema è un A/B test controllato:
- Disattiva temporaneamente la complessità nella GPO che governa il dominio (o nel PSO pertinente).
- Esegui il cambio password con una stringa semplice ma lunga (es. 20 caratteri alfanumerici).
- Se funziona, la causa è nella regola di complessità (nativa o filtro terzo). Se non funziona, prosegui con replica, FGPP e conflitti GPO.
Nota: effettua il test fuori orario e ripristina subito l’impostazione dopo la verifica. In produzione, coordina con il team Security.
Diagnostica passo‑passo consigliata
Questa procedura logica porta quasi sempre alla causa effettiva:
- Verifica rapida: disabilita la complessità a livello dominio → prova cambio password.
- Sì → problema legato a complessità o a un filtro/DLL personalizzato.
- No → vai al punto successivo.
- Replica GPO/DC: forza gli aggiornamenti.
gpupdate /force repadmin /syncall repadmin /replsummary dcdiag /test:Advertising /v netdom query fsmo nltest /dsgetdc:DOMINIO /pdc
- Controlla FGPP: individua PSO attivi e la policy risultante sull’utente.
Get-ADDefaultDomainPasswordPolicy Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name,Precedence,MinPasswordLength,ComplexityEnabled,PasswordHistoryCount,MinPasswordAge,MaxPasswordAge Get-ADUserResultantPasswordPolicy -Identity
- Esamina filtri di terze parti: cerca DLL registrate come LSA Notification Packages.
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"
Se compaiono nomi non standard (oltre ad eventuali componenti Microsoft), prova a disabilitarli temporaneamente in un ambiente di test o in finestra di manutenzione. - Analizza Event Viewer su DC e client:
- Security: 4723/4724 (tentativo di cambio/reset), 4738 (modifica account), con dettagli dell’errore restituito.
- System/GroupPolicy: 1202 (SCE), 16958 (applicazione policy), errori DFSR/SYSVOL.
- Profili utente / workstation: se il problema tocca poche macchine, ricrea il profilo locale o prova un clean boot. Errore lato client può produrre sintomi simili.
Focus su FGPP: perché battono il Default Domain Policy
Le Fine‑Grained Password Policies (PSO) consentono di impostare lunghezze minime, history e complessità diverse per gruppi/utenti specifici. Dettagli importanti:
- Le PSO sono oggetti in
CN=Password Settings Container,CN=System,DC=...
e si applicano a utenti o gruppi globali. - Se più PSO si applicano allo stesso utente, vince quella con Precedence più bassa (cioè priorità più alta).
- Un’utenza può risultare soggetta a una PSO anche indirettamente (membership in gruppi).
Comandi utili:
# Elenco PSO con parametri principali
Get-ADFineGrainedPasswordPolicy -Filter * |
Format-Table Name,Precedence,MinPasswordLength,PasswordHistoryCount,ComplexityEnabled
Policy effettiva su uno specifico utente
Get-ADUserResultantPasswordPolicy -Identity | Format-List *
Se scopri PSO con requisiti più severi (es. lunghezza 14, history 24, min age 1 giorno), adegua o rimuovi il riferimento al gruppo/utente interessato, oppure allinea Default Domain Policy per coerenza.
Password filter di terze parti: cosa cercare e come testare
Molti prodotti (SSPR, PAM, auditing, “banned password”, MFA) installano DLL che estendono le regole. Indizi e verifiche:
- Controlla
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages
sui DC. È un valore multi-stringa. Ogni voce corrisponde a una DLL in%SystemRoot%\System32
. - Se la prova con complexity disattivata risolve, un filtro esterno potrebbe bloccare pattern “tropo comuni” (es. nomi aziendali, stagioni, varianti di vecchie password, tastierate ripetitive) o imporre lunghezze/dizionari propri.
- In manutenzione, rimuovi temporaneamente la voce sospetta e riavvia il DC interessato per vedere se il cambio va a buon fine. Non lasciare la rimozione come soluzione definitiva senza valutazione Security.
FIPS e Suite‑B: quando la crittografia è troppo esigente
Se nel dominio o sui DC è attivo il criterio System cryptography: Use FIPS compliant algorithms, alcuni protocolli o componenti legacy possono fallire. Non è la causa più comune, ma in ambienti hardenizzati può influire sull’SSPR o su filtri non aggiornati. Verifica il criterio nei template Security Options della GPO applicata ai DC.
Precedenza e “pulizia” delle GPO
Per evitare conflitti:
- Assicurati che una sola GPO definisca le Account Policies di dominio (idealmente la Default Domain Policy).
- Se proprio devi usare un’altra GPO al livello di dominio per account policy, portala al primo posto nel link order e rimuovi le stesse impostazioni dalla DDP per non avere doppioni.
- Ricorda: GPO su OU/Sites non influenzano le account policy di dominio, ma possono impostare policy locali su server membri.
Password history, età e reversibilità
Anche con “Minimum password age = 0”, due fattori possono sorprendere:
- Password History: con history elevata (es. 24) piccole variazioni (es. aggiunta di “!” o inversione di un carattere) potrebbero essere considerate “troppo simili” da filtri avanzati.
- Store password using reversible encryption: abilitazione rara e sconsigliata; in combinazione con policy severe può introdurre comportamenti inattesi. Verifica che sia disabilitata salvo necessità applicative specifiche.
Replica, SYSVOL e salute dei DC
Se la replica è in sofferenza, alcuni DC applicheranno policy datate e rifiuteranno password che altri accetterebbero. Checklist:
repadmin /replsummary
repadmin /showrepl * /csv > repl.csv
dcdiag /test:SysVolCheck /test:Advertising /v
Get-ADReplicationFailure -Scope Site -Target * | Ft Server,FirstFailureTime,Partner
Verifica anche lo stato di SYSVOL (DFSR) e la presenza di errori in Applications and Services Logs > DFS Replication sui DC.
Verifiche lato client
- Forza l’aggiornamento GPO:
gpupdate /force
- GPResult:
gpresult /h C:\Temp\gp.html
per analizzare le policy applicate alla macchina/utente. - Test da più percorsi: prova il cambio password da Ctrl+Alt+Del, da ADUC, da
net user <utente> * /domain
e via PowerShell/RSAT. Se funziona solo da un canale, individua il DC target di quella specifica operazione. - Connettività: verifica DNS (il client deve risolvere i DC del dominio), porte RPC/Kerberos aperte, assenza di proxy interferenti.
Comandi rapidi di diagnostica
# Impostazioni effettive del dominio
Get-ADDefaultDomainPasswordPolicy
Test replica DC
repadmin /replsummary
FGPP applicate a uno specifico utente
Get-ADUserResultantPasswordPolicy -Identity
Playbook operativo
- Conferma i valori effettivi su dominio e su utente target (DefaultDomainPolicy + FGPP risultante).
- Verifica PDC Emulator e salute replica (AD + SYSVOL).
- A/B test sulla complessità (off → on) per isolare filtro nativo vs terza parte.
- Individua e disabilita temporaneamente eventuali Notification Packages non Microsoft in finestra controllata.
- Riallinea GPO rimuovendo duplicazioni; una sola GPO deve definire Account Policies a livello di dominio.
- Raccolta evidenze: esporta log di Security (4723/4724) e di sistema (1202, 16958), screenshot delle impostazioni e output dei comandi.
Tabella di riferimento rapido
Obiettivo | Comando/Strumento | Output atteso |
---|---|---|
Vedere account policy del dominio | Get-ADDefaultDomainPasswordPolicy | Min/Max age, Min length, History, Complexity |
Elenco PSO | Get-ADFineGrainedPasswordPolicy -Filter * | PSO con Precedence, Min length, Complexity |
Policy effettiva su utente | Get-ADUserResultantPasswordPolicy -Identity U | Policy finale applicata a U |
Replica AD | repadmin /replsummary | 0 errori, latenze nella norma |
Stato SYSVOL | dcdiag /test:SysVolCheck | Passed |
Ruoli FSMO | netdom query fsmo | Individua PDC Emulator |
GPO applicate | gpresult /h gp.html | Report HTML dettagliato |
Filtri LSA presenti | reg query ...\Lsa /v "Notification Packages" | Elenco DLL notifiche |
Casi tipici e come si risolvono
FGPP dimenticata su un gruppo “VIP”
Un gruppo di dirigenti aveva una PSO storica con MinPasswordLength=14 e MinPasswordAge=1 giorno. Gli utenti provavano ripetutamente il cambio nel giro di pochi minuti ricevendo l’errore. Soluzione: ridurre MinPasswordAge o rimuovere l’associazione del gruppo alla PSO; comunicare le nuove regole.
Filtro di terze parti con dizionario aziendale
Un password filter vietava qualsiasi riferimento al nome dell’azienda e a parole del settore. Molte password “creative” contenevano suffissi o varianti di quei termini. Soluzione: aggiornare il dizionario del filtro, rilasciare linee guida agli utenti e, in emergenza, disabilitare temporaneamente il filtro durante la rotazione massiva.
Replica SYSVOL rotta su tre DC remoti
Alcuni DC remoti non ricevevano aggiornamenti della GPO. Gli utenti di quelle sedi non potevano cambiare password secondo le nuove regole. Soluzione: riparare DFSR, forzare repadmin /syncall
, verificare dcdiag
e allineare SYSVOL; a valle, tutto ok.
Linee guida per una password “buona” che evita i filtri
- Lunghezza ≥ 14 caratteri (meglio 16+), combinando lettere, numeri e simboli.
- Niente riferimenti a nome utente, nome completo, azienda, prodotti, città, stagioni, anni correnti o pattern tastiera (es. Qwerty, 1234).
- Frase segreta con separatori (es. “Gatto!Corsa=Caffè19”) spesso supera anche filtri severi.
Mitigazioni di emergenza
Se devi sbloccare utenti rapidamente senza compromettere la sicurezza:
- Allinea i DC (replica) prima di toccare i criteri.
- Riduci temporaneamente la MinPasswordAge nella PSO/Domain Policy per autorizzare cambi ravvicinati; ripristina subito dopo.
- Comunica una password recipe chiara agli utenti (esempi ammessi/vietati).
Checklist finale prima di chiudere l’incidente
- Replica AD e SYSVOL senza errori per almeno un ciclo completo.
- Una sola GPO definisce Account Policies al livello di dominio; documentata e approvata.
- Elenco PSO aggiornato con proprietari e scopo; Precedence verificata.
- Password filter di terze parti inventariati; policy di gestione e change control definiti.
- Event log pulito (nessun 1202/16958 ricorrente, nessun 4723/4724 fallito anomalo).
Domande frequenti
Disattivare la complessità è sicuro?
No in modo permanente. Usalo solo come test di isolamento per pochi minuti, in finestra protetta, e ripristina immediatamente.
Perché alcuni utenti sono colpiti e altri no?
Spesso perché una FGPP si applica solo a un gruppo/OU specifico o perché un filtro controlla parole legate al ruolo/ufficio.
Il reset password da parte dell’amministratore “bypassa” i controlli?
Può aggirare alcuni vincoli temporali, ma i filtri di complessità (nativi o terzi) possono comunque bloccare la password proposta. Non è una soluzione strutturale.
La policy nel “Default Domain Controllers Policy” influenza gli utenti?
No: quella GPO regola i DC. Le account policy per gli utenti di dominio arrivano dalle GPO linkate al domain root o dalle FGPP.
Modello di procedura operativa standard
- Rilevazione: ticket con errore “Your password does not meet the requirements”.
- Classificazione: plateale (più sedi/utenti) → ~probabile replica/GPO; settoriale (alcuni gruppi) → ~probabile FGPP/filtro.
- Diagnosi: comandi indicati; controllo PDC; Event Viewer.
- Contenimento: riduzione temporanea vincoli temporali; comunicazione agli utenti; change window.
- Eradicazione: fix per GPO/FGPP/filtro; riparazione replica.
- Recupero: verifica fine‑fine; test da sedi diverse; monitoraggio log 24–48 ore.
- Lezione appresa: documentazione definitiva, ownership PSO, processo change.
Riepilogo operativo
- Se disattivare la complessità sblocca il cambio ⇒ indaga filtri/PSO e linee guida password.
- Se non sblocca ⇒ controlla replica, SYSVOL, PDC, conflitti GPO e applicazione della policy risultante.
- FGPP e password filter sono i maggiori responsabili delle discrepanze rispetto ai parametri “noti”.
Esempi di comandi PowerShell utili
# Report completo policy dominio
$dom = Get-ADDomain
$pol = Get-ADDefaultDomainPasswordPolicy
[PSCustomObject]@{
Domain = $dom.DNSRoot
MinLength = $pol.MinPasswordLength
Complexity = $pol.ComplexityEnabled
History = $pol.PasswordHistoryCount
MinAge = $pol.MinPasswordAge
MaxAge = $pol.MaxPasswordAge
} | Format-List
Report PSO con precedence
Get-ADFineGrainedPasswordPolicy -Filter * |
Sort-Object Precedence |
Select Name,Precedence,MinPasswordLength,PasswordHistoryCount,MinPasswordAge,ComplexityEnabled |
Format-Table -Auto
Utente: policy risultante
Get-ADUserResultantPasswordPolicy -Identity | Format-List *
Conclusioni
Quando il cambio password fallisce con “Your password does not meet the requirements”, non è quasi mai un problema della singola password, ma della policy effettiva applicata o della replica. Seguendo il percorso: test complessità → replica → FGPP → filtri → log, individuerai la causa vera e ripristinerai rapidamente il funzionamento. Mantieni le policy centralizzate, documenta le PSO con precedenza chiara, monitora la replica e governa con rigore i filtri di terze parti: è la ricetta per evitare che l’errore si ripresenti.
Appendice: informazioni supplementari utili
- FGPP: nei domini con livello funzionale 2008+, PSO possono sovrascrivere il Default Domain Policy (usa
Get-ADFineGrainedPasswordPolicy
eGet-ADUserResultantPasswordPolicy
). - Password Filter di terze parti: controlla
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages
. - FIPS/Suite‑B: verifica “System cryptography: Use FIPS compliant algorithms” sui DC.
- Precedenza GPO: accertati che la GPO che imposta le account policy al dominio sia unica e prioritaria.
- Password History e Reversibilità: attenzione a history elevata e a “Store password using reversible encryption”.
- Comandi rapidi:
Get-ADDefaultDomainPasswordPolicy repadmin /replsummary Get-ADUserResultantPasswordPolicy -Identity <SAMAccountName>
Procedura consigliata riassunta
- Disabilita temporaneamente la complessità → prova → esito guida la diagnosi.
- Forza replica e GPO (
gpupdate /force
,repadmin /syncall
), quindi riprova. - Controlla/elimina/correggi FGPP in conflitto.
- Isola filtri terzi; disabilita temporaneamente in finestra controllata.
- Event Viewer: cerca 1202/16958, 4723/4724, errori DFSR.
- Se ristretto a poche macchine: profilo locale o clean boot.