Il futuro di WindowsServizi di directory di Windows Server "Longhorn"
Byron Hynes
Questo articolo si riferisce a una versione preliminare di Windows Server, il cui nome in codice è "Longhorn". Tutte le informazioni qui contenute sono soggette a modifiche.
La versione di Windows Server attualmente in produzione, dal nome in codice "Longhorn", rende disponibili molteplici miglioramenti in Active Directory. Alcune di queste modifiche sono decisamente importanti e aprono un varco verso una migliore gestibilità ed efficienza. Una delle modifiche più ovvie in Active Directory è la denominazione delle caratteristiche e funzionalità. Tutto ciò che si riferisce alla gestione delle identità viene proposto ora sotto l'egida di Active Directory®. Ciò che in precedenza veniva chiamato Active Directory in Microsoft® Windows Server® 2003 si chiama ora Servizi di dominio Active Directory (ADDS) e sono disponibili anche altri servizi aggiuntivi, fra i quali Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (o ADLDS, chiamato in precedenza Active Directory/Application Mode o ADAM), Servizi certificati Active Directory (ADCS) e Active Directory Rights Management Services (ADRMS).
Ciascuno di questi servizi rappresenta un ruolo server, un nuovo concetto introdotto in Windows Server "Longhorn". Si può scegliere di avere un computer dedicato a uno o più ruoli server e si possono amministrare i ruoli server con Server Manager, che viene mostrato in figura 1. Da qui è possibile aggiungere ruoli, chiedere assistenza ed eseguire altre attività amministrative ritenute necessarie.
Figura 1.** Server Manager **(Fare clic sull'immagine per ingrandirla)
Come si può osservare, con questo nuovo approccio si organizzano le attività e le funzionalità quotidiane in gruppi logici che sono accessibili in Server Manager.
Livelli di funzionalità
Windows Server "Longhorn" rende disponibile un nuovo livello di funzionalità per gli insiemi di strutture e i domini. Il livello di funzionalità dell'insieme di strutture di Windows Server "Longhorn" (a cui verrà assegnato un nuovo nome al momento del rilascio) non aggiunge di per sé nuove funzionalità, ma fa sì che tutti i domini nell'insieme di strutture siano al livello di funzionalità del dominio di Windows Server "Longhorn", che consente due nuovi miglioramenti. Il primo miglioramento è costituito dall'uso del nuovo motore di replica del file system distribuito (DFS, Distributed File System) per la condivisione SYSVOL, che è più robusto, granulare ed efficiente. Il secondo è il supporto aggiunto per la crittografia AES (Advanced Encryption Services) a 256 bit per il protocollo di autenticazione Kerberos. L'utilizzo del livello di funzionalità più recente assicura prestazioni migliori, ma si può continuare a lavorare con livelli di funzionalità inferiori durante la migrazione a Windows Server "Longhorn".
Sono state introdotte anche numerose estensioni di schema per garantire il supporto di varie funzionalità, tutte compatibili con gli schemi esistenti attualmente utilizzati. I controller di dominio che eseguono Windows Server "Longhorn" possono coesistere e interagire con quelli che eseguono Windows Server 2003.
Supporto per Server Core
I Servizi di dominio Active Directory costituiscono uno dei ruoli server di un'installazione Server Core di Windows Server "Longhorn". Server Core, che non viene trattato dettagliatamente in questo articolo, è un'opzione di installazione minima che mantiene solo le funzionalità principali del server. Con Server Core non viene installata la shell di Windows e non viene utilizzata un'interfaccia utente grafica, il che consente un risparmio notevole di risorse.
Controller di dominio di sola lettura
In alcuni ambienti, la funzionalità più importante di ADDS in Windows Server "Longhorn" è un controller di dominio di sola lettura (RODC, Read-Only Domain Controller) che consente di distribuire facilmente un controller di dominio che ospita una replica di sola lettura del database del dominio. È particolarmente utile nelle sedi in cui non può essere garantita la protezione fisica del controller di dominio o in cui devono essere eseguite altre applicazioni nel controller di dominio che devono essere gestite da un amministratore del server (idealmente, l'amministratore non dovrebbe appartenere al gruppo Domain Admins). Entrambi questi scenari sono diffusi nelle implementazioni delle succursali.
Un controller di dominio di sola lettura si installa semplicemente selezionando una casella di controllo nell'installazione guidata, come mostrato in figura 2.
Figura 2.** Installazione del controller di dominio di sola lettura **(Fare clic sull'immagine per ingrandirla)
Prima del rilascio di Windows Server "Longhorn", se gli utenti dovevano autenticarsi presso un controller di dominio in una sede diversa, il traffico avrebbe dovuto attraversare un collegamento WAN (Wide-Area Network). I collegamenti WAN sono spesso più lenti e più costosi delle connessioni LAN (Local Area Network) e in alcuni casi sono più soggetti a interruzioni del servizio. Una possibile soluzione consisteva nell'implementare un controller di dominio nella succursale o nel sito remoto. Tuttavia, questa soluzione ha dato luogo ad altri problemi, compresi il traffico di replica e la necessità di mantenere la protezione fisica nel controller di dominio della succursale, un aspetto questo che viene troppo spesso trascurato nei siti delle piccole succursali remote. In altri casi, le succursali dispongono di una limitata larghezza di banda per la connessione a un sito centrale (hub), il che allunga i tempi richiesti per l'accesso.
Ad eccezione delle password degli account (a meno che non sia specificato diversamente nelle impostazioni di configurazione), un RODC contiene tutti gli oggetti e gli attributi dei Servizi di dominio Active Directory contenuti in un controller di dominio scrivibile. Tuttavia, le modifiche che hanno origine localmente non possono essere apportate nella replica memorizzata nel RODC. Queste modifiche vengono invece apportate in un controller di dominio scrivibile e replicate nel RODC. Ciò impedisce che le modifiche effettuate nelle sedi della succursale possano contaminare o danneggiare l'insieme di strutture tramite la replica, eliminando così una via di attacco.
Le applicazioni locali che richiedono accesso in lettura alle informazioni contenute nella directory di dominio possono ottenere accesso direttamente dal RODC, mentre le applicazioni LDAP (Lightweight Directory Access Protocol) che richiedono accesso in scrittura ricevono una risposta di riferimento LDAP. Questa risposta di riferimento le indirizza a un controller di dominio scrivibile, di solito in un sito hub.
Poiché nessuna modifica viene scritta direttamente nel RODC, nessuna modifica ha origine nel RODC. Di conseguenza, i controller di dominio scrivibili che sono partner di replica non devono recuperare le modifiche dal RODC. Ciò riduce il carico di lavoro dei server testa di ponte nell'hub e gli sforzi richiesti per monitorare la replica. La replica unidirezionale del RODC si applica sia alla replica ADDS che alla replica DFS. Il RODC esegue la normale replica in ingresso per le modifiche della replica ADDS e DFS.
Nel database del dominio, ogni entità di protezione è dotata di un insieme di circa 10 password o segreti, denominati credenziali. In un RODC non vengono memorizzate le credenziali dell'utente o del computer, ad eccezione dell'account computer specifico del RODC e di uno speciale account "krbtgt" (utilizzato per l'autenticazione Kerberos per ciascun RODC). Il RODC viene annunciato come il centro distribuzione chiavi (KDC, Key Distribution Center) per il relativo sito (solitamente la succursale). Quando il RODC firma o crittografa una richiesta TGT (Ticket-Granting Ticket, ticket di concessione ticket), utilizza un account krbtgt e una password differenti rispetto al KDC di un controller di dominio scrivibile.
La prima volta che un account tenta di autenticarsi presso un RODC, il RODC invia la richiesta a un controller di dominio scrivibile nel sito hub. Se l'autenticazione riesce, il RODC richiede anche una copia delle credenziali appropriate. Il controller di dominio scrivibile riconosce che la richiesta proviene da un RODC e consulta il criterio di replica delle password attivo per quel RODC.
Il criterio di replica delle password determina se le credenziali possono essere replicate e memorizzate nel RODC. In caso affermativo, un controller di dominio scrivibile invia le credenziali al RODC e questo le memorizza nella cache, come spiegato nell'articolo "How a Read-Only Domain Controller Works" (in inglese).
Dopo che le credenziali vengono memorizzate nella cache del RODC, la prossima volta che l'utente tenta di effettuare l'accesso, la richiesta può essere gestita dal RODC fino a quando le credenziali non cambiano. Quando un TGT viene firmato con l'account krbtgt del RODC, krbtgt, il RODC riconosce che ha una copia delle credenziali memorizzata nella cache. Se un altro controller di dominio ha firmato il TGT, il RODC inoltrerà le richieste a un controller di dominio scrivibile.
Limitando la memorizzazione nella cache alle sole credenziali degli utenti che si sono autenticati presso il RODC, si limita la possibile esposizione delle credenziali in presenza di un problema di protezione grave del RODC.
Per impostazione predefinita, nessuna password dell'utente viene memorizzata nella cache di un RODC, ma questo scenario non è necessariamente il più efficiente. Normalmente, solo le credenziali di alcuni utenti di un dominio devono essere memorizzate in un determinato RODC rispetto al numero totale di utenti del dominio. Si può utilizzare il criterio di replica delle password per specificare quali gruppi di utenti devono essere considerati per la memorizzazione nella cache. Limitando, ad esempio, la memorizzazione nella cache del RODC ai soli utenti che si trovano spesso nella succursale, o impedendo la memorizzazione nella cache di credenziali di valore elevato, come quelle degli amministratori, si può ridurre la possibile esposizione a eventuali attacchi.
In questo modo, nel caso in cui il RODC venga sottratto o danneggiato, solo le credenziali che sono state memorizzate nella cache dovranno essere reimpostate e, come spiegheremo più avanti, si saprà esattamente a quali account appartengono, come mostrato in figura 3.
Figura 3.** Informazioni sugli account memorizzati nella cache **(Fare clic sull'immagine per ingrandirla)
Separazione dei ruoli di amministratore
In molte succursali, a un controller di dominio vengono assegnati altri ruoli di server e attività da svolgere, ad esempio il ruolo di file server o di server di stampa. In altri casi, un'applicazione line-of-business viene installata per necessità in u un controller di dominio. In questi casi si ha un problema perché il dipendente di una succursale ha bisogno di credenziali amministrative per amministrare i server e le applicazioni. E chiunque possa amministrare un controller di dominio Windows Server 2003 può amministrare l'intero dominio.
In Windows Server "Longhorn", si può concedere a un amministratore l'autorizzazione per gestire soltanto un determinato RODC, senza attribuirgli l'accesso che gli consentirebbe di gestire altri controller di dominio e senza renderlo inutilmente membro del gruppo di protezione Domain Admins.
Miglioramenti dell'interfaccia utente e degli strumenti
Per supportare le funzionalità del RODC e facilitare il monitoraggio della replica delle password, è disponibile la nuova scheda Criterio di replica password nella pagina delle proprietà del controller di dominio in Utenti e computer di Active Directory, come mostrato in figura 4.
Figura 4.** Scheda Criterio di replica password **(Fare clic sull'immagine per ingrandirla)
Facendo clic sul pulsante Avanzate in questa scheda, è possibile visualizzare quali password sono state inviate al RODC, quali vi sono memorizzate e quali account vi sono stati autenticati, come mostrato in figura 5. Poiché l'elenco include gli account che sono stati autenticati, anche se non appartengono ai gruppi per i quali è consentita la replica delle password, si possono utilizzare queste informazioni per decidere quali gruppi devono essere inclusi nel criterio di replica delle password.
Figura 5.** Criterio di replica password avanzato **(Fare clic sull'immagine per ingrandirla)
Sono state apportate numerose modifiche alla vecchia utilità dcpromo, più comunemente nota con il nome di Installazione guidata dei Servizi di dominio Active Directory. Questa procedura guidata può essere avviata come applicazione grafica completa scegliendo il comando Aggiungi ruoli nella pagina Attività iniziali di configurazione che si apre immediatamente dopo l'installazione del sistema operativo. Scegliere Aggiungi ruoli e poi ADDS in Server Manager o richiamare il comando dcpromo dalla riga di comando o dalla casella Esegui.
Quando si utilizza la procedura guidata in modalità grafica, si può notare una migliore organizzazione degli elementi e delle opzioni, nonché il pratico raggruppamento degli elementi correlati. Sono disponibili anche altre opzioni. Dall'interfaccia utente è possibile accedere alla modalità avanzata senza utilizzare l'opzione /adv per eseguire attività quali la creazione di una nuova struttura di domini, l'installazione da supporto (per ridurre la durata della replica iniziale in una WAN) e la selezione del controller di dominio di origine per la replica iniziale.
Alcuni miglioramenti sono stati apportati per semplificare le operazioni e ridurre eventuali errori frustranti. Ad esempio, se si utilizza la procedura guidata per creare un nuovo controller di dominio in un dominio o in un insieme di strutture esistente, si possono sfogliare i domini esistenti invece di dover digitare il nome NetBIOS.
Sono state aggiunte nuove pagine contenenti opzioni aggiuntive che consentono di configurare il controller di dominio come server di catalogo globale, come server DNS e come RODC. La procedura guidata consente anche di configurare la selezione dei siti, impostare i livelli di funzionalità, creare un criterio di replica delle password per RODC e configurare la delega DNS.
In quanto strumento da riga di comando, l'utilità dcpromo può essere eseguita in modalità completamente automatica. Diversamente dallo stesso strumento in Windows Server 2003, un'installazione automatica non richiede risposta a nessun prompt dell'interfaccia utente, come la richiesta di riavviare il computer. Questo comportamento rende più semplice l'utilizzo di ADDS nelle installazioni Server Core di Windows Server "Longhorn".
Controllo di ADDS
Microsoft aggiunge molte altre funzionalità per il controllo dei servizi di directory in Windows Server "Longhorn". In Windows Server 2003 si poteva attivare e disattivare la funzionalità di controllo dell'accesso alle directory, ma anche se la si attivava correttamente, l'audit trail non specificava quali informazioni erano state modificate. Ora, invece, tali informazioni sono disponibili.
In Windows Server "Longhorn" il criterio di controllo per ADDS è dotato delle quattro sottocategorie seguenti:
- Accesso al servizio directory
- Modifiche servizio directory
- Replica servizio directory
- Replica dettagliata servizio directory
I professionisti IT devono tenere conto di due aspetti fondamentali relativi a queste modifiche. In primo luogo, il controllo dell'accesso al servizio di directory fornisce essenzialmente le stesse informazioni che forniva in Windows Server 2003, ma l'ID evento è stato modificato da 566 a 4662. Prendere nota di questa modifica se si utilizzano degli strumenti per l'analisi del registro degli eventi di protezione. In secondo luogo, la nuova categoria Modifiche servizio directory registra sia il valore precedente che quello attuale dell'attributo modificato.
Per implementare il controllo in ADDS, utilizzare il criterio di controllo globale, gli elenchi di controllo di accesso di sistema (SACL, System Access Control List) e lo schema ADDS. Questi componenti interagiscono tra di loro per garantire una struttura di controllo flessibile e completa.
Il criterio di controllo globale verifica se vengono eseguiti controlli su ADDS. Se è attivata la funzionalità di controllo, il controllo globale verifica quali fra le quattro sottocategorie di accesso (menzionate prima) vengono controllate. Il criterio di controllo globale viene applicato di solito all'oggetto Criteri di gruppo dei controller di dominio predefiniti, il che significa che viene applicato all'intera directory del controller di dominio.
Anche se gli strumenti Criteri di gruppo possono attivare e disattivare il criterio di controllo globale, si deve utilizzare lo strumento da riga di comando Auditpol.exe per visualizzare e configurare le sottocategorie. Queste, infatti, non sono esposte nell'interfaccia utente grafica.
Un SACL appartiene al descrittore di protezione di un oggetto. Quando si specificano le voci nel SACL, si rendono disponibili nel sistema le seguenti informazioni: quali azioni e quali utenti (o entità di protezione) si considerano rilevanti. In altre parole, si specifica quali tentativi di esecuzione di determinate azioni da parte di determinati utenti devono essere registrati nel registro eventi. Quindi, se si desidera registrare le modifiche apportate agli oggetti Utente dal gruppo Domain Admins ma non dagli utenti stessi, si può farlo con i SACL. Un SACL viene applicato a un oggetto (e può essere definito per nuovi oggetti ed ereditato da oggetti contenitore).
Si può anche configurare lo schema ADDS in modo che il controllo delle modifiche venga limitato a determinati attributi. Poiché i SACL vengono applicati all'oggetto per impostazione predefinita, vengono registrati l'accesso e le modifiche a qualsiasi attributo. Questo comportamento potrebbe generare una notevole attività di registrazione e forse non tutti gli attributi sono degni d'attenzione. Si può perciò impostare, a livello di attributo, un flag per evitare che vengano registrate le modifiche apportate a un attributo.
SearchFlags è un attributo definito nella classe di definizione degli attributi: è pertanto un attributo di un attributo. È anche una maschera di bit in cui ciascun bit con un valore di un byte rappresenta una diversa impostazione di attivazione/disattivazione. Forse è più semplice pensare a SearchFlags come alla proprietà di un attributo. In Windows Server 2003, sette di questi valori sono utilizzati per controllare diverse impostazioni, comprese l'indicizzazione e la replica GC (Global Catalog, Catalogo globale) dell'attributo. In Windows Server "Longhorn" l'ottavo bit (con un valore di 128) è utilizzato per controllare se le modifiche vengono registrate o meno. Se questo bit è impostato, ADDS non registrerà gli eventi di modifica quando le modifiche vengono apportate a quell'attributo. Questo comportamento viene applicato a tutti gli oggetti che contengono l'attributo. Nella versione Beta 2 non è possibile utilizzare l'interfaccia utente grafica per impostare l'ottavo bit.
In Windows Server "Longhorn" il criterio di controllo globale è attivato per impostazione predefinita e Modifiche servizio directory è impostato per la registrazione delle modifiche apportate in modo corretto.
ADDS riavviabile
In Windows Server "Longhorn", ADDS è un servizio riavviabile. Questo significa semplicemente che i servizi ADDS possono essere arrestati e avviati senza riavviare il controller di dominio. Ciò consente agli amministratori di eseguire operazioni che non potrebbero essere eseguite quando il servizio è attivo (come la deframmentazione non in linea del database) in maniera più semplice e senza entrare in Modalità di ripristino servizi di directory.
Un controller di dominio che esegue Windows Server "Longhorn" può avere tre stati: ADDS avviato, ADDS interrotto e Modalità di ripristino servizi di directory. Esaminiamoli.
ADDS avviato Il controller di dominio funziona normalmente.
ADDS arrestato Il server ha le caratteristiche sia di un controller di dominio in Modalità di ripristino servizi di directory sia di un server membro di dominio.
In Modalità di ripristino servizi di directory, il database ADDS (Ntds.dit) non è in linea. La password di Modalità di ripristino servizi di directory può essere utilizzata per effettuare l'accesso locale se non è possibile contattare un altro controller di dominio per accedere al dominio.
In un server membro, il server appartiene al dominio. Gli utenti possono effettuare l'accesso in modo interattivo o in rete utilizzando un altro controller di dominio per accedere al dominio. Un controller di dominio non dovrebbe però rimanere in questo stato per un periodo prolungato perché non può gestire le richieste di accesso né eseguire le attività di replica con altri controller di dominio.
Modalità di ripristino servizi di directory Questa modalità (o stato) non ha subito modifiche rispetto a quella disponibile in Windows Server 2003.
Il diagramma di flusso in figura 6 mostra come un controller di dominio che esegue Windows Server "Longhorn" può passare da uno qualsiasi dei tre stati all'altro.
Figura 6.** Un controller di dominio Windows Server 'Longhorn' può passare da uno qualsiasi dei tre stati all'altro **
Per saperne di più
È impossibile spiegare approfonditamente in un breve articolo le nuove funzionalità ADDS di Windows Server "Longhorn". È chiaro comunque che le novità introdotte in Active Directory risolveranno numerosi problemi che in passato dovevano essere aggirati o semplicemente tollerati. Con l'avvicinarsi della data di rilascio della versione finale del prodotto, il lettore che desidera ricevere ulteriori informazioni potrà consultare la documentazione che verrà man mano pubblicata. Per il momento, la risorsa ottimale per trovare gli aggiornamenti relativi alla fase beta è il sito Web di Windows Server "Longhorn".
Byron Hynes fa parte del team Windows Server User Assistance di Microsoft. In passato ha lavorato come consulente e istruttore e vanta, tra le numerose esperienze, la gestione di un backbone Internet regionale, la risoluzione dei problemi delle applicazioni client-server e Web e la progettazione di schemi di database, infrastrutture di rete e modelli di protezione. È possibile contattarlo all'indirizzo bhynes@microsoft.com.
© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.