La nuova gestione delle password e del blocco degli account in Windows Server 2008

Di Rossano Orlandini - MCSE MCSA MVP – Windows Server

In questo secondo articolo della serie introduttiva dedicata a Windows Server 2008, esamineremo le novità introdotte nella gestione delle password e degli account utente nel nuovo sistema operativo server di casa Microsoft.

Uno degli aspetti più frustranti che accompagnano la vita degli amministratori di rete nei domini Active Directory Windows 2000 e Windows 2003 è l’impossibilità di creare diverse policy di sicurezza relative alle caratteristiche delle password di accesso degli utenti, differenziandole per tipologia e gruppi di utilizzo. Non è possibile avere gruppi di utenti con criteri sulle password molto più restrittivi, oppure gruppi di utenti che abbiano criteri sulle password particolari e sincronizzati con altre origini di dati. Al momento è possibile creare una e una sola password policy, specificata nella Default Domain Policy e che si applica all’intero dominio, indistintamente.

In effetti l’interfaccia grafica attuale della Group Policy Management Console è fuorviante. Se proviamo, ad esempio, a creare una nuova password policy a livello di una OU che abbiamo creato nel nostro dominio e che contiene alcuni account utente e alcuni account computer, tutto sembra funzionare per il meglio e non riceviamo alcun messaggio di errore. Ma in realtà non è così. L’unica vera password policy in vigore è quella impostata a livello di dominio. La creazione di una diversa password policy a livello di OU influenza solo gli account utente che accedono localmente alle macchine contenute nella OU in oggetto; non ha alcun effetto sugli account utente che accedono regolarmente al dominio Active Directory.

In Windows Server 2008 è stato finalmente introdotto un metodo, seppur non molto intuitivo, per definire più password policy ed assegnarle a diversi utenti e gruppi di utenti all’interno del dominio.

Il requisito fondamentale per applicare questa nuova funzionalità è avere il livello funzionale del dominio già aggiornato a Windows Server 2008, vale a dire che tutti i domain controller devono avere come sistema operativo Windows Server 2008 e non è possibile avere in linea alcun domain controller con sistema operativo precedente (Windows Server 2003, Windows 2000 Server oppure l’obsoleto Windows NT Server 4.0).

Con il livello funzionale del dominio a Windows Server 2008, vengono introdotte due nuove classi di oggetti nello schema di Active Directory:

• Password Settings Container

• Password Settings Objects

La cartella della classe Password Settings Container (PSC) è creata anche nel container System nello snap-in di Active Directory Users and Computers (visibile attivando la modalità Avanzata) e qui vengono memorizzati gli oggetti Password Settings (PSO) per il dominio. Non è possibile cancellare, spostare o rinominare la cartella Password Settings Container.

Vediamo ora un esempio pratico di come configurare una nuova password policy per un gruppo di utenti presenti nel nostro dominio betadomain.local, già aggiornato al livello funzionale Windows Server 2008.

Attualmente il dominio ha una password policy di questo tipo:

Ora creeremo una nuova password policy (PSO) che, per ragioni di sicurezza, verrà assegnata al solo gruppo IT-Admins e che avrà queste caratteristiche:

Nota

Nota: le nuove password policy possono essere assegnate solamente agli utenti e ai gruppi di protezione. Non è possibile assegnare direttamente una nuova password policy ad un account computer oppure ad una OU.

Innanzitutto andiamo in Administrative Tools e apriamo la console di ADSI Edit. In alto a sinistra, facciamo click di destro su ADSI Edit e scegliamo Connect to...

Nel campo Name inseriamo il nome di dominio in formato FQDN nel quale andremo a creare un nuovo PSO. Nel nostro caso sarà betadomain.local.

Scendiamo quindi nella struttura di ADSI Edit fino a DC=betadomain DC=local, CN=System, CN=Password Settings. Clicchiamo di destro su CN=Password Settings e selezioniamo New / Object...

Nella finestra di creazione dell’oggetto (ossia il nostro PSO), selezioniamo la voce proposta msDS-PasswordSettings e procediamo.

Nella schermata che compare inseriamo il nome che assegneremo al PSO (“Password policy molto restrittiva”).

Ora occorre completare il wizard secondo questa tabella che ci eravamo preparati in precedenza (è obbligatorio inserire tutti i valori):

Nota

Nota: per ottenere rapidamente il Distinguished Name (DN) di un gruppo di protezione o di un utente, andate nelle sue proprietà all’interno di Active Directory Users and Computers, scheda Attribute Editor, cercate l’attributo distinguishedName, cliccate sul pulsante View e copiatene il valore da utilizzare per l’attributo msDS-PSOAppliesTo.

Una volta completato il wizard, non cliccate sul pulsante Finish perché vi sarete resi conto che manca ancora un valore da inserire, quello appunto dell’attributo msDS-PSOAppliesTo.

In quest’ultima schermata clicchiamo il pulsante More Attributes in alto a destra; nella finestra che comparirà, alla voce Select which properties to view selezioniamo Optional, nel menu a tendina Select a property to view selezioniamo msDS-PSOAppliesTo e nel campo Edit Attribute inseriamo il DN del gruppo di protezione IT-Admins cliccando alla fine su Add.

Chiudiamo la finestra cliccando su OK e quindi Finish. Il nuovo PSO apparirà nel riquadro di destra all’interno del CN=Password Settings Container in ADSI Edit.

Ora dobbiamo accertarci che le nuove impostazioni siano state memorizzate correttamente in Active Directory. Ritorniamo in Active Directory Users and Computers e scendiamo fino a betadomain.local / System / Password Settings Container. Qui ritroviamo il nostro PSO e cliccandone le Proprietà, nella scheda Attribute Editor, troviamo l’attributo msDS-PSOAppliesTo che punta al Distinguished Name CN=IT-Admins, OU=Groups, DC=domain, DC=local.

L’utente Steven Dennis è membro del gruppo di protezione IT-Admins. Andando nelle sue proprietà e cliccando sulla scheda Attribute Editor possiamo ritrovare l’attributo msDS-ResultantPSO con il valore del PSO corretto. Se l’attributo non avesse un valore significherebbe che sarebbe attiva la password policy della Default Domain Policy.

Se in futuro volessimo applicare il PSO “Password policy molto restrittiva” anche, ad esempio, ai membri del gruppo Sales-Europe, è sufficiente andare in Active Directory Users and Computer, scendere fino a betadomain.local / System / Password Settings Container, cliccare le Proprietà del PSO, scheda Attribute Editor, selezionare l’attributo msDS-PSOAppliesTo e cliccare in basso a sinistra il pulsante Edit.

Cliccando sul pulsante in basso Add DN... inseriremo poi il DN del gruppo Sales-Europe (CN=Sales-Europe, OU=Sales, DC=betadomain, DC=local) e daremo OK.

Prima di terminare, è doveroso fornire maggiori dettagli su un paio di aspetti un po’ misteriosi che abbiamo incontrato durante la configurazione.

I quattro valori inseriti nel wizard di creazione del PSO relativi alla durata massima e minima della password, la durata del blocco account e il tempo che deve trascorrere prima che il contatore dei tentativi errati venga azzerato sono stati immessi nel formato I8. Questo formato memorizza l’unità di tempo ad intervalli di -100 nanosecondi ed è necessario, quindi, convertire prima il consueto formato in minuti, ore o giorni in intervalli di 100 nanosecondi e anteporre al risultato il segno meno.

Questa è una piccola tabella di conversione verso il formato I8:

Nella creazione di nuovi PSO, tenete presente che:

• il valore msDS-MinimumPasswordAge deve essere minore o uguale al valore msDS-MaximumPasswordAge.

• il valore msDS-LockoutObservationWindow non può essere minore del valore msDS-LockoutDuration.

• il valore msDS-MaximumPasswordAge non può essere zero.

La seconda finestra del wizard di creazione del PSO ci chiedeva il valore di un attributo relativo alla precedenza della password policy. A che cosa serve questo valore? Un utente o un gruppo possono ritrovarsi assegnati più di un PSO, sia perché un utente può appartenere a più di un gruppo o perché, forse erroneamente, ad un oggetto sono stati assegnati direttamente più PSO. In ogni caso, solo un PSO può essere attivo come password policy e solo le impostazioni di quel PSO agiscono su quell’utente o su quel gruppo, le impostazioni degli altri eventuali PSO non possono essere sommate. La precedenza (grazie all’attributo msDS-PasswordSettingsPrecedence) serve a definire la priorità di un PSO rispetto ad un altro. Più un valore è basso, più la sua priorità è alta. Se creassimo un nuovo PSO completamente diverso da quello appena concepito e questo PSO avesse l’attributo msDS-PasswordSettingsPrecedence con valore 9, assegnandolo al gruppo IT-Admins avrebbe una precedenza (priorità) maggiore e diventerebbe il PSO attivo per quel gruppo, sostituendo il PSO Password policy molto restrittiva.

E’ bene quindi assegnare un valore msDS-PasswordSettingsPrecedence univoco per tutti i PSO che creeremo. Se più PSO con il medesimo valore msDS-PasswordSettingsPrecedence sono assegnati ad un utente o a un gruppo, “vince” e ha dunque la precedenza il PSO che ha il Globally Unique Identifier (GUID) più basso. Questo GUID è visualizzabile nelle proprietà del PSO all’interno del Container Password Settings Container nello snap-in Active Directory Users and Computers.

Come detto in precedenza, non è possibile assegnare direttamente una nuova password policy ad un account computer oppure ad una OU. Se il proprio dominio di Active Directory non è stato ben organizzato in gruppi di protezione, è possibile creare dei cosiddetti “gruppi ombra” da associare alle OU che contengono gli utenti designati. Un gruppo ombra è sostanzialmente un gruppo di protezione in cui inserire gli utenti contenuti nella OU e al quale verrà assegnato il nuovo PSO. E’ chiaro che se si sposta un utente da una OU all’altra, andrà riconfigurata l’appartenenza al gruppo ombra della nuova OU di destinazione.