Amministrazione di Windows

Delega dell'autorità in Active Directory

Joel Yoker and Rob Campbell

Panoramica:

• Definizione dei ruoli amministrativi
• Sviluppo di un modello dell'unità organizzativa e dei gruppi di protezione
• Uso degli account secondari
• Strumenti per la delega dei diritti

Le funzionalità di delega in Active Directory sono molto potenti, risolvono numerosi problemi di protezione e semplificano le attività di gestione. Delegando adeguatamente i diritti in Active

Directory® è possibile applicare ruoli specificati nell'ambiente, limitare l'impatto e la probabilità di errori amministrativi, nonché applicare il principio del privilegio minimo in tutta l'infrastruttura. Nonostante questo, molte delle organizzazioni che utilizzano Active Directory non sfruttano ancora il potere della delega. Ciò è dovuto in parte al fatto che lo sviluppo di un modello di delega in Active Directory per l'organizzazione appare a prima vista piuttosto complicato. Da una parte, il maggiore ostacolo è sviluppare un modello di delega adatto alle esigenze specifiche dell'organizzazione; ma in realtà esistono modelli molto semplici che possono essere applicati con poche modifiche alla maggior parte delle infrastrutture IT.

Anche se ogni ambiente è diverso in qualche modo, in realtà la maggior parte delle grandi organizzazioni sono simili per molti aspetti e devono affrontare le stesse problematiche nel campo IT. Ad esempio, molte organizzazioni sono divise in regioni geografiche, si sono sviluppate da team di progettazione o assistenza IT separati e hanno unità aziendali indipendenti. Inoltre, molte grandi organizzazioni devono affrontare questioni come l'escalation dei privilegi, l'uso scorretto degli account di servizio e l'"attendibilità".

"Attendibilità" è un termine interessante che spesso viene usato per giustificare l'esistenza di insiemi di strutture di Active Directory multiple. I problemi relativi all'attendibilità derivano spesso dalla capacità di una divisione o di una regione di incidere sulla disponibilità del sistema di un'altra divisione o regione. Spesso i livelli di competenze sono diversi nelle varie suddivisioni dell'organizzazione e manca una conoscenza approfondita dei sistemi specifici necessari per supportare una determinata regione o Business Unit. Di conseguenza le divisioni solitamente non vogliono rinunciare ai propri diritti amministrativi a favore di un gruppo centrale.

Nel frattempo, per qualsiasi implementazione di Active Directory, gli amministratori devono definire le regole di base per le applicazioni che utilizzano l'infrastruttura di Active Directory. Purtroppo un approccio comune, spesso citato nelle guide di installazione delle applicazioni consiste nell'assegnare a un account di servizio l'appartenenza al gruppo Domain Admins. Il problema di questo approccio è che gli account di servizio sono essenzialmente account generici. Concedendo questi diritti di amministratore del dominio si crea un rischio significativo per l'ambiente IT. Gli account di servizio possono facilmente essere utilizzati in modo scorretto dagli amministratori, per errore o intenzionalmente, o essere utilizzati per attacchi che sfruttano i problemi di sicurezza sottostanti all'interno di un'applicazione.

Anche se questi ostacoli possono sembrare insormontabili, essi rappresentano uno scenario perfetto per l'implementazione di un modello di delega in Active Directory. Lo sviluppo di un modello di delega è un processo di progettazione iterativo, in cui è consigliabile seguire questa procedura:

1. Definire i ruoli amministrativi IT all'interno dell'organizzazione.
2. Sviluppare un modello per unità amministrative e gruppi di protezione.
3. Definire gli account secondari per gli amministratori IT.
4. Delegare i diritti.

Esaminiamo ora nei dettagli i vari passaggi.

Definire i ruoli

Il processo di definizione dei ruoli deve partire da una comprensione totale dell'amministrazione dei servizi e dei dati. Questi concetti sono l'elemento fondamentale di qualunque modello di delega in Active Directory.

Essenzialmente, per amministrazione dei servizi si intende la gestione dei componenti critici del servizio directory, come i controller di dominio e i server Exchange. Per amministrazione dei dati si intende la gestione di oggetti che risiedono in questi servizi, come le cassette postali e gli account utente. Per quanto riguarda Active Directory, gli amministratori dei servizi sono responsabili in ultima analisi della fornitura e disponibilità dei servizi directory, mentre gli amministratori dei dati gestiscono account di utenti e server, gruppi e altre risorse del dominio.

Active Directory supporta la delega granulare dell'autorità attraverso le unità organizzative. Le unità amministrative spesso possono essere costruite su misura per fornire agli amministratori lo stesso livello di autorità disponibile all'interno dei modelli esistenti di servizio directory o di dominio. Ma è importante capire che alcune funzioni non possono assolutamente essere delegate e devono essere gestite da un singolo gruppo o entità affidabile.

Anche l'analisi delle attività è molto importante. È necessario sapere quali attività di Active Directory sono eseguite dagli amministratori e in che modo tali attività corrispondono ai ruoli. Ad esempio, la creazione di sito di Active Directory è un'attività di amministrazione dei servizi, mentre la modifica dell'appartenenza al gruppo di protezione generalmente rientra nell'amministrazione dei dati. Ogni attività deve essere valutata dal punto di vista della frequenza, dell'importanza e della difficoltà. Questi sono aspetti fondamentali della definizione delle attività, perché determinano l'opportunità o meno di delegare un diritto. Le attività più adatte alla delega sono quelle che vengono eseguite regolarmente, presentano rischi limitati e sono facili da eseguire. Al contrario, le attività che vengono eseguite raramente, che hanno notevoli effetti in tutta l'organizzazione e che richiedono competenze di alto livello, sono poco adatte alla delega. La soluzione appropriata per queste attività è invece l'escalation, ossia l'elevazione temporanea di un account al ruolo richiesto o la riassegnazione dell'attività.

Poiché le grandi organizzazioni hanno molte caratteristiche simili, solitamente è possibile implementare un modello di delega comune. Ai fini di questo articolo, forniremo una serie di ruoli campione che consentono le funzionalità di gestione e, allo stesso tempo, rispettano i confini dell'organizzazione e cercano di limitare i problemi legati all'attendibilità, come ad esempio la disponibilità di risorse applicabili all'intera organizzazione quali i controller di dominio. Tenere presente che questo modello è solo un esempio: è ideale per avviare la discussione sui ruoli all'interno dell'organizzazione in cui si lavora, ma non sarà necessario seguire alla lettera queste indicazioni.

Alcuni ruoli sono già definiti da Active Directory, mentre altri devono essere creati da zero per completare il modello di delega. Una serie di ruoli campione adatta a molti grandi ambienti di Active Directory potrebbe includere Enterprise Admins, Domain Admins e amministratori di livello 4 per l'amministrazione dei servizi, e amministratori di livello 3, amministratori regionali e amministratori di livello 2 e di livello 1 per l'amministrazione dei dati. Vedere la Figura 1 per un elenco di questi ruoli con le rispettive responsabilità.

Figure 1 Definire ruoli e responsabilità

Amministratori dei servizi

Esaminiamo ora nel dettaglio i ruoli degli amministratori dei servizi. Gli amministratori dei servizi gestiscono i componenti critici dell'infrastruttura e tutti gli amministratori compresi in questa categoria hanno molti privilegi. In questo caso quindi è decisamente consigliata una strategia di privilegio minimo, che significa concedere solo le autorizzazioni necessarie per eseguire le attività richieste.

Enterprise Admins e Domain Admins. Active Directory definisce due gruppi di amministratori speciali il cui contesto di protezione è necessario per funzioni critiche all'interno della directory. I gruppi Enterprise Admins e Domain Admins sono responsabili dell'amministrazione dei servizi principale. Per ridurre i rischi associati a gruppi con tali privilegi, è consigliabile limitare strettamente l'appartenenza a questi gruppi. In pratica, il gruppo Enterprise Admins non deve avere membri permanenti, mentre il gruppo Domain Admins deve contenere solo un numero ridotto e facilmente gestibile di individui di fiducia che lavorano a tempo pieno per l'organizzazione.

Quando devono essere eseguite attività di amministrazione dell'organizzazione, come l'autorizzazione del server DHCP o la creazione del sito di Active Directory, i Domain Admins nel dominio principale dell'insieme di strutture di Active Directory possono aumentare i privilegi attraverso la gestione dell'appartenenza al gruppo Enterprise Admins. Questi privilegi devono essere concessi solo per brevi periodi, per evitare la creazione di membri permanenti del gruppo Enterprise Admins. Naturalmente tutti i membri di un gruppo Domain Admins in un insieme di strutture di Active Directory devono essere ugualmente affidabili.

Un errore commesso dalla maggior parte delle organizzazioni nello sviluppo di un modello di delega consiste nel disattivare o ridurre l'efficacia di questi ruoli incorporati. La modifica dei ruoli predefiniti può causare risultati imprevedibili; inoltre non vi sono garanzie che tali impostazioni vengano mantenute dalle revisioni dei Service Pack o dagli aggiornamenti dei prodotti. In più, questo tipo di modifica crea un ambiente non supportato al di fuori dell'organizzazione. Un approccio pratico consiste nell'utilizzare i gruppi e i ruoli incorporati ma limitarne l'appartenenza. A tal fine, sarà necessario probabilmente creare nuovi ruoli per gli amministratori che in precedenza utilizzavano l'appartenenza a gruppi come Domain Admins.

Tier4 Admins. Il gruppo Tier4 Admins dovrà comprendere amministratori dei servizi centralizzati che forniscono assistenza per tutti i servizi dell'organizzazione. Poiché questo è un ruolo creato, le autorizzazioni di accesso al servizio directory e al sistema possono essere adattate perfettamente alle esigenze specifiche dell'organizzazione. I membri di questo gruppo sono amministratori dei servizi, ma possono a volte eseguire anche attività di gestione dei dati a livello dell'insieme di strutture. Poiché vi sono molte classi di sistemi e aree diverse di responsabilità, i ruoli Tier4 sono suddivisi in vari sottogruppi nella directory. Ad esempio, è bene creare gruppi Tier4 separati per fornire la gestione separata di sistemi specifici, come i server Exchange. Questo gruppo serve anche da punto di escalation per gli amministratori dei dati.

Un motivo per cui spesso gli utenti vogliono appartenere al gruppo Domain Admins è per ottenere diritti amministrativi su ogni sistema in un dato dominio. Il sistema per mantenere questi amministratori di servizio in un contesto di privilegio minimo è assegnare a Tier4 Admins il controllo dei server dell'organizzazione senza renderli Domain Admins. Per evitare l'escalation dei privilegi, a Tier4 Admins non deve essere concessa l'appartenenza al gruppo BUILTIN\Administrators sui controller di dominio, dato che tale gruppo dispone di molti diritti sottostanti al servizio directory che non possono essere separati. Ad esempio, un membro del gruppo BUILTIN\Administrators di un dato dominio può gestire l'appartenenza al gruppo Domain Admins, consentendo ai membri un'escalation dei privilegi senza controlli e valutazioni.

Il rischio di ridurre l'efficacia delle autorizzazioni predefinite può essere ridotto rendendo i gruppi Tier4 membri nidificati dei gruppi di dominio incorporati, Server Operators e DNS Admins. Questo consente la gestione locale dei controller di dominio e allo stesso tempo limita la capacità di escalation dei privilegi da parte di Tier4 Admins. Per la maggior parte dei sistemi (ad eccezione di controller di dominio, server dei certificati e così via), il gruppo Tier4 Admins dovrà essere membro del gruppo Administrators locale. È possibile automatizzare l'appartenenza nidificata ai gruppi locali tramite la funzionalità Gruppi con restrizioni in Criteri di gruppo.

Amministratori dei dati

Esaminiamo ora i ruoli di amministrazione dei dati. Questi dovranno essere progettati con diritti cumulativi, ossia in modo che un gruppo Tier2 Admin abbia tutti i diritti di un gruppo Tier1 Admin con in più alcuni privilegi aggiuntivi, e così via. Per questo motivo analizzeremo questi gruppi a partire dal basso.

Tier1 Admins. Il gruppo Tier1 Admins deve fornire la gestione generale degli oggetti di directory creati in precedenza. Questo gruppo comprende gli amministratori meno esperti o chi effettua attività isolate, come la reimpostazione delle password. Concedere a questo gruppo i diritti necessari all'interno della propria unità organizzativa per modificare le proprietà degli account utente, reimpostare le password degli account utente, sbloccare gli account, attivare/disattivare gli account utente, aggiungere e azzerare gli account delle workstation e modificare l'appartenenza all'oggetto gruppo per i gruppi non amministrativi.

Tier2 Admins. Questo gruppo deve consentire la gestione e la creazione selettiva di oggetti, consentendo la creazione degli oggetti solo quando questi possono essere gestiti da Tier1 Admins. Ad esempio, i gruppi di protezione possono essere creati solo nell'unità organizzativa Gruppi. Tier2 Admins può aggiungere e modificare gli account Tier1 Admins; aggiungere, modificare ed eliminare gli account utente per un'unità organizzativa; eliminare gli oggetti Workstation; aggiungere, modificare ed eliminare gli oggetti Server, Contatto e Cartella condivisa.

Regional Admins. Questo gruppo dispone di diritti esclusivi sulla struttura dell'unità organizzativa locale. Pertanto, non può gestire altre strutture di unità organizzative regionali all'interno della directory. Gli account Regional Admin devono essere considerati altamente privilegiati e, di conseguenza, vengono memorizzati in una gerarchia di unità organizzative separata e gestiti dagli amministratori dei servizi Tier4 Admin. Regional Admins può creare la maggior parte degli oggetti senza restrizioni all'interno della struttura dell'unità organizzativa (con l'eccezione significativa della creazione di altre unità organizzative), il che comporta il rischio aggiuntivo di creare oggetti non gestibili dai livelli inferiori.

Tier3 Admins. Molte organizzazioni hanno un supporto tecnico centralizzato o di livello superiore. Questo ruolo completa l'elenco degli amministratori dei dati e fornisce un gruppo di amministratori dei dati per tutti i Regional Admins. I diritti non sono delegati specificamente a questi gruppi all'interno della directory; vengono invece assegnati attraverso l'appartenenza nidificata a ogni gruppo di Regional Admin. Questo fornisce un punto di escalation di livello superiore per tutti gli amministratori dei dati e un punto di ingresso per i problemi da trasferire ai gruppi di amministrazione dei servizi.

Sviluppare un modello di unità organizzativa e di gruppi di protezione

Una volta definiti i ruoli nell'organizzazione, è necessario definire un modello dell'unità organizzativa e dei gruppi di protezione. Vi sono due motivi principali per creare un'unità organizzativa in Active Directory: delegare i diritti e creare un punto a cui possono essere collegati gli oggetti Criteri di gruppo. Le unità organizzative definiscono un ambito di gestione all'interno della directory e possono essere utilizzate per limitare i diritti agli oggetti a vari livelli. Di conseguenza, il modo in cui si decide di delegare l'autorità dovrà essere uno dei fattori principali nella scelta di come implementare la struttura delle unità organizzative.

Tenendo presente questo fatto, sarà necessario creare un'unità organizzativa (o una serie di unità organizzative) di primo livello subito sotto il dominio che conterrà tutti gli oggetti. Questa unità organizzativa ha lo scopo specifico di definire l'ambito di gestione di massimo livello per Tier4 Admins. Creando un'unità amministrativa di primo livello, i diritti sul servizio directory possono iniziare esplicitamente a livello dell'unità amministrativa piuttosto che a livello di dominio. La delega da un'unità organizzativa di primo livello invece che dal dominio riduce il rischio che gli utenti possano effettuare un'escalation dei privilegi manipolando i gruppi di dominio incorporati come osservato in precedenza.

Sotto alle unità organizzative di primo livello si dovranno creare gerarchie separate di unità organizzative secondarie che rappresentino ogni regione o unità aziendale dotata di un team di amministrazione dei dati separato. Ogni unità organizzativa secondaria regionale dovrà avere una gerarchia di unità organizzative comune non estensibile per la gestione degli oggetti di directory. L'uniformità è essenziale per la gestione continuativa, dato che gran parte della delega dei diritti verrà automatizzata. Questo non è un compito facile, dato che ogni regione potrebbe volere unità organizzative specifiche. Ma gli amministratori IT devono tenere duro; se un'estensione è necessaria per una regione, la struttura dell'unità organizzativa secondaria dovrà essere estesa per tutte le regioni. Questo può sembrare difficile all'inizio, ma se l'organizzazione offre un alloggiamento generico per gli oggetti, col tempo le situazioni anomale tendono a risolversi.

Infine, creare gruppi e account di amministrazione secondari separati per rimuovere la possibilità di escalation dei privilegi degli amministratori: un gruppo Tier1 Admins, uno Tier2 Admins e uno Regional Admins per ogni gerarchia di unità organizzative secondarie. Collocando questi account in unità organizzative separate è possibile limitarne l'amministrazione al proprio livello e ai livelli inferiori. In questo modo, se tutti gli account Tier1 Admins e il gruppo di protezione associato risiedono in un'unità organizzativa in cui non hanno diritti, gli amministratori non saranno in grado di impadronirsi di altri account amministrativi o aumentare i privilegi di altri amministratori portandoli al proprio livello. Qualunque membro del gruppo Domain Admins, ad esempio, può fare di qualsiasi altro account utente nel dominio un Domain Admin. Tuttavia, adottando questo modello di unità organizzative si riduce tale rischio. La Figura 2 mostra un esempio di struttura di unità organizzative con i gruppi di protezione associati.

Figura 2** Struttura di unità organizzative e gruppi di protezione associati **

Definire gli account secondari

L'elemento chiave per il successo di un modello di delega è l'applicazione del principio di privilegio minimo. In pratica questo significa che un'entità di protezione deve avere solo la capacità di eseguire le attività richieste per il ruolo assegnato e niente di più. Purtroppo molti amministratori IT utilizzano la stessa entità di protezione per l'amministrazione di directory e per le attività quotidiane come l'esplorazione del Web e la lettura della posta elettronica. La creazione di account separati riduce la probabilità che un amministratore nel sistema a più livelli danneggi il servizio directory per errore o sia vittima di un attacco effettuato attraverso applicazioni di uso quotidiano ma diretto all'amministratore della directory.

Per fare ciò senza che l'utente debba disconnettersi ed eseguire nuovamente l'accesso, si usa il servizio Accesso secondario (Runas.exe). Questo consente agli utenti di aumentare i propri privilegi fornendo un insieme di credenziali diverse durante l'esecuzione di script o eseguibili su server e workstation.

Anche se il concetto di utilizzare account con privilegi minimi è in sé abbastanza semplice, le organizzazioni a volte trovano difficile applicarlo, perché le vecchie abitudini informatiche possono essere difficili da cambiare. Un modo semplice per impedire l'uso degli account privilegiati per le attività quotidiane è non fornire a tali account accesso alla posta in Exchange Server, implementando questo approccio tramite un criterio amministrativo all'interno dell'organizzazione. Questo approccio relativamente semplice riduce notevolmente la probabilità che tali account vengano utilizzati per le attività non amministrative di routine.

Delegare i diritti.

Il passaggio finale nello sviluppo di un modello di delega è l'effettiva delega dei diritti all'interno di Active Directory. Questo comporta la manipolazione delle voci di controllo di accesso (ACE) e degli elenchi di controllo degli accessi (ACL) sui dati memorizzati nella directory. Gli ACL nei contenitori Active Directory definiscono quali oggetti possono essere creati e come verranno gestiti. La delega dei diritti comporta operazioni di base sugli oggetti, come la capacità di visualizzare un oggetto, creare un oggetto figlio di una classe specificata o leggere le informazioni su attributi e protezione in relazioni agli oggetti di una classe specificata. Oltre a queste operazioni di base, Active Directory definisce autorizzazioni estese, che consentono operazioni quali Invia come e Gestione topologia di replica.

Ai punti precedenti sono è stata esaminata la creazione di gruppi di protezione corrispondenti a ruoli organizzativi definiti. Questo significa che per ogni ruolo esiste un gruppo di protezione associato in base alla struttura di unità organizzativa secondaria. Per implementare il modello di delega, a questi gruppi devono essere assegnate autorizzazioni sugli oggetti della directory. A questo punto del processo, non è il caso di partire da zero e creare un ambiente altamente personalizzato. È invece meglio sfruttare ovunque possibile i gruppi e i diritti incorporati. Se, ad esempio, un determinato ruolo deve poter gestire i record DNS per l'insieme di strutture, non si cerchi di delegare diritti su contenitori e contesti di denominazione correlati al DNS integrato di Active Directory; sarà sufficiente utilizzare il gruppo BUILTIN\DNS Admins del dominio. In più, diritti utente e altre autorizzazioni possono essere estesi attraverso Criteri di gruppo per fornire le autorizzazioni aggiuntive necessarie a un dato ruolo per gestire una classe specifica del sistema.

Durante l'assegnazione di autorizzazioni mediante la delega, è necessario limitare o eliminare completamente l'uso di ACE di negazione all'interno della directory, che possono creare difficoltà al momento di individuare e risolvere i problemi. Un approccio migliore consiste nell'utilizzare ACE di autorizzazione espliciti per concedere autorizzazioni ai gruppi personalizzati che rappresentano i ruoli definiti. Tenere presente che i ruoli definiti dall'utente, come Tier4 Admins, hanno solo i diritti espliciti definiti dal ruolo stesso.

L'ereditarietà è fondamentale per la protezione di Active Directory e definisce il modo in cui un determinato ACL si applica agli oggetti figli in un dato contenitore principale o secondario. È importante essere sempre specifici nel definire l'ambito dell'ereditarietà, assicurandosi che gli ACE ereditabili siano applicati il più vicino possibile agli oggetti di destinazione. Le autorizzazioni di negazione ereditabili applicate all'oggetto padre avranno la precedenza su eventuali autorizzazioni di negazioni ereditabili applicati all'oggetto padre del padre, uno dei motivi principali per cui si sconsiglia l'uso di ACE di negazione per la delega pratica. Inoltre, le autorizzazioni ereditabili non possono ignorare un ACE esplicito su un oggetto. Per questo motivo si consiglia di limitare o eliminare la capacità degli amministratori nel sistema a livelli di modificare l'elenco di controllo di accesso discrezionale (DACL) sugli oggetti di directory, rimuovendo il privilegio di scrittura del DACL. (Si noti che il creatore dell'oggetto dispone implicitamente di questi diritti). La regola generale è che se un amministratore ha la capacità di modificare il DACL su un oggetto, probabilmente lo farà. Sarebbe un peccato se tutto il lavoro dell'organizzazione per implementare il modello di delega andasse sprecato con l'introduzione di elementi di scelta e potenziali errori amministrativi.

Per implementare correttamente un modello di delega in Active Directory sarà necessario utilizzare vari strumenti. Per la maggior parte delle grandi organizzazioni, utilizzare la procedura guidata di impostazione deleghe per assegnare le autorizzazioni nella directory rappresenta un compito enorme che offre molte possibilità di errori amministrativi. Invece si dovrà sempre utilizzare l'automazione per garantire che il modello di delega sia ben documentato, che sia supportabile e che fornisca un'opzione di ripristino nel caso in cui le impostazioni vengano in qualche modo perdute o modificate involontariamente.

Lo strumento principale necessario per implementare la delega è DSACLS.EXE, uno strumento da riga di comando utilizzato per manipolare gli ACL del servizio directory sugli oggetti. Questo strumento consente anche di specificare sull'oggetto padre i flag di eredità per un DACL. (I flag di eredità includono questo oggetto e i relativi oggetti secondari, solo gli oggetti secondari e distribuiscono le autorizzazioni ereditabili per un solo livello. I comandi DSACLS produrranno prima o poi errori se un flag di eredità è impostato in modo scorretto, quindi il testing è indispensabile quando si usa questo strumento. Ecco un esempio della sintassi di DSACLS per delegare la capacità di creare oggetti computer nell'unità organizzativa di destinazione di esempio:

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS distingue tra maiuscole e minuscole in relazione ai tipi di oggetto. Questo significa che non sarà possibile delegare le autorizzazioni per la classe di oggetti "cn=Computer" su "cn=computer" (vedere la Figura 3).

Figura 3** Errore dovuto alla differenza tra maiuscole e minuscole **(Fare clic sull'immagine per ingrandirla)

Per creare alcuni oggetti è necessaria una serie specifica di diritti. Questo dipende dalla differenza tra gli attributi "must-contain" e "may-contain" degli oggetti. La metafora migliore per spiegare questo concetto è quella dell'hamburger. Per essere considerato tale, un hamburger deve contenere una polpetta di carne e un panino. Questi sono gli attributi "must-contain" della classe di oggetti hamburger. Le altre cose, come sottaceti, ketchup, lattuga e così via, sono attributi "may-contain". Se si estende la classe di oggetti in modo da definire un cheeseburger, si dovrà aggiungere il formaggio all'elenco degli attributi "must-contain".

Gli oggetti utente funzionano allo stesso modo. Si supponga di seguire questo modello per creare oggetti utente utilizzando la seguente sintassi di DSACLS:

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

L'amministratore incontrerebbe vari errori durante la creazione dell'oggetto utente. È necessario assegnare i privilegi necessari per impostare gli attributi richiesti sull'oggetto utente, compresa l'impostazione della password. Questo è descritto nella seguente sintassi di DSACLS aggiuntiva.

Per prima cosa, assegnare i privilegi di scrittura degli attributi "deve contenere" assegnando Lettura generica/Scrittura generica a tutti gli attributi della classe utente:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

Quindi assegnare il diritto esteso di modificare la password:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

Infine assegnare il privilegio di lettura e scrittura proprietà dell'attributo Ultima impostazione password:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

Una volta delegati i diritti appropriati, i ruoli definiti saranno limitati alla sola gestione delle classi di oggetti definite nel DACL del contenitore. Utilizzando l'esempio di oggetto computer precedente, il menu contestuale in Utenti e computer di Active Directory limita l'elenco di nuovi oggetti che possono essere creati dall'utente a cui sono delegati tali diritti: vedere l'elenco limitato nella Figura 4.

Figura 4** Elenco limitato di oggetti nuovi **

DSACLS può anche essere automatizzato per fornire una distribuzione complessa dei diritti. Ecco alcuni comandi di DSACLS che possono essere utilizzati per delegare i diritti a manipolare attributi degli indirizzi comuni sugli oggetti utente di un determinato contenitore:

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

Esempi di questo tipo sono comuni nella maggior parte dei modelli di delega e possono essere utilizzati insieme ai ruoli definiti in precedenza.

Un altro strumento utilizzato per l'implementazione della delega è DSREVOKE.EXE, che consente agli amministratori di individuare e rimuovere diritti delegati per specifiche entità di protezione su oggetti nella directory. Questo strumento può essere molto utile, ma si applica a una specifica entità di protezione e non valuta l'appartenenza nidificata all'interno dei gruppi di protezione.

Oltre a questi strumenti della riga di comando, si consiglia di utilizzare anche Assegnazione diritti utente e Gruppi con restrizioni con i Criteri di gruppo. Come si è visto in precedenza, Assegnazione diritti utente consente agli amministratori IT di estendere o rimuovere diritti di basso livello, come il diritto ad accedere e riavviare un sistema in modalità remota, per vari gruppi di utenti su sistemi di destinazione specifici. I Gruppi con restrizioni possono essere utilizzati per specificare e applicare l'appartenenza a gruppi locali e di dominio nell'insieme di strutture. Insieme, questi strumenti forniscono tutto il necessario per automatizzare e implementare un modello di delega in Active Directory.

Riepilogo

Anche se il compito di sviluppare un modello di delega in Active Directory può sembrare complesso, in realtà modelli molto semplici possono essere applicati alla maggior parte delle infrastrutture IT. Una delle fasi più importanti nella distribuzione di un modello di delega pratico è la definizione di ruoli chiari. È bene limitarsi a definire un numero ristretto e gestibile di ruoli. Si tratta di un equilibrio delicato: se ci sono troppi ruoli, alcuni non verranno utilizzati, mentre se ce ne sono troppo pochi non sarà possibile mantenere la separazione dei ruoli.

Durante la definizione delle attività, ricordarsi di suddividerle in base alla frequenza, all'importanza e alla difficoltà. Una volta definiti i ruoli, sviluppare una serie di casi d'uso per identificare più facilmente ciò che ogni ruolo può o non può fare e automatizzare il processo di testing. I casi d'uso adeguatamente preparati aiuteranno a spiegare i ruoli agli interessati nell'organizzazione e a ridurre le sorprese causate da errori di automazione.

Infine, è sempre bene adottare un approccio pratico nello sviluppare un modello di delega. Semplicità significa facilità di supporto, e un modello di delega sostenibile ripagherà abbondantemente il lavoro necessario facilitando il controllo dei diritti amministrativi all'interno dell'ambiente Active Directory.

Ulteriori riferimenti

• Design Considerations for Delegation of Administration in Active Directory (in inglese)
• Best Practices for Delegating Active Directory Administration (in inglese)

Joel Yoker è un consulente senior del team federale Microsoft. Joel e Rob si occupano dello sviluppo e della distribuzione di soluzioni di protezione per clienti nel governo federale degli Stati Uniti.

Rob Campbell è uno specialista tecnico senior del team federale Microsoft. Joel e Rob si occupano dello sviluppo e della distribuzione di soluzioni di protezione per clienti nel governo federale degli Stati Uniti.

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