Numero speciale Windows Server 2008

Novità in Servizi di dominio Active Directory

Gil Kirkpatrick

 

Panoramica:

• Utilizzo del nuovo strumento Server Manager con ADDS
• Esecuzione dei servizi di dominio su Server Core
• Controller di dominio di sola lettura
• Modifica di password, backup e controllo

Con Windows 2000 Microsoft ha introdotto Active Directory. La versione successiva, Windows Server 2003, ha introdotto significativi miglioramenti in Active Directory, ma nessuna

modifica rivoluzionaria. Oggi, Active Directory® è un servizio directory consolidato e molto affidabile. Ciò nonostante, il team di Active Directory ha introdotto innovazioni significative nella versione più recente allo scopo di migliorare la protezione e la gestibilità di questo servizio di rete di base.

Al volgere del secolo, Active Directory rappresentava il sistema in grado di autenticare un utente all'accesso, applicare criteri di gruppo all'utente e al relativo computer e assistere l'utente nella ricerca della stampante desiderata. Alcuni anni dopo, Microsoft ha rilasciato una variante autonoma denominata Active Directory Application Mode (ADAM).

Con l'avvento del 2006, la situazione è completamente cambiata. Active Directory non era più una tecnologia specifica. Attualmente, rappresenta un marchio che identifica un insieme di servizi Windows® integrati per il controllo di accesso e di identità. Nella Figura 1 viene riportato un rapido riepilogo dei componenti che costituiscono Active Directory.

Figure 1 Componenti di Active Directory

Tecnologia Active Directory corrente	Denominazione precedente	Descrizione
Servizi di dominio Active Directory (ADDS)	Active Directory	Si tratta della tecnologia che in precedenza era definita Active Directory. Fornisce l'autenticazione Kerberos e basata su NTLM per gli utenti e i computer di dominio; inoltre gestisce unità organizzative, utenti, gruppi, criteri di gruppo e molto altro.
Active Directory Lightweight Directory Services (ADLDS)	Active Directory Application Mode (ADAM)	Un server LDAP a elevate prestazioni basato sullo stesso codice sorgente utilizzato da ADDS.
Servizi certificati Active Directory (ADCS)	Servizi certificati	Fornisce autenticazione avanzata mediante certificati X.509.
Active Directory Rights Management Services (ADRMS)	Rights Management Server	Protegge le risorse digitali, come documenti e messaggi di posta elettronica, dall'utilizzo non autorizzato creando file e contenitori protetti da diritti.
Active Directory Federation Services (ADFS)	Active Directory Federation Services	Fornisce federazione delle identità e funzionalità Single Sign-On Web per i servizi Web compatibili con WS-*.

Pertanto, per utilizzare la corretta terminologia, questo articolo tratta di Servizi di dominio. È bene chiarire, tuttavia, che si tratta dello stesso Active Directory che abbiamo imparato ad amare sin dal 2000.

Server Manager in Windows Server 2008

I primi due miglioramenti per Active Directory che verranno illustrati in questo articolo, in effetti, non rappresentano le modifiche introdotte in Servizi di dominio Active Directory (ADDS), quanto piuttosto le modifiche introdotte nell'ambiente Windows che cambieranno la modalità di gestione di Active Directory. Il primo, il nuovo strumento Server Manager, viene visualizzato quando il server Windows Server® 2008 viene avviato per la prima volta. Il secondo è rappresentato dall'installazione di Server Core, che verrà trattata tra breve.

Server Manager risulterà probabilmente familiare in quanto già disponibile nella Configurazione guidata server di Windows Server 2003, che viene visualizzata, per impostazione predefinita, dopo l'installazione di Windows Server 2003. Tale versione, tuttavia, non risulta particolarmente utile per l'amministrazione quotidiana e molti utenti preferiscono selezionare la casella "Non visualizzare questa pagina all'accesso".

Server Manager in Windows Server 2008, invece, si rivela molto utile (per una panoramica su Server Manager, vedere l'articolo di Byron Hynes in questo numero di TechNet Magazine). Innanzitutto, come si può osservare nella Figura 2, Server Manager ora è uno snap-in di Microsoft® Management Console (MMC) anziché un'applicazione HTML (HTA). Questo significa che tale strumento è dotato di un'interfaccia utente con funzionalità complete familiare e facile da personalizzare. Server Manager consente di gestire l'installazione dei ruoli del server (servizi principali come DNS, ADDS e IIS) e delle funzionalità (componenti software, come Microsoft .NET Framework, Crittografia unità BitLockerTM e Windows PowerShellTM). Oltre alla possibilità di aggiungere e rimuovere il software, Server Manager fornisce anche un singolo punto di contatto per l'esecuzione di strumenti di diagnostica, come Visualizzatore eventi e PerfMon, e utilità di configurazione di sistema, come Gestione dispositivi e lo snap-in Windows Firewall. Se si aggiungono gli snap-in di MMC per Active Directory, ad esempio Utenti e computer, Domini e trust e Siti e servizi, si avrà a disposizione un'interfaccia molto interessante per la gestione quotidiana del controller di dominio di Windows Server 2008.

Figura 2** Server Manager in Windows Server 2008 **(Fare clic sull'immagine per ingrandirla)

Server Core per Windows Server 2008

Windows Server Core è una nuova opzione di installazione di Windows che fornisce una versione ridotta di Windows contenente solo i componenti necessari per eseguire alcuni ruoli del server principali, come Servizi di dominio Active Directory. Nella Figura 3 vengono elencati i ruoli supportati da Server Core. Sebbene l'installazione di Server Core preveda un'interfaccia grafica, non esegue la shell desktop di Windows e quasi tutti gli strumenti grafici per la gestione e la configurazione di Windows sono assenti (vedere la Figura 4). In sostituzione di tali strumenti è presente solo una finestra di comando, che crea una "sensazione di vuoto", in quanto non viene fornita alcuna indicazione sulle successive azioni da intraprendere. In che modo è possibile modificare il nome del computer? In che modo è possibile configurare un indirizzo IP statico?

Figura 4** Non c'è molto da vedere nell'interfaccia utente di Server Core **(Fare clic sull'immagine per ingrandirla)

I primi minuti davanti a un'installazione di Server Core possono essere in un certo qual modo sconvolgenti. Tuttavia, se si dedica un po' di tempo ad acquisire nuovamente dimestichezza con le utilità WMIC, NETSH e NETDOM, si sarà in grado di eseguire tutte le comuni attività di installazione e configurazione senza alcuna difficoltà. Inoltre, per soddisfare le proprie esigenze grafiche, è ancora possibile avvalersi di Regedit e del Blocco note.

Il vantaggio principale di Server Core è che gran parte della quantità di codice risultante da un'installazione di Windows tipica, che potrebbe non essere necessaria per i ruoli del server di base, viene rimossa. Questo determina una riduzione della potenziale superficie di attacco per il malware (un grande vantaggio) nonché una riduzione del numero di applicazioni di patch e di riavvii che è necessario eseguire nei controller di dominio (un vantaggio ancora maggiore). È possibile inoltre ottenere una riduzione del footprint del disco e dei requisiti dell'unità disco, il che, sebbene non rappresenti un grosso vantaggio, può rivelarsi particolarmente utile in ambienti server virtualizzati.

La mancanza di utilità grafiche renderà difficoltosa la gestione di ADDS? Niente affatto. È possibile effettuare quasi tutta le attività di gestione in modalità remota eseguendo le utilità sulla workstation locale e connettendosi al controller di dominio in rete. Prevedo che la maggior parte dei controller di dominio verrà, alla fine, eseguita nelle installazioni Server Core.

Modifiche a DCPROMO

La prima modifica che è possibile notare in ADDS è rappresentata dalla nuova funzionalità DCPROMO. Sebbene identica alla funzionalità DCPROMO disponibile in Windows Server 2003, la nuova utilità è stata completamente riscritta per semplificarne l'utilizzo. Non è necessario, ad esempio, inserire le credenziali di amministratore di dominio, in quanto DCPROMO è in grado di utilizzare le credenziali dell'account di accesso corrente per innalzare di livello il server. Non occorre inoltre digitare DCPROMO /ADV per attivare le opzioni DCPROMO in modalità avanzata; ora nella prima finestra di dialogo di DCPROMO è presente una casella di controllo che consente di attivare queste opzioni. La modalità avanzata consente inoltre di selezionare il controller di dominio esistente da cui eseguire la replica. Questo contribuisce a ridurre il carico di replica di DCPROMO che grava sui controller di dominio di produzione.

Durante l'innalzamento di livello di un controller di dominio in un nuovo dominio o una nuova foresta, DCPROMO consente di impostare immediatamente il livello di funzionalità del dominio e della foresta. È inoltre possibile specificare il sito di Active Directory in cui si desidera inserire il controller di dominio durante il processo di innalzamento di livello, il che risulta molto utile in uno scenario con DCPROMO in automatico. DCPROMO è in grado persino di suggerire il sito più appropriato per il controller di dominio in base all'indirizzo IP del controller di dominio.

Il nuovo strumento DCPROMO prevede la raccolta in una singola pagina di tutte le opzioni di configurazione, fornendo un'unica posizione in cui è possibile scegliere se impostare il nuovo controller di dominio su un catalogo globale, un server DNS o un controller di dominio di sola lettura. Non è necessario accedere a un'area sconosciuta dello snap-in Siti e servizi di Active Directory per contrassegnare il controller di dominio come catalogo globale.

Tuttavia, probabilmente la funzionalità più interessante della nuova utilità DCPROMO è rappresentata dalla capacità di salvare tutte le impostazioni di DCPROMO in un file di risposta prima dell'avvio del processo di innalzamento di livello. Questo meccanismo è molto più semplice e meno soggetto a errori rispetto alla compilazione manuale del file di risposta. È quindi possibile utilizzare il file di risposta per eseguire le operazioni DCPROMO in modalità automatica su altri server. Per i fanatici degli script, tutte le opzioni di DCPROMO sono ora accessibili dalla riga di comando.

Controller di dominio di sola lettura

Nelle prime fasi del rilascio di Active Directory, le organizzazioni distribuivano in genere i controller di dominio in ogni sito a cui gli utenti potevano accedere. Questo comportamento era piuttosto comune nelle banche, che collocavano, ad esempio, un controller di dominio in ogni succursale. La logica era che gli utenti nella succursale sarebbero stati in grado di accedere alle risorse di rete locali anche in caso di errore della rete WAN.

In quel periodo, l'importanza della necessità di garantire la protezione fisica dei controller di dominio non era stata ben compresa. Ho visto controller di dominio posizionati sotto le scrivanie a cui tutti potevano accedere senza problemi. Solo alcuni anni dopo i progettisti di Active Directory hanno compreso pienamente il rischio per la protezione che un controller di dominio non protetto crea. Di conseguenza, le organizzazioni IT hanno iniziato a consolidare i relativi controller di dominio in centri dati più centralizzati. Questo implicava la necessità per gli utenti delle succursali di eseguire l'autenticazione sulla rete WAN, un compromesso tuttavia vantaggioso in termini di maggiore protezione.

Active Directory in Windows Server 2008 cambia l'equazione rispetto alle distribuzioni in succursali introducendo i controller di dominio di sola lettura. Questi rappresentano la modifica la più significativa in Servizi di dominio di Windows Server 2008.

Il team di Active Directory si è concentrato sui requisiti dello scenario di distribuzione in succursali quando ha progettato il controller di dominio di sola lettura e ha adottato un approccio di tipo "Ciò che accade nella succursale, resta nella succursale". Il punto è che, se si distribuisce un controller di dominio in una succursale fisicamente non protetta, non si potrà in alcun modo impedire che il controller di dominio (e i computer che considerano attendibile tale controller di dominio) venga compromesso. È tuttavia possibile impedire che tale compromissione si diffonda dalla succursale nel resto del dominio.

Tenere presente che, anche se rappresentano una modifica significativa all'infrastruttura ADDS, i controller di dominio di sola lettura sono piuttosto semplici da implementare. Il dominio deve essere al livello di funzionalità della foresta di Windows Server 2003 ed è necessario che nel dominio sia presente almeno un controller di dominio di Windows Server 2008. Oltre a essere una semplice soluzione per succursali, i controller di dominio di sola lettura sono utili in ambienti che interagiscono con Internet e in situazioni in cui il controller di dominio viene posizionato nella rete perimetrale.

Furto di un controller di dominio

Esistono diverse classi di minacce che occorre prendere in considerazione in una succursale. Il primo tipo di minaccia è rappresentato da uno scenario che prevede il furto di un controller di dominio, in cui qualcuno ruba il controller di dominio o il disco del controller di dominio. Oltre all'interruzione del servizio locale, il rischio principale è rappresentato dalla capacità dell'utente malintenzionato di accedere a tutti i nomi e le password degli utenti all'interno del dominio e di elevare i relativi privilegi per ottenere l'accesso alle risorse protette o causare un attacco Denial of Service. Per far fronte a questa minaccia, i controller di dominio di sola lettura, per impostazione predefinita, non archiviano hash di password nel database DIT (Directory Information Tree) del controller di dominio di sola lettura. Pertanto, per eseguire l'autenticazione nel dominio, quando un utente si autentica per la prima volta presso uno specifico controller di dominio di sola lettura, quest'ultimo passa la richiesta al controller di dominio completo nel dominio. Il controller di dominio completo elabora la richiesta e, in caso di esito positivo, il controller di dominio di sola lettura emette una richiesta di replica per l'hash di password.

Un controller di dominio di sola lettura compromesso potrebbe richiedere hash di password per gli account riservati. Per impedire una situazione di questo tipo, l'amministratore del dominio può configurare un criterio di replica password per ogni controller di dominio di sola lettura. Il criterio di replica password è composto da due attributi nell'oggetto computer del controller di dominio di sola lettura. L'attributo msDS-RevealOnDemandGroup contiene i nomi distinti di gruppi, utenti o account di computer le cui password possono essere memorizzate nella cache del controller di dominio di sola lettura (si tratta in genere degli utenti e dei computer che risiedono nello stesso sito del controller di dominio di sola lettura). L'attributo msDS-NeverRevealGroup contiene i nomi distinti di gruppi, utenti o account di computer le cui password non possono essere memorizzate nella cache del controller di dominio di sola lettura (ad esempio, l'account di amministratore di dominio non deve mai memorizzare nella cache del controller di dominio di sola lettura i relativi hash di password). Quando il controller di dominio di sola lettura richiede l'hash della password per uno specifico account, il controller di dominio completo valuta la richiesta in base al criterio di replica password per determinare se l'hash della password deve essere replicato nel controller di dominio di sola lettura. Quando un controller di dominio viene rubato, questa situazione limita la vulnerabilità delle password che sono state memorizzate nella cache del controller di dominio di sola lettura rubato nel momento in cui è stato rimosso dalla rete ed elimina la possibilità che una password critica venga compromessa.

L'oggetto computer del controller di dominio di sola lettura contiene altri due attributi che consentono di determinare esattamente quali account devono avere le relative password memorizzate nella cache. L'attributo msDS-AuthenticatedAtDC elenca gli account che sono stati autenticati nel controller di dominio di sola lettura, mentre l'attributo msDS-RevealedList elenca gli account le cui password sono correntemente memorizzate nel controller di dominio di sola lettura.

Gli hash di password di utenti e computer non sono gli unici segreti memorizzati in un controller di dominio. L'account KrbTGT contiene le chiavi per il servizio Centro distribuzione chiavi Kerberos (KDC) in esecuzione in ciascun controller di dominio. In uno scenario tipico, ogni KDC all'interno del dominio condivide lo stesso account KrbTGT ed è possibile che un utente malintenzionato recuperi queste chiavi da un controller di dominio rubato e le utilizzi per sferrare un attacco contro il resto del dominio. Tuttavia, ogni controller di dominio di sola lettura dispone di un proprio account KrbTGT e di specifiche chiavi, eliminando tale possibilità.

Inoltre, non è insolito per le applicazioni memorizzare le password o altri segreti nel DIT. Se un utente malintenzionato dovesse rubare un controller di dominio, potrebbe rubare eventualmente le password di queste applicazioni e utilizzarle per accedere alle applicazioni. Per ridurre questo rischio, Servizi di dominio di Windows Server 2008 consente agli amministratori di definire il RO-FAS (Read-Only DC Filtered Attribute Set). Gli attributi che fanno parte del RO-FA non vengono mai replicati nei controller di dominio di sola lettura e, pertanto, non possono essere recuperati da un controller di dominio compromesso. È possibile assegnare attributi al RO-FAS impostando il bit 9 (0x0200) dell'attributo searchFlags dell'oggetto attributeSchema corrispondente nello schema.

I barbari sono alle porte

Un'altra classe di minaccia per i controller di dominio delle succursali è rappresentata da uno scenario in cui un amministratore di un server locale eleva i relativi privilegi utilizzando i privilegi del controller di dominio per ottenere l'accesso ad altre risorse del dominio o progettare un attacco Denial of Service. Se l'amministratore locale dispone dell'accesso fisico al controller di dominio, non è possibile in alcun modo evitare la compromissione. Tuttavia, è possibile impedire all'utente malintenzionato di utilizzare il controller di dominio della succursale per compromettere gli altri controller di dominio all'interno del dominio.

I controller di dominio di sola lettura non vengono considerati come controller di dominio trusted dai controller di dominio completi all'interno del dominio. Dal punto di vista dell'attendibilità, i controller di dominio completi considerano i controller di dominio di sola lettura come server membro del dominio. Un controller di dominio di sola lettura non è membro del gruppo Controller di dominio organizzazione o Controller di dominio. Poiché la capacità dell'account del controller di dominio di sola lettura di aggiornare il contenuto della directory è piuttosto limitata, anche se un utente malintenzionato compromette l'account del controller di dominio di sola lettura, non otterrà privilegi utili.

I controller di dominio di sola lettura non vengono neppure visualizzati nella normale topologia di replica di Servizi di dominio. Poiché i controller di dominio di sola lettura sono simili a normali server membro piuttosto che a controller di dominio, l'attività di Controllo di coerenza informazioni (KCC, Knowledge Consistency Checker), che rappresenta il processo in ciascun controller di dominio responsabile del calcolo della topologia di replica di Servizi di dominio, non creerà oggetti connessione dai controller di dominio di sola lettura. Nessun controller di dominio completo o controller di dominio di sola lettura tenterà di eseguire la replica da un controller di dominio di sola lettura. D'altra parte, il controller di dominio di sola lettura creerà un oggetto connessione che rappresenta un accordo di replica in ingresso da un controller di dominio completo; tuttavia, questo oggetto connessione esiste solo nella replica del controller di dominio di sola lettura, in quanto nessun altro controller di dominio dispone di una copia dell'oggetto connessione in questione. Dal punto di vista della replica, i controller di dominio di sola lettura sono come "trappole per scarafaggi" per gli oggetti directory. Gli oggetti vengono replicati in ingresso, ma non vengono replicati in uscita.

Separazione dei ruoli amministrativi nei controller di dominio di sola lettura

È molto comune che un controller di dominio di succursale venga gestito da un amministratore del server locale che esegue qualsiasi tipo di operazione, dall'esecuzione dei backup sul controller di dominio alla pulizia delle tastiere. Tuttavia, la concessione a un amministratore di un sito remoto dei diritti necessari per eseguire la manutenzione generale in un controller di dominio rappresenta un rischio per la protezione e l'amministratore del sito potrebbe elevare i relativi privilegi nel dominio. Per ridurre questo rischio, i controller di dominio di sola lettura forniscono due tipi di separazione dei ruoli amministrativi.

Con il primo tipo di separazione dei ruoli, l'amministratore del dominio può innalzare di livello il controller di dominio di sola lettura utilizzando DCPROMO o può utilizzare un processo a due fasi in cui il processo di innalzamento di livello effettivo viene delegato all'amministratore della succursale, senza concedere diritti per l'amministrazione del dominio. L'amministratore del dominio crea in modo preliminare l'account del computer del controller di dominio di sola lettura utilizzando lo snap-in MMC Utenti e computer di Active Directory, come illustrato nella Figura 5.

Figura 5** Creazione preliminare dell'account del computer del controller di dominio di sola lettura **(Fare clic sull'immagine per ingrandirla)

Se si seleziona "Creazione preliminare account controller di dominio di sola lettura", verrà eseguita una versione abbreviata di DCPROMO che esegue tutte le attività che richiedono l'accesso amministrativo al dominio, tra cui la creazione dell'account del computer, l'assegnazione del controller di dominio di sola lettura a un sito, l'impostazione dei ruoli del controller di dominio, l'impostazione dei criteri di replica password e la definizione dell'utente o del gruppo che dovrà disporre dei diritti necessari per completare l'operazione DCPROMO nel controller di dominio di sola lettura. L'amministratore o il gruppo delegato viene memorizzato nell'attributo managedBy dell'oggetto computer del controller di dominio di sola lettura.

L'amministratore delegato può eseguire quindi DCPROMO sullo stesso server. DCPROMO rileverà l'account creato in modo preliminare e convertirà il server in un controller di dominio di sola lettura. Questa modalità di esecuzione di DCPROMO non richiede credenziali di amministratore di dominio.

Il secondo metodo con cui i controller di dominio di sola lettura forniscono la separazione dei ruoli amministrativi consiste nel creare ruoli amministrativi locali nel controller di dominio di sola lettura. Questi ruoli, che sono simili a gruppi locali di computer, vengono memorizzati nel Registro di sistema del controller di dominio di sola lettura e possono essere solo valutati nel controller di dominio di sola lettura. Tuttavia, anziché utilizzare lo snap-in di MMC Gestione computer per gestirli, l'amministratore gestisce i ruoli dei controller di dominio di sola lettura locali mediante NTDSUTIL. Nella Figura 6 vengono elencati i ruoli amministrativi locali in un controller di dominio di sola lettura. Esiste una corrispondenza uno-a-uno tra questi ruoli e i gruppi incorporati di Windows.

Figure 6 Ruoli amministrativi dei controller di dominio di sola lettura locali

Account Operators

Administrators

Backup Operators

Certificate Service DCOM Access

Cryptographic Operators

Distributed COM Users

Event Log Readers

Guests

IIS_IUSRS

Incoming Forest Trust Builders

Network Configuration Operators

Performance Log Users

Performance Monitor Users

Pre-Windows 2000 Compatible Access

Print Operators

Remote Desktop Users

Replicator

Server Operators

Terminal Server License Servers

Users

Windows Authorization Access Group

Comportamento imprevisto dei controller di dominio di sola lettura

Poiché i controller di dominio di sola lettura sono di sola lettura e nessuno altro controller di dominio può eseguire la replica da tali controller di dominio, i controller di dominio di sola lettura presentano alcuni comportamenti imprevisti. Ad esempio, gli oggetti residui, ovvero gli oggetti che sono stati eliminati da ovunque eccetto da uno specifico controller di dominio, in quanto quest'ultimo non è stato in grado di eseguire la replica per un tempo maggiore rispetto alla durata di rimozione definitiva della foresta, vengono in genere rilevati dai partner di replica in uscita del controller di dominio. Tuttavia, poiché i controller di dominio di sola lettura non dispongono di partner di replica in ingresso, per tali controller di dominio non viene rilevato alcun oggetto residuo.

I controller di dominio di sola lettura non prevedono le operazioni di aggiornamento LDAP (aggiunta, modifica, eliminazione, ridenominazione o spostamento), ma restituiscono un errore con un riferimento LDAP a un controller di dominio scrivibile che può gestire l'operazione. Se l'applicazione che ha richiesto l'aggiornamento LDAP non è in grado di gestire correttamente l'operazione di riferimento, è possibile che si verifiche un errore.

Infine, se un utente da un altro dominio nella foresta tenta di eseguire l'autenticazione in un controller di dominio di sola lettura, quest'ultimo dovrà essere in grado di accedere a un controller di dominio completo nel proprio dominio per ottenere la password di trust in modo da passare correttamente la richiesta di autenticazione al controller di dominio nel dominio dell'utente. Se la connessione di rete tra il controller di dominio di sola lettura e il controller di dominio completo nel relativo dominio non è disponibile, l'autenticazione non riuscirà.

Criteri specifici per le password

La capacità di definire più criteri password nel dominio è stata probabilmente la funzionalità più richiesta per il servizio ADDS di Windows Server 2008. Come probabilmente si saprà, in Windows 2000 e in Active Directory per Windows Server 2003, ogni dominio supporta un singolo criterio password che viene applicato a tutte le entità di protezione all'interno del dominio. Se si necessita di un criterio password separato per un gruppo specifico di utenti, occorre creare un dominio separato. Tuttavia, ora una nuova funzionalità di ASSD per Windows Server 2008, denominata criteri specifici per le password, consente di definire più criteri password all'interno di un dominio.

La nuova strategia utilizza i gruppi per applicare agli utenti i criteri specifici per le password. È necessario prima definire i criteri specifici per le password creando un nuovo oggetto msDS-PasswordSettings in CN=Contenitore Impostazioni password, CN=Sistema, DC=<dominio>. L'oggetto msDS-PasswordSettings (abbreviato in PSO) contiene attributi che equivalgono all'impostazione dei criteri password in Criteri di gruppo (vedere la Figura 7).

Figure 7 Attributi nell'oggetto mSDS-PasswordSettings

Attributo	Descrizione
mSDS-PasswordReversibleEncryptionEnabled	Valore booleano che indica se le password vengono crittografate mediante la crittografia reversibile.
mSDS-PasswordHistoryLength	Numero di voci contenute nella cronologia delle password.
mSDS-PasswordComplexityEnabled	Valore booleano che indica se le restrizioni relative alla complessità delle password sono attivati.
mSDS-MinimumPasswordLength	Numero intero che definisce la lunghezza minima della password.
mSDS-MinimumPasswordAge	INTEGER8 che indica la validità minima della password prima che possa essere modificata.
mSDS-MaximumPasswordAge	INTEGER8 che indica la validità massima della password prima che sia necessario modificarla.
mSDS-LockoutThreshold	Numero intero che indica il numero di accessi non riusciti prima del blocco.
mSDS-LockoutObservationWindow	INTEGER8 che indica il numero di nanosecondi entro cui è necessario eseguire accessi consecutivi non riusciti per attivare il blocco.
mSDS-LockoutDuration	INTEGER8 che indica il numero di nanosecondi in cui l'account viene bloccato.

Assegnare quindi i criteri password agli utenti o ai gruppi aggiungendo i nomi degli utenti o dei gruppi all'attributo multivalore mDS-PSOAppliesTo di PSO. Una volta accettata l'idea che i criteri password non vengono applicati alle unità organizzative, tale attività è piuttosto semplice, anche se presenta un livello di complessità aggiuntivo.

Gli utenti sono in genere membri di molti gruppi. Pertanto, cosa accade se a un utente sono associati più criteri password in conflitto a causa dell'appartenenza a diversi gruppi? In questo caso, ADDS utilizza la valutazione delle precedenze per determinare quali criteri password devono essere applicati. Questo meccanismo funziona come indicato di seguito:

1. Se un criterio password viene collegato a un oggetto utente direttamente (non tramite l'appartenenza al gruppo), verrà applicato il criterio password in questione.
2. Se all'utente vengono collegati direttamente più criteri password, verrà applicato il criterio con il valore di precedenza più basso (come determinato dal valore dell'attributo msDS-PasswordSettingsPrecendence di PSO).
3. Se sono presenti più PSO con la stessa precedenza, verrà applicato quello con il valore objectGUID più basso.
4. Se all'utente non viene collegato direttamente alcun PSO, ADDS valuterà i PSO collegati ai gruppi dell'utente. Se sono presenti più PSO, verrà applicato il PSO con il valore più basso nell'attributo msDS-PasswordSettingsPrecedence.
5. Se sono presenti più PSO con lo stesso valore di precedenza, verrà applicato quello con il valore objectGUID più basso.
6. Se all'utente non è associato alcun PSO, verranno utilizzati i criteri password di dominio.

Gli oggetti utente hanno un nuovo attributo denominato msDS-ResultantPSO che consente di determinare esattamente il PSO da applicare a un utente. Questo attributo contiene il nome distinto del PSO che gestisce la password dell'utente in questione.

I criteri specifici per le password forniscono maggiore flessibilità di quella effettivamente necessaria, ma occorre gestire questi criteri con attenzione e garantirne la semplicità di utilizzo. Non è disponibile alcuna utilità integrata per la definizione di criteri specifici per le password e, pertanto, sarà necessario utilizzare ADSIEdit o un'utilità di terze parti.

Servizio Active Directory riavviabile

Ogni volta che si provoca l'arresto di un controller di dominio per la manutenzione DIT si causa un'interruzione nei livelli di servizio della rete. I controller di dominio di Windows Server 2008 dispongono di una nuova funzionalità che consente di arrestare il servizio directory senza arrestare completamente il controller di dominio.

Il comando NET STOP NTDS consente di arrestare ADDS in un controller di dominio di Windows Server 2008. Quando si esegue questa operazione, il processo LSASS (Local Security Authority Subsystem Service) sul controller di dominio continua l'esecuzione, ma scarica tutte le DLL correlate ad ADDS e il servizio directory diventa non disponibile. LSASS si comporta essenzialmente come si comporterebbe su un server membro, inoltrando le richieste di autenticazione del dominio a un controller di dominio. Poiché le DLL che gestiscono ADDS vengono scaricate, è possibile applicare delle patch correlate ad ADDS o eseguire una deframmentazione non in linea del DIT. L'avvio di ADDS è semplice quanto l'avvio di NET START NTDS. Il ripristino del DIT da un backup dello stato di sistema richiede tuttavia l'esecuzione dell'avvio in modalità ripristino servizi directory.

È importante comprendere che il servizio directory non è un vero servizio di Windows. È un componente integrato di LSASS e non è possibile arrestare LSASS senza spegnere il computer. Tuttavia, la capacità di avviare e arrestare il servizio directory in Windows Server 2008 è un'opzione molto utile.

Backup e ripristino

L'intero meccanismo di backup e ripristino è stato rinnovato in Windows Server 2008. Questo meccanismo non verrà trattato in modo dettagliato nel presente articolo, ma la nuova funzionalità Windows Server Backup presenta alcune modifiche che hanno un impatto significativo su ADDS.

Windows Server Backup è una soluzione di backup basata su volume, ovvero esegue contemporaneamente il backup dei volumi dell'intero disco. Prevede inoltre solo il backup su periferiche disco e non fornisce il supporto per i backup su nastro.

Per l'utilità di backup della riga di comando WBADMIN è disponibile un'opzione di backup dello stato di sistema. Utilizzando il comando WBADMIN START SYSTEMSTATEBACKUP, ora è possibile creare un'immagine di backup che contiene tutti i file di sistema critici necessari per ripristinare Active Directory su un controller di dominio. Il set di backup può contenere un massimo di cinque volumi, ma i volumi nel set di backup conterranno solo i file necessari per un ripristino dello stato di sistema. Ancora più fastidioso è il fatto che, a partire dalla build RC0 di Windows Server 2008, non è possibile eseguire un backup dello stato di sistema in una condivisione di rete. Per archiviare le immagini di backup dello stato di sistema, è necessario che sia disponibile un volume del disco locale e che il volume non faccia parte del set di volumi di backup dello stato di sistema. Potrebbe essere necessario aggiungere un nuovo volume del disco a ogni controller di dominio su cui si eseguono i backup dello stato di sistema.

L'esecuzione di un ripristino dello stato di sistema è piuttosto semplice. Avviare semplicemente il controller di dominio in modalità ripristino servizi directory ed eseguire il comando WBADMIN START SYSTEMSTATERECOVERY. Il risultato è un DIT non ripristinato in modo autorevole, in cui è possibile eseguire un ripristino autorevole di oggetti specifici utilizzando NTDSUTIL, come è stato fatto in Windows Server 2003.

Un aspetto di Windows Server Backup merita particolare attenzione, ovvero la capacità di archiviare le immagini di backup in formato VHD (Virtual Hard Disk). Si tratta dello stesso formato utilizzato in Microsoft Virtual Server 2005 per archiviare le relative immagini disco virtuali. Questo implica la possibilità di utilizzare un'immagine di backup creata con Windows Server Backup e di montarla come unità disco in un computer virtuale in esecuzione su Microsoft Virtual Server. È possibile quindi esplorare i contenuti di backup come se si trattasse di una normale unità disco.

Un'altra modifica riguardante il meccanismo di backup di ADDS è rappresentata dalla capacità di utilizzare il servizio Copia Shadow del volume per creare istantanee temporizzate di Active Directory. Quando si crea un'istantanea utilizzando NTDSUTIL, il servizio Copia Shadow del volume salva i dati visualizzati prima dell'immagine di ciascun blocco del disco del DIT prima che vengano sovrascritti da un'operazione di aggiornamento. Combinando questi dati salvati con la versione corrente del DIT, il servizio Copia Shadow del volume può creare un'istantanea completa del DIT con un overhead minimo. Un'istantanea tipica viene creata solo in pochi secondi, indipendentemente dalle dimensioni del DIT.

Sebbene questa funzionalità sia piuttosto interessante, non è di grande utilità. Tuttavia, in Windows Server 2008, ADDS include un'utilità della riga di comando, denominata DSAMAIN, che consente di montare l'immagine dell'istantanea in modalità di sola lettura. Questo fornisce un server LDAP autonomo, molto simile a un'istanza ADLDS che include il contenuto della directory al momento dell'istantanea. È possibile esplorare la directory utilizzando l'utilità LDP o altri strumenti LDAP e recuperare le versioni degli oggetti directory relative a un momento precedente.

Replica SYSVOL con DFS-R

Windows Server 2003 R2 includeva un servizio DFS (Distributed File Service) completamente rinnovato che incorporava un nuovo meccanismo di replica dei file denominato DFS-R. DFS-R utilizza la tecnologia RDC (Remote Differential Compression, Compressione differenziale remota), che in sostanza riduce il traffico di replica dei file determinando quali blocchi di un file di destinazione devono essere replicati in modo da sincronizzare il file di destinazione con il file di origine. Tuttavia, Windows Server 2003 R2 continua a utilizzare il servizio Replica file (non DFS-R) per replicare SYSVOL tra i controller di dominio. Per questo motivo, la replica SYSVOL ha continuato a essere fonte di problemi per gli amministratori di Active Directory.

Quando l'esecuzione avviene al livello di funzionalità del dominio di Windows Server 2008, Windows Server 2008 è in grado di replicare SYSVOL mediante DFS-R, migliorando la velocità e la robustezza della replica SYSVOL. È ragionevole pertanto collocare file di grandi dimensioni in SYSVOL in modo da renderli disponibili su tutti i controller di dominio. Per utilizzare DFS-R per SYSVOL, è necessario prima eseguire la migrazione dei dati SYSVOL precedenti in DFS-R utilizzando l'utilità DFSRMIG. Questo processo prevede quattro passaggi:

• Creare gli oggetti Active Directory richiesti da DFS-R.
• Creare la nuova struttura di file per SYSVOL su ogni controller di dominio.
• Configurare tutti i controller di dominio per l'utilizzo del nuovo volume SYSVOL.
• Rimuovere il volume SYSVOL precedente.

A seconda delle dimensioni di SYSVOL e del numero di controller di dominio a disposizione, questo processo potrebbe richiedere molto tempo; tuttavia l'incremento delle prestazioni e il miglioramento dell'affidabilità fanno passare in secondo piano lo sforzo compiuto.

Miglioramenti al sistema di controllo

Il sistema di controllo in Active Directory per Windows Server 2003 arreca vantaggi ma anche problemi. Da una parte, fornisce una soluzione completa, flessibile e protetta per tenere traccia delle modifiche nella directory. Tuttavia, alcuni potrebbero sostenere che presenta significativi problemi di utilizzabilità.

L'abilitazione del controllo delle modifiche della directory in un controller di dominio di Windows Server 2003 è come un'operazione di tipo "all-or-nothing": il controllo o è attivato o è disattivato. Inoltre, il volume del traffico di controllo su un controller di dominio organizzazione non disponibile può rendere il controllo impraticabile. La configurazione del sistema di controllo per la produzione dei messaggi necessari utilizzando singoli descrittori di protezione è un'attività noiosa e soggetta a errori. Gli stessi messaggi di controllo sono spesso enigmatici e, in molti casi, non contengono le informazioni necessarie, come i valori precedenti e successivi degli attributi modificati. Inoltre, la raccolta, la correlazione e l'archiviazione dei messaggi da più controller di dominio potrebbe non essere possibile mediante gli strumenti di Windows nativi.

Il sistema di controllo dei servizi directory in Windows Server 2008 fa fronte ad alcuni di questi problemi. Primo, sono disponibili quattro nuove sottocategorie di controllo per il controllo del servizio directory: accesso a Servizi di dominio, modifiche di Servizi di dominio, replica di Servizi di dominio e replica di Servizi di dominio dettagliata. Pertanto, se si desidera controllare le modifiche della directory, non è necessario esaminare tutti gli eventi di replica e di lettura. Tuttavia, se si desidera includere le eliminazioni degli oggetti nel registro di controllo, è necessario attivare l'accesso a Servizi di dominio. Questo determina la generazione di messaggi per tutti gli accessi agli oggetti DS; in sostanza, il risultato è la generazione di un numero eccessivo di messaggi. È responsabilità dello sviluppatore configurare i descrittori di protezione per generare i messaggi di controllo desiderati per gli oggetti a cui è interessato.

I messaggi di controllo sono stati sostanzialmente puliti in modo che siano leggibili e contengano i dati necessari. In particolare, le modifiche della directory generano le voci del registro di controllo che contengono i vecchi e i nuovi valori degli attributi modificati. Questo rappresenta un enorme miglioramento. L'unico svantaggio è che i valori nuovi e precedenti vengono visualizzati in voci del registro di controllo separate e, pertanto, è necessario metterle in correlazione per comprendere la modifica apportata. Molti prodotti di raccolta di registri di controllo aggiuntivi, tra cui Microsoft Audit Collection Services (ACS), supportano questo tipo di correlazione.

Miglioramenti all'interfaccia utente

Gli snap-in di MMC Utenti e computer di Active Directory, Siti e servizi e Domini e trust sono sempre state soluzioni adeguate per la gestione di Active Directory. In Windows Server 2008, gli strumenti di amministrazione di base sono stati puliti e forniscono un paio di nuove e interessanti funzionalità. Se si attiva Caratteristiche avanzate, nella finestra di dialogo delle proprietà per ciascun oggetto viene visualizzata una scheda aggiuntiva, Editor attributi. Si tratta della stessa scheda Editor attributi utilizzata da ADSIEdit, che consente di controllare e modificare tutti gli attributi dell'oggetto. La scheda ora offre una migliore decodifica degli attributi codificati, come l'attributo userAccountControl. Nella Figura 8 viene illustrata la facilità di integrazione dell'editor attributi.

Figura 8** Editor attributi in Utenti e computer di Active Directory **(Fare clic sull'immagine per ingrandirla)

Conclusioni

A parte i punti chiave discussi in questo articolo, in ADDS di Windows Server 2008 sono stati introdotti numerosi altri miglioramenti. Ad esempio, KDC utilizza la tecnologia Advanced Encryption Standard a 256 bit (AES-256) nel caso in cui il dominio si trovi nel livello di funzionalità del dominio di Windows Server 2008. È possibile impedire l'eliminazione accidentale degli oggetti selezionando la casella appropriata nella scheda Oggetto per qualsiasi oggetto DS. Il motore Extensible Storage Engine che fornisce il servizio di gestione dei dati è stato migliorato e configurato per l'utilizzo della correzione di errori di bit singoli, riducendo la probabilità che un errore hardware o software nel sottosistema disco danneggi il DIT. Il servizio DNS avvia l'elaborazione delle richieste prima di aver caricato completamente il database DNS. Il modulo DC Locator è stato migliorato in modo che, in caso di errore durante il rilevamento di un controller di dominio nel sito desiderato, tenti di individuare un controller di dominio nel sito successivo più vicino anziché utilizzare semplicemente un qualsiasi controlller di dominio rilevato all'interno del dominio. L'utilità NTDSUTIL ora supporta i controller di dominio di sola lettura e le istantanee del servizio Copia Shadow del volume.

Chiaramente, Windows Server 2008 introduce un numero significativo di miglioramenti in Servizi di dominio Active Directory. Queste modifiche nell'insieme miglioreranno considerevolmente la protezione e la gestibilità di ADDS. L'aspetto più interessante, tuttavia, è che l'integrazione di Windows Server 2008 nell'ambiente Active Directory non implica una migrazione su larga scala: è un processo semplice e incrementale.

Gil Kirkpatrick è CTO di NetPro e si occupa dello sviluppo software per Active Directory dal 1996. In collaborazione con Guido Grillenmeier, che lavora presso HP, ha realizzato i noti workshop sul ripristino di emergenza in Active Directory. Gil è anche il fondatore della Directory Experts Conference (www.dec2008.com).

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.