Windows Server 2025 / Configurare password e blocco account con i FGPP

In Windows Server 2025, i criteri granulari per le password (Fine-Grained Password Policies, FGPP) consentono di assegnare requisiti di password e blocco diversi a utenti o gruppi specifici dello stesso dominio. In questa esercitazione si assegna un oggetto impostazioni password (Password Settings Object, PSO) al solo gruppo di laboratorio e si verifica il criterio effettivo, lasciando invariato quello predefinito del dominio. Un normale oggetto Criteri di gruppo (Group Policy Object, GPO) collegato a un'unità organizzativa (OU) di utenti non crea un criterio di password di dominio distinto per quella OU.

Distinguere criterio predefinito e criteri granulari

I FGPP si applicano agli oggetti utente e ai gruppi di sicurezza globali, non direttamente alle OU, come spiega la guida Microsoft ai criteri granulari per le password. Occorrono il modulo Active Directory (AD) di Windows PowerShell su DC1 o un PC di gestione con gli strumenti di amministrazione remota del server (RSAT), e autorizzazioni AD adeguate: per impostazione predefinita le possiedono i Domain Admins, ma si possono delegare. Essere amministratore locale del PC non basta. Prima delle query verificare che la sessione operi nel dominio di laboratorio ad.example.test, perché i comandi seguenti non specificano un dominio alternativo.

Get-ADDefaultDomainPasswordPolicy
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'
Get-ADFineGrainedPasswordPolicy -Filter *

Il primo comando legge il criterio predefinito del dominio, il secondo il PSO risultante per labuser1 e il terzo elenca i PSO esistenti. Annotare i valori iniziali e le assegnazioni, senza registrare password. Per un utente si determina un solo PSO effettivo: non si combinano i valori più restrittivi di PSO diversi. Un'assegnazione diretta all'utente ha priorità su quelle ottenute tramite gruppi; tra candidati dello stesso tipo prevale il valore Precedence più basso. Perciò 100 non garantisce da solo che questo esempio vinca. Se esistono già assegnazioni o conflitti di nome e precedenza, fermarsi ed esaminarli prima di creare il criterio.

Verificare i destinatari e scegliere i valori di laboratorio

Usare il gruppo GG_LabUsers e l'utente ordinario labuser1 preparati nella lezione sulla creazione di utenti, gruppi e OU. In Utenti e computer di Active Directory (dsa.msc) controllare che il gruppo abbia ambito Globale e tipo Sicurezza, quindi verificare tutti i membri, anche quelli derivanti da gruppi annidati. Procedere soltanto se l'ambito è interamente di laboratorio: se comprende amministratori, account di servizio o utenti reali, interrompere la prova senza modificare i membri di gruppi di produzione. I valori seguenti servono a osservare il comportamento, non costituiscono una configurazione universale consigliata.

L'età minima di 0 giorni facilita cambi ripetuti durante la prova; la durata massima di 30 giorni e la soglia di 5 errori sono anch'esse scelte dimostrative. Non copiarle automaticamente in produzione. La finestra di osservazione non deve superare la durata del blocco: qui entrambe sono di 15 minuti. Le scelte operative dipendono dal rilevamento degli abusi, dall'autenticazione a più fattori (MFA), dai tipi di account e dalle procedure di recupero. Una soglia troppo bassa può facilitare attacchi di negazione del servizio contro gli utenti; lunghezza, complessità e scadenza non descrivono da sole tutta la protezione dell'account.

Creare e assegnare il PSO

Aprire Windows PowerShell con privilegi elevati e con le autorizzazioni AD richieste, dopo aver verificato che Lab-Password-Policy non esista già e che precedenza e destinatari siano corretti. Il blocco definisce i parametri, crea il PSO, assegna il criterio a GG_LabUsers e legge il risultato per labuser1. Eseguire le operazioni per fasi: se la creazione restituisce un errore, fermarsi e non assegnare alla cieca un vecchio oggetto con lo stesso nome. I parametri sono documentati in New-ADFineGrainedPasswordPolicy.

$policyParameters = @{
    Name = 'Lab-Password-Policy'
    Precedence = 100
    MinPasswordLength = 14
    ComplexityEnabled = $true
    PasswordHistoryCount = 5
    MinPasswordAge = (New-TimeSpan -Days 0)
    MaxPasswordAge = (New-TimeSpan -Days 30)
    LockoutThreshold = 5
    LockoutDuration = (New-TimeSpan -Minutes 15)
    LockoutObservationWindow = (New-TimeSpan -Minutes 15)
    ReversibleEncryptionEnabled = $false
}
New-ADFineGrainedPasswordPolicy @policyParameters
Add-ADFineGrainedPasswordPolicySubject -Identity 'Lab-Password-Policy' -Subjects 'GG_LabUsers'
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'

Il risultato atteso per labuser1 è Lab-Password-Policy con Precedence 100, lunghezza minima 14, complessità attiva, cronologia 5, età minima 0 giorni e massima 30 giorni, soglia 5, durata e finestra di osservazione di 15 minuti e crittografia reversibile disattivata. La sola creazione del PSO o la presenza del gruppo tra i destinatari non dimostra che sia il criterio effettivo dell’utente. Se il risultato differisce, controllare appartenenza, altri PSO e replica prima di riprovare; non ripetere la creazione.

In alternativa a PowerShell, aprire il Centro di amministrazione di Active Directory (dsac.exe), selezionare il dominio corretto e seguire Sistema (System) → Contenitore Impostazioni password (Password Settings Container). Nel riquadro Attività scegliere Nuovo → Impostazioni password, indicare Nome Lab-Password-Policy, Precedenza 100 e tutti i valori della tabella. In Si applica direttamente a scegliere Aggiungi, inserire GG_LabUsers e confermare. Selezionare poi labuser1 e usare Visualizza impostazioni password risultanti per verificarne l'effetto. È un percorso alternativo: non ricreare il criterio se è già stato creato con PowerShell.

Verificare il cambio password e interpretare lo stato

Il criterio non allunga né riscrive retroattivamente una password già memorizzata; le condizioni di scadenza possono invece cambiare in base all'età della password. Dopo aver verificato il PSO effettivo, accedere a CLIENT1 con l'account di dominio labuser1, premere Ctrl+Alt+Canc e scegliere Cambia password. In una macchina virtuale inviare la combinazione al sistema ospite tramite i comandi del programma di virtualizzazione. Inserire la password corrente e una nuova password univoca conforme ai requisiti, ripetendola nel campo di conferma; attendere la conferma di riuscita e verificare un successivo accesso normale. Non usare password pubblicate negli esempi e non inserire password in script, log o schermate. Non provocare errori ripetuti per dimostrare il blocco.

Non usare un amministratore o un account di servizio per una prova con password errate. La soglia riguarda gli errori di autenticazione effettivamente conteggiati: un singolo tentativo percepito dall'utente può comportare più richieste, ad esempio per i tentativi dei protocolli o delle applicazioni, come precisa la documentazione della soglia di blocco account. Se labuser1 si blocca inaspettatamente, verificare prima attività pianificate, servizi e connessioni con credenziali obsolete. Da una sessione amministrativa autorizzata si può leggere lo stato senza inserire password:

Get-ADUser -Identity 'labuser1' -Properties LockedOut,PasswordLastSet | Select-Object SamAccountName,LockedOut,PasswordLastSet

LockedOut descrive lo stato rilevato dal controller di dominio interrogato, non la causa del blocco. PasswordLastSet indica quando è stata impostata la password: non rivela il testo della password né dimostra che quella esistente rispetti la complessità attuale. Dopo un cambio riuscito la data dovrebbe riflettere il nuovo evento; interpretarla tenendo conto del controller interrogato, della replica e del contesto temporale.

Uno sblocco non elimina le credenziali obsolete presenti su dispositivi o applicazioni. Identificare l'utente, trovare l'origine degli errori e correggere le credenziali salvate prima di un eventuale sblocco mirato e autorizzato. Non ridurre i requisiti del criterio e non sbloccare indiscriminatamente tutti gli account per superare la prova.

Rimuovere l’assegnazione e verificare il criterio effettivo

Al termine, rimuovere soltanto l’assegnazione del PSO a GG_LabUsers. Controllare l'eventuale richiesta di conferma: l'operazione rimuove il collegamento del destinatario al criterio, senza eliminare il gruppo, gli utenti o il PSO. Leggere quindi di nuovo il risultato per l'utente e il criterio predefinito:

Remove-ADFineGrainedPasswordPolicySubject -Identity 'Lab-Password-Policy' -Subjects 'GG_LabUsers'
Get-ADUserResultantPasswordPolicy -Identity 'labuser1'
Get-ADDefaultDomainPasswordPolicy

Se non esiste un altro PSO applicabile, torna a valere il criterio predefinito del dominio e la query del PSO risultante può non restituire un oggetto. Distinguere questa situazione da un errore di autorizzazione o di query. Se compare un altro PSO, esaminarne l'assegnazione senza eliminarlo soltanto per ottenere un risultato vuoto. Confrontare il criterio predefinito con i valori iniziali: deve essere rimasto invariato. Rimuovere l'assegnazione non ripristina la password precedente; conservare in sicurezza quella nuova e valida. Prima di eliminare il PSO, controllare gli eventuali altri destinatari, oppure lasciarlo non assegnato se verrà riutilizzato.