Considerazioni sulla progettazione della delega dell'amministrazione in Active Directory (it-IT)

L'originale di questo articolo è consultabile al seguente uri :  http://social.technet.microsoft.com/wiki/contents/articles/design-considerations-for-delegation-of-administration-in-active-directory.aspx

Questo articolo è basato su un documento di Microsoft TechNet Library ed è presentato qui per permettere di migliorarlo alle persone esterne a Microsoft che sono interessate ed informate su questo argomento. Per leggere l'articolo ufficiale di Microsoft su questo argomento, vedere Considerazioni sulla progettazione della delega amministrativa in Active Directory   sulla libreria TechNet Microsoft .

 

Considerazioni sulla progettazione dellla delega amministrativa in Active Directory (it-IT)

Raggiungere autonomia e isolamento con foreste, domini e unità organizzative

Una funzionalità chiave del servizio directory Active Directory ® in Microsoft ® Windows ® 2000 è la delega dell'amministrazione. Attraverso la delega dell'amministrazione, è possibile progettare un'infrastruttura di directory che si estende su più organizzazioni, consentendo di soddisfare i requisiti specifici per l'indipendenza strutturale ed operativa.

In Active Directory, gli amministratori possono delegare sia la gestione del servizio che la gestione dei dati. La gestione può essere delegata per raggiungere l’autonomia tra le organizzazioni o l’isolamento tra le organizzazioni. In questo white paper vengono illustrate considerazioni sulla progettazione di Active Directory e sulle implicazioni di sicurezza quando si utilizzano le foreste, i domini o le unità organizzative per la delega dell'amministrazione.

In questa pagina

Introduzione
Concetti della delega
Delega dell'amministrazione, con foreste, domini e unità organizzative 
Procedure consigliate per gli amministratori del servizio e limitazioni all'accesso fisico sui controller di dominio
Conclusione 
Appendice – informazioni base per i requisiti di fiducia all'amministratore del servizio e requisiti di accesso fisico ai Domain Controller

Introduzione

Una funzionalità chiave del servizio directory di Active Directory in Microsoft ® Windows ® 2000 è la delega dell'amministrazione. Attraverso la delega dell'amministrazione, un'infrastruttura directory può essere progettata per comprendere più organizzazioni che hanno requisiti di gestione specifici. In particolare, la delega dell'amministrazione di Active Directory può aiutare le organizzazioni a soddisfare requisiti specifici per l'indipendenza strutturale ed operativa.

In Active Directory, gli amministratori possono delegare sia la gestione del servizio che la gestione dei dati. La gestione può essere delegata per raggiungere l’autonomia tra organizzazioni o l’isolamento tra le organizzazioni .Questo documento vengono illustrate considerazioni sulla progettazione di Active Directory e sulle implicazioni di sicurezza quando si utilizzano le foreste, i domini o le unità organizzative per la delega dell'amministrazione.

La discussione si presuppone che il lettore conosca concetti e le procedure associate alla progettazione e distribuzione di Active Directory. Per ulteriori informazioni sulla pianificazione e la distribuzione di Active Directory, vedere la serie di documenti : http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].

Inizio della pagina 

Concetti della delega

Per capire come delegare l'amministrazione di Active Directory, dobbiamo prima capire perché le organizzazioni potrebbero delegare l'amministrazione e i diversi tipi di responsabilità amministrativa che può essere delegata.

Motivi per delegare l’amministrazione

Le organizzazioni in genere delegano l'amministrazione per tre tipi di motivazione :

·    Struttura organizzativa — parti di un'organizzazione potrebbero partecipare a un'infrastruttura condivisa per ridurre i costi, ma richiedere la capacità di operare in modo indipendente dal resto dell'organizzazione.

·    Requisiti operativi — una parte di un'organizzazione o una applicazione che sfrutta l'Active Directory potrebbero porre vincoli  specifici sulla configurazione del servizio di directory, sulla continuità o sulla sicurezza. Esempi si trovano in:

o  Organizzazioni militari

o  Scenari di hosting

o  Scenari extranet oppure di directory esposte al mondo esterno

• Requisiti legali — alcune organizzazioni hanno obblighi normativi che costringono ad operare in modo specifico, ad esempio limitando l'accesso a determinate informazioni. Questi requisiti si applicano comunemente per i tipi di organizzazioni seguenti:

o  Istituzioni finanziarie

o  Appaltatori della difesa

o  Organizzazioni governative

Per tali ragioni, un'organizzazione potrebbe dover delegare il controllo sulla gestione dei servizi, sulla gestione dei dati o entrambi. In base alle esigenze specifiche dell'organizzazione, scopo di tale delega potrebbe essere raggiungere l'isolamento, l'autonomia o entrambi. Un primo passo importante nella progettazione di Active Directory è definire con precisione le esigenze di un'organizzazione basandosi sui concetti di gestione dei servizi, gestione dei dati, autonomia e isolamento. Questi concetti sono definiti qui di seguito.

Gestione del servizio e gestione dei dati

Le responsabilità amministrative che vengono delegate in Active Directory possono essere separate in due tipi: responsabilità per la fornitura del servizio di directory (gestione del servizio) e la responsabilità per i contenuti memorizzati o protetti dal servizio directory (gestione dei dati). Gli amministratori con queste responsabilità sono gli amministratori del servizio o gli amministratori dei dati.

·    Gli amministratori dei servizi — gli amministratori del servizio Active Directory sono responsabili per la configurazione e la distribuzione del servizio directory. Ad esempio, gli amministratori dei servizi mantengono i controller di dominio, controllano le impostazioni di configurazione a livello di directory e sono responsabili di garantire la disponibilità del servizio.

·    Gli amministratori di dati — gli amministratori dati di Active Directory sono responsabili per la gestione dei dati archiviati in Active Directory o nei computer appartenenti ad Active Directory e non hanno alcun controllo sulla configurazione o la distribuzione del servizio directory. Gli amministratori di dati includono:

o  Amministratori che controllano un sottoinsieme di oggetti nella directory. Attraverso il controllo di accesso ereditabile a livello di attributo, agli amministratori di dati può essere concesso il controllo di sezioni molto specifiche della directory, senza avere alcun controllo sulla configurazione del servizio stesso.

o  Amministratori che gestiscono computer membri appartenenti alla directory e i dati archiviati su tali computer.

o  In molti casi, la configurazione del servizio della directory è determinata dai valori degli attributi su oggetti memorizzati nella directory. Di conseguenza, gli amministratori dei servizi di Active Directory sono anche gli amministratori di dati.

Autonomia e isolamento

I requisiti di delegazione di un'organizzazione generalmente rientrano in due categorie: autonomia e isolamento.

·    Autonomia — autonomia è la capacità degli amministratori di un'organizzazione di gestire in modo indipendente:

o  Tutta la gestione del servizio o parte di esso (autonomia dei servizi).

o  Tutti (o parte) dei dati memorizzati nella directory o su computer membri che partecipano alla directory (l'autonomia dei dati).

·    Isolamento — l'isolamento è la capacità degli amministratori di un'organizzazione di impedire ad altri amministratori di:

o  Controllare o interferire con la gestione del servizio (isolamento dei servizi).

o  Controllare o la visualizzare un sottoinsieme di dati nella directory o su computer che partecipano alla directory (isolamento dei dati).

L’autonomia è meno vincolante rispetto all’isolamento. Gli amministratori che richiedono solo autonomia accettano che nel sistema esistano altri amministratori con privilegi uguali o superiori che hanno un controllo equivalente o superiore (al loro). Gli amministratori che richiedono specificamente l’isolamento cercano di bloccare ad altri amministratori la visione o il controllo della loro parte di servizi o di gestione dei dati. Poiché l'autonomia è meno vincolante dell’isolamento, è in genere meno costosa e più efficiente delegare l’autonomia in Active Directory.

La combinazione di gestione dei servizi, gestione dei dati, autonomia e requisiti di isolamento determina quale struttura Active Directory utilizzerà per delegare il controllo di un'organizzazione.

Nota: In molte organizzazioni di piccole o medie dimensioni, non è insolito per tutto i servizi e per tutta la gestione dei dati in Active Directory essere sotto il controllo di un singolo e gruppo IT. Tali organizzazioni che non hanno alcun requisito specifico di autonomia o di isolamento possono utilizzare un foresta unica, un singolo dominio Active Directory e trattare le procedure in questo documento come semplice riferimento.

Inizio della pagina

Delega dell'amministrazione, con foreste, domini e unità organizzative

Tre differenti strutture possono essere utilizzati per delegare l'amministrazione di Active Directory: foreste, domini e unità organizzative (ou). La sezione seguente descrive brevemente le caratteristiche di ogni struttura, e quando è appropriato scegliere una struttura basata su specifici requisiti di delega.

Per ulteriori informazioni sulla progettazione di Active Directory, vedere la serie di documenti : http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].

Foreste, domini e unità organizzative

Per capire la discussione della delega che segue, è utile esaminare brevemente le definizioni e le caratteristiche di gestione delle foreste di Active Directory, domini e unità organizzative.

Una foresta è un insieme di domini con una configurazione e uno schema condivisi, rappresentati da un unico catalogo globale e collegati da una rete completa di trust transitive. Una foresta è rappresentata da un dominio radice della foresta. Il proprietario amministrativo predefinito di una foresta è il gruppo Domain Admins del dominio radice della foresta. Il gruppo Domain Admins del dominio principale controlla l'appartenenza ai gruppi Enterprise Admins e Schema Admins, che, per impostazione predefinita, controllano le configurazioni a livello di foresta. Dato che il proprietario della foresta gestice i controller di dominio, il proprietario della foresta è un amministratore del servizio.

Un dominio è una partizione in una foresta di Active Directory. Il proprietario amministrativo di un dominio è per default il gruppo Domain Admins del dominio. Datosi che  il proprietario del dominio controlla i controller di dominio, il proprietario del dominio è un amministratore del servizio. Tutti i proprietari del dominio non radice in una foresta sono di pari livello, indipendentemente dalla posizione del loro dominio nella gerarchia dei nomi; il proprietario di un dominio padre non radice della foresta non dispone di alcun controllo amministrativo predefinito su un dominio figlio.

Un' unità organizzativa (OU) è un contenitore all'interno di un dominio. Il controllo su una unità organizzativa e gli oggetti in una unità organizzativa cono determinati interamente dalla Access Control List (ACL) sull'unità organizzativa e sugli oggetti nell'unità organizzativa. Utenti e gruppi che hanno il controllo su oggetti in unità organizzative sono amministratori di dati.

Maggiore sarà il numero delle organizzazioni che possono partecipare in una foresta, maggiori sono i possibili benefici dalla collaborazione e i risparmi sui costi. Per questo motivo, è consigliabile ridurre al minimo il numero di foreste in una distribuzione di Active Directory. Tuttavia, ci sono situazioni in cui i requisiti di delega rendono la creazione di più foreste del tutto appropriata.

Ad esempio, nelle organizzazioni dove il controllo amministrativo è estremamente distribuito, può essere impraticabile aspettarsi che tutte le organizzazioni partecipino alla stessa infrastruttura. In queste situazioni, il costo di gestione di un insieme di strutture aggiuntive barattato con la soddisfazione di questa esigenza pratica.

Informazioni su strutture di Directory e proprietari di struttura di Directory

I seguenti fatti riguardo le strutture di Active Directory e gli amministratori sono importanti quando si sceglie una struttura di directory per una delegazione. Per l’utilizzo di queste informazioni in sede di semplice selezione di una struttura, fare riferimento a "Selezionare una struttura basata su requisiti di delega", più avanti in questo documento.

1. **I proprietari del dominio non possono impedire che i proprietari di foreste controllino i loro servizi e abbiano accesso ai loro dati.**Sebbene sia possibile rimuovere l'accesso a un dominio per gli Enterprise Admins, generalmente non è possibile impedire l'accesso agli oggetti in domini non root al proprietario della foresta. Ad esempio, i membri del gruppo Schema Admins (che è controllato dal gruppo Domain Admins del dominio radice della foresta) possono modificare il descrittore di protezione predefinito su una classe di oggetti per concedere il controllo completo al gruppo Enterprise Admins su una classi di oggetti appena creata. Di conseguenza, le organizzazioni che partecipano a una foresta devono concedere fiducia al proprietario della foresta.

2. I proprietari di un dominio mantengono il diritto di accedere ai dati memorizzati in un dominio o ospitato su computer appartenenti a un dominio. Gli amministratori del servizio di un dominio non possono essere esclusi dalla visione o dalla manipolazione dei dati memorizzati in un dominio o sui computer appartenente a un dominio. Questa è una conseguenza delle seguenti caratteristiche di Active Directory:

o  Il gruppo Builtin\Administrators in un controller di dominio può assumere la proprietà di qualsiasi oggetto del dominio e quindi leggere, modificare o cancellare, indipendentemente dalla ACL esistente per l'oggetto. Questa caratteristica dà gli amministratori dei servizi un modo per correggere gli errori nelle ACL applicate agli oggetti. Di conseguenza, le organizzazioni che archiviano i dati in unità organizzative di un dominio devono concedere fiducia al proprietario del dominio.

o  Un amministratore del servizio può modificare intenzionalmente il software di sistema su un controller di dominio per ignorare i controlli di sicurezza normali. Un amministratore del servizio può utilizzare questa procedura per visualizzare o modificare qualsiasi oggetto del dominio, indipendentemente dalla ACL per l'oggetto. Di conseguenza, le organizzazioni che archiviano i dati in unità organizzative di un dominio devono concedere fiducia  al proprietario del dominio.

o  Un amministratore del servizio può utilizzare i criteri di sicurezza dei gruppi con restrizioni per concedere qualsiasi utente o gruppo l'accesso amministrativo a qualsiasi computer del dominio. Questa caratteristica garantisce che un amministratore può sempre ottenere il controllo su un computer del dominio, indipendentemente dalle intenzioni del proprietario del computer. Di conseguenza, le organizzazioni che inseriscono computer in un dominio devono concedere fiducia al proprietario del dominio.

o  Se a un utente o a un gruppo in un dominio viene concesso l'accesso ai dati memorizzati su un computer che fa parte della foresta, il proprietario del dominio dell'utente o del gruppo può reimpostare la password dell'utente o manipolare l'appartenenza al gruppo e così facendo guadagnare l’accesso ai dati. Di conseguenza, le organizzazioni che aggiungere computer a una foresta devono concedere fiducia a ogni proprietario di dominio della foresta.

3. i proprietari del dominio non possono impedire che altri proprietari di dominio malintenzionati controllino i loro servizi e accedano ai loro dati. A causa della natura strettamente legata di una foresta di Active Directory, è possibile che i proprietari del dominio utilizzino metodi malevoli per ottenere l'accesso ad altri domini della foresta. Ad esempio, è possibile che un proprietario di dominio malintenzionato modifichi il software di sistema su un controller di dominio e così facendo interferisca con il funzionamento di un qualsiasi dominio della foresta, veda o manipoli i dati di configurazione della foresta, visualizzi o manipoli i dati memorizzati in un qualsiasi dominio, oppure visualizzi o manipoli i dati memorizzati su qualsiasi computer inserito nella foresta. Pertanto, il proprietario della foresta deve concedere fiducia a tutti i proprietari di dominio in una foresta e tutti i proprietari di dominio in una foresta devono considerarsi attendibili l’un l'altro.

1. Controller di dominio all'interno di una foresta non possono essere isolati tra di loro. A causa della natura distribuita di Active Directory, la violazione della sicurezza di un singolo controller di dominio può avere effetti in tutta una foresta. Ad esempio, è possibile che un utente malintenzionato che ha accesso fisico a un controller di dominio apporti modifiche non in linea al database di directory e così facendo interferisca con il funzionamento di qualsiasi dominio della foresta, visualizzi o manipoli i dati memorizzati in un punto qualsiasi della foresta oppure visualizzi o manipoli i dati memorizzati su qualsiasi computer che della foresta. Di conseguenza, l'accesso fisico ai controller di dominio deve essere limitato a personale di fiducia.

Considerare attendibili gli amministratori dei servizi

Per riassumere le conseguenze delle informazioni (fin qui elencate) sulle strutture di directory e sui proprietari della struttura di directory, un'organizzazione per partecipare a una infrastruttura di dominio o di foresta, deve scegliere di concedere fiducia a tutti gli amministratori dei servizi nella foresta e in tutti i domini. In questo contesto, dare fiducia agli amministratori dei servizi significa:

·    Avere fondati motivi per credere che gli amministratori dei servizi operano nell’interesse dell'organizzazione. Le organizzazioni non dovrebbero entrare in una foresta o in un dominio se i proprietari del dominio o della foresta possono avere motivi legittimi per agire intenzionalmente contro l'organizzazione.

• Avere fondati motivi per credere che gli amministratori dei servizi seguono le procedure consigliate e rispettano le restrizioni dell'accesso fisico ai controller di dominio. Per ulteriori informazioni su queste pratiche, vedere "Procedure consigliate per gli amministratori del servizio e limitazioni all'accesso fisico sui controller di dominio" più avanti in questo documento.

·    Comprendere e accettare i rischi per l'organizzazione associati agli amministratori con intenti criminali e agli amministratori sottoposti a coercizione.

o  Amministratori con intenti criminali  - è sempre possibile che amministratori normalmente affidabili si rivelino malintenzionati e abusino del potere che essi hanno nel sistema.

• • Amministratori sottoposti a coercizione - gli amministratori normalmente affidabili possono essere costretti o indotti a eseguire operazioni che possono violare la sicurezza del sistema.

Alcune organizzazioni potrebbero accettare il rischio di violazioni della sicurezza da amministratori con intenti criminali o dagli amministratori sottoposti a coercizione (che operano) su altre parti dell'organizzazione. Tali organizzazioni potrebbero valutare che il beneficio derivato dalla collaborazione e il risparmio derivati dal partecipare ad un'infrastruttura condivisa prevalgono sul rischio. Tuttavia, altre organizzazioni potrebbero non accettare questo rischio perché le conseguenze di una violazione della sicurezza sarebbero troppo gravi.

Nota: documentazione  precedentemente pubblicata su Active Directory afferma che un dominio è un limite di sicurezza, ma non fornisce dettagli specifici circa il livello di autonomia e isolamento possibile tra domini in una foresta. Anche se un dominio è in realtà un limite di protezione quando si considera gli aspetti della gestione di Active Directory, non fornisce completo isolamento di fronte a possibili attacchi dagli amministratori di servizio che modificano con intenzioni malevole il comportamento del sistema. Per ulteriori informazioni, vedere l'appendice a questo documento.

Selezionare una struttura basandosi sui requisiti di delega

La Figura 1 illustra il processo decisionale per determinare se i requisiti specifici di delega di un'organizzazione giustificano la delega del controllo di una foresta separata, di un dominio o di una unità organizzativa a quell'organizzazione. Per utilizzare il processo, eseguire il seguente esercizio concettuale :

1. Iniziare inserendo tutte le organizzazioni in una foresta con dominio singolo.

2. Per ogni organizzazione con specifici requisiti amministrativi, utilizzare il processo di decisione per determinare il modo appropriato di agire.

3. Quando si prende nota della motivazione per ogni decisione, assicuratevi di osservare :

o  Se il requisito della delegazione è imposto da uno o più requisiti organizzativi, operativi, legali o altro.

o  Se il requisito è per la delega di gestione di un servizio, gestione dei dati o entrambi.

o  Se il requisito è per autonomia, isolamento o entrambi.

Il processo di decisione per la delega dell'amministrazione è illustrato nella figura 1 e discusso in dettaglio in una serie di scenari che seguono l’illustrazione.

Figura 1: Processo per la determinazione dei requisiti di delega per l'organizzazione

Scenario 1: Creazione di foreste per l'isolamento di servizio

Un'organizzazione che ha bisogno di isolamento dei servizi richiede che nessun amministratore al di fuori dell'organizzazione possa interferire con il funzionamento della directory. L'isolamento è in genere imposto da requisiti operativi o giuridici. Per fornire l'isolamento dei servizi, occorre creare una nuova foresta per l'organizzazione.

I requisiti operativi che guidano l'isolamento dei servizi potrebbero includere quanto segue:

·    Una società di produzione potrebbe avere un'applicazione critica abilitata alle Active Directory che controlla un’apparecchiatura utilizzata da diversi operai. Se questa azienda considera il funzionamento delle attrezzature di fabbrica come massima priorità, potrebbe scegliere di creare una singola foresta di tutta la società per le normali funzioni amministrative e una foresta separata per ogni stabilimento critico. In questo modo fabbriche critiche potrebbero continuare ad operare indipendentemente dallo stato della foresta della società e dallo stato di altre fabbriche.

·    Una Marina militare potrebbe richiedere che la cattura di una singola nave non abbia il potenziale di compromettere l’erogazione di servizi per un intero gruppo di battaglia o per l'intera Marina. Per contenere l'impatto della cattura di una singola nave alla nave stessa, la Marina potrebbe creare una foresta separata per ogni nave.

·    Una società di hosting potrebbe desiderare di collocare i controller di dominio di un cliente nei locali dedicati al cliente stesso. Poiché la violazione di un controller di dominio da sola può influire sulla fornitura di servizi nel resto di una foresta,  si potrebbe creare una foresta separata per ogni cliente che richiede controller di dominio nei locali. In caso contrario, un client manomesso con accesso fisico a un controller di dominio nei loro locali potrebbe essere in grado di interferire con il funzionamento della directory per gli altri clienti nella stessa foresta.

Considerazioni particolari per le foreste di isolamento del servizio sono i seguenti:

·    Foreste create per l'isolamento dei servizi possono avere trust con domini di altre foreste, ma non devono includere gli utenti dalle altre foreste nei gruppi amministrativi. Se gli utenti dalle altre foreste sono inclusi nei gruppi amministrativi della foresta isolata, una violazione dell’altra foresta potrebbe portare a una violazione della foresta isolata.

·    Sebbene la creazione di una foresta separata possa fornire isolamento del servizio, è importante notare che fino a che i controller di dominio sono accessibili su una rete, essi sono soggetti ad attacchi (ad esempio attacchi denial of service) dai computer in rete. Le organizzazioni che decidono che il rischio di attacco è troppo alto, o che la conseguenza di un attacco o violazione sono troppo grandi, possono effettuare le seguenti operazioni:

o  Valutare attentamente l'affidabilità delle reti che contengono i controller di dominio.

o  Limitare l'accesso alle reti che contengono i controller di dominio.

L’accesso può essere limitato utilizzando tecnologie come firewall e IPSEC. Per ulteriori informazioni sul limitare l'accesso tramite firewall e IPSEC, vedere Windows 2000 Server Resource Kit al link http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx [http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx].

Scenario 2: Creazione di foreste per l'autonomia dei servizi a livello di foresta

Una foresta è costituito da un insieme di domini con contenitore dello schema e un contenitore di configurazione condivisi. Questi contenitori sono controllati dal proprietario della foresta.

·    **Schema:**Lo schema della foresta determina quali classi di oggetti possono essere creati nella directory e quali attributi sono associati a tali oggetti. Le applicazioni che si avvalgono di Active Directory possono estendere lo schema per includere dati specifici dell'applicazione.

·    **Configurazione:**Dati memorizzati nel contenitore di configurazione includono:

o  Dati che definiscono la topologia dei siti e della replica della foresta.

o  Varie impostazioni a livello delle policy di foresta, ad esempio una policy LDAP basata su sito e una a livello di foresta (per i controller di dominio).

o  Informazioni che identificano l’insieme dei domini nella foresta e la gerarchia di trust. Ogni dominio della foresta ha una trust con tutti gli altri domini della foresta. Attraverso il controllo di questi dati di configurazione, il proprietario della foresta controlla la creazione di nuovi domini della foresta.

o  Applicazioni abilitate per Active Directory possono memorizzare i dati di configurazione a livello di foresta nel contenitore configurazione. Un esempio di tali applicazioni è Microsoft ® Exchange 2000.

Se un'organizzazione richiede la capacità di manipolare in modo indipendente il contenitore di configurazione o dello schema, essa richiede una propria foresta. Questo requisito è tipicamente guidato dalla struttura organizzativa o da requisiti operativi.

Un requisito di struttura organizzativa che spinge all'autonomia dei servizi a livello di foresta potrebbe essere il seguente:

·    Una divisione di un'azienda potrebbe voler installare applicazioni abilitate all'uso di directory che estendono lo schema, senza consultare altre divisioni dell'azienda. La creazione di una foresta separata scambia i costi supplementari di gestione di una foresta separata con l'autonomia a livello di foresta.

Un'esigenza operativa che spinge all'autonomia dei servizi a livello di foresta potrebbe essere la seguente:

• Una società di hosting potrebbe voler permettere ai propri clienti di installare applicazioni personalizzate che estendono lo schema, ma non sono certificate nell'ambito del programma Windows Logo per soddisfare le best practices relative allo schema. Datosi che altri client probabilmente non accetteranno applicazioni non certificate, questo client deve poter gestire in autonomia lo schema. A tale scopo, la società di hosting deve assegnare a loro una foresta separata.

Una considerazione speciale per la creazione di foreste per l'autonomia dei servizi a livello di foresta è il seguente:

·      Le organizzazioni che giustificano la creazione di una foresta separata con requisiti relativi alla struttura organizzativa devono essere consapevoli che nella realizzazione di più foreste è necessario bilanciare costi e benefici. Anche se un'organizzazione potrebbe preferire le operazioni del servizio in autonomia, potrebbe essere più conveniente a concedere la responsabilità per la fornitura di servizi ad un gruppo IT affidabile centralizzato. In questo modo, l'organizzazione IT del gruppo può partecipare alla gestione dei dati nella foresta, ma elimina il costo di ottenere personale specializzato nella gestione dei servizi directory. Per ulteriori informazioni sul bilanciare costi e benefici in questo scenario, consultare la serie Best Practice nella distribuzione di Active Directory http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].

Scenario 3: Delega di domini per l'autonomia dei servizi a livello di dominio

Un'organizzazione potrebbe concordare nel consentire che la configurazione a livello di foresta sia gestita da un proprietario della foresta, ma potrebbe ancora desiderare di avere autonomia dei servizi a livello di dominio. I seguenti elementi del servizio sono controllati in modo indipendente a livello di dominio:

·    **Disponibilità del servizio —**Il proprietario del dominio ha la capacità di creare, eliminare, salvare e ripristinare i controller di dominio al fine di soddisfare un livello stabilito di disponibilità del servizio.

·    **Trust esterno —**Il proprietario del dominio può determinare quali domini in altre foreste avranno una trust.

·    **Criteri di account utente di dominio —**Certe politiche che governano gli account utente di dominio possono essere controllate solo a livello di dominio. Questi criteri sono:

o  Criterio password

o  Criterio di blocco account

o  Politica di vita del ticket Kerberos

Per delegare la capacità di controllare autonomamente questi aspetti del servizio, un proprietario della foresta può delegare un dominio nell'organizzazione. Considerazioni particolari per la delega di un dominio sono i seguenti :

·         In conseguenza delle informazioni su Active Directory discusse in precedenza in questo documento (vedere " Informazioni su strutture di Directory e proprietari di struttura di Directory"), il proprietario di una foresta deve delegare un dominio ad una organizzazione  solo se il proprietario della foresta e tutti i proprietari di dominio considerano attendibile il proprietario del dominio dell’organizzazione delegata. In base a questo requisito, è una pratica consigliata centralizzare le proprietà della foresta e dei servizi di dominio in una singola organizzazione responsabile della foresta e utilizzare domini solo per il partizionamento geografica della replica. Poiché tutti gli amministratori del servizio sono attendibili, delegazione può essere tranquillamente fatto interamente a livello dell'unità organizzativa.

·    I domini forniscono autonomia dei servizi a livello di dominio, ma non forniscono isolamento dei dati dal proprietario della foresta o altri proprietari di dominio. Se un'organizzazione richiede l'isolamento dei dati rispetto ai proprietari di servizio, è necessario creare foreste separate. Per ulteriori informazioni, vedere "Scenario 4: creazione di foreste per dati isolate dai proprietari del servizio", più avanti in questo documento.

·    In un'organizzazione di grandi dimensioni è possibile che l'organizzazione IT che possiede la foresta sia diversa dall'organizzazione IT che gestisce tutte le altre operazioni di directory. In questa situazione è consigliabile creare un dominio radice della foresta dedicato. Il proprietario del dominio radice della foresta controlla il dominio radice dedicato della foresta e l'organizzazione IT operativa ha la proprietà di uno o più domini figlio. In questo modo l'organizzazione IT operativa può gestire autonomamente la disponibilità del servizio, ma non controlla l'appartenenza dei gruppi Enterprise Admins e Schema Admins nel dominio radice della foresta. Si noti che un dominio root  della foresta dedicato garantisce protezione solo contro l'abuso non intenzionale o accidentale dei privilegi; i proprietari di domini non root possono ancora utilizzare metodi dannosi per tentare di manipolare i gruppi nel dominio radice.

Per ulteriori informazioni sulle best practice nella progettazione del partizionamento di dominio geografico e sul dominio root dedicato per la foresta consultare i documenti Best Practice seguenti http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx [http://technet.microsoft.com/en-us/library/bb727085.aspx].

Scenario 4: creazione di foreste per dati isolate dai proprietari del servizio

Datosi che i dati archiviati in Active Directory e sui computer fanno parte di Active Directory non possono essere isolati dagli amministratori del servizio di directory, l'unico modo per un'organizzazione di ottenere l'isolamento completo dei dati è di creare una foresta separata. Questa situazione può verificarsi in un'organizzazione in cui gli amministratori dei servizi sono normalmente affidabili, ma le conseguenze di un attacco da un amministratore malintenzionato o costretto con coercizione possono avere un impatto grave sull'organizzazione. Questo tipo di requisito per l'isolamento dei dati in genere è imposto da requisiti legali.

Requisiti legali che impongono la necessità di isolamento dei dati da parte dei proprietari del servizio sono i seguenti :

·    Una istituzione finanziaria è obbligata per legge a limitare l'accesso ai dati dei clienti in una particolare giurisdizione agli utenti, computer e agli amministratori che si trova in tale giurisdizione. Anche se l'ente darebbe normalmente fiducia gli amministratori dei servizi che lavorano di fuori della giurisdizione protetta, violando la limitazione di accesso potrebbe far perdere all'istituzione la sua capacità di fare affari in tale giurisdizione.

·    Un appaltatore dell’esercito è obbligato per legge a limitare l'accesso ai dati del progetto di difesa a un insieme di utenti specificato. Anche se il contraente darebbe normalmente fiducia gli amministratori dei servizi che controllano i sistemi di computer connessi ad altri progetti, la conseguenza di una violazione da parte di questi amministratori dei servizi potrebbe essere la perdita della capacità di avere contratti con il governo.

Considerazioni particolari per la creazione di foreste per l'isolamento dei dati da parte dei proprietari del servizio sono i seguenti:

·    Foreste create per l'isolamento dei dati possono avere trust con domini da altre foreste, ma gli utenti dalle altre foreste non dovrebbero essere inclusi in uno qualsiasi dei seguenti gruppi:

o  Gruppi responsabili della gestione del servizio o gruppi che possono gestire l'appartenenza a gruppi di amministratori di servizio

o  Gruppi con controllo amministrativo di computer che archiviano i dati protetti

o  Gruppi che hanno accesso ai dati protetti, o gruppi, responsabili per la gestione di oggetti utente o gruppo che hanno accesso ai dati protetti

Se gli utenti da un'altra foresta sono inclusi in uno qualsiasi di questi gruppi, una violazione di altra foresta potrebbe portare a una violazione della foresta isolata e alla divulgazione di dati protetti.

·    Sebbene la creazione di una foresta separata consente l'isolamento dei dati, è importante notare che, finché i controller di dominio della foresta isolata e i computer che ospitano informazioni protette sono accessibili su una rete, essi sono soggetti ad attacchi lanciati dai computer in rete. Le organizzazioni che decidono che il rischio di attacco è troppo alto, o che la conseguenza di un attacco o di una violazione sono troppo grandi, devono fare quanto segue:

o  Considerare con attenzione l'affidabilità delle reti che ospitano i controller di dominio o computer contenente dati protetti

o  Limitare l'accesso per le reti che ospitano i controller di dominio e i computer che ospitano dati protetti utilizzando tecnologie come firewall e IPSEC

Scenario 5: Delega di unità organizzative per autonomia e isolamento dei dati da non proprietari di servizi

Un'organizzazione può affidare la proprietà del servizio a livello di foresta e di dominio ad una organizzazione separata, attendibile, conservando controllo autonomo sui suoi dati mettendoli in un'unità organizzativa. Possono essere collocate autorizzazioni sui dati in modo che siano visibili solo a utenti specifici. Questo permette a un'organizzazione di isolare i suoi dati da altre organizzazioni  che non sono proprietarie di servizi che controllano OU nello stesso dominio o nella stessa foresta

Un requisito di struttura organizzativa che giustifica l'utilizzo di unità organizzative per la delega è il seguente:

·    Una business unit in un'azienda potrebbe richiedere la capacità di creare, modificare e cancellare gli account utente per i propri dipendenti in modo indipendente. Se la business unit non ha nessun requisito di isolare questi account utente dai proprietari di servizio, è sicuro per questa business unit di accettare una delega a livello di OU.

Un'esigenza operativa che giustifica l'utilizzo di unità organizzative per la delega è la seguente:

·    Una società di hosting che mantiene tutte le proprietà del servizio in una foresta e limita l'accesso fisico al personale della società di hosting può delegare le unità organizzative ai clienti. Questi clienti possono gestire autonomamente i loro dati di directory e potrebbero anche scegliere di avere i loro dati nascosti da altri clienti che condividono la stessa infrastruttura.

Segue una considerazione speciale per la delega dell'unità organizzative:

·    Un'unità organizzativa delegata è appropriata solo se l'organizzazione è convinta che tutti i proprietari di servizio nella foresta sono affidabili, e tutti i controller di dominio della foresta sono fisicamente protetti.

Inizio della pagina

Procedure consigliate per gli amministratori del servizio e che limitano l'accesso fisico ai controller di dominio

Poiché gli amministratori dei servizi devono essere altamente attendibili, è importante capire quali gruppi amministrativi di Active Directory sono amministratori dei servizi, e quali sono le Procedure consigliate da seguire per questi gruppi.

Gli amministratori dei servizi in Active Directory includono:

·    Qualsiasi gruppo che legittimamente può modificare le impostazioni di configurazione di directory

·    Qualsiasi gruppo che può installare un controller di dominio

·    Qualsiasi gruppo che può installare o modificare il software sui controller di dominio

·    Qualsiasi gruppo che può modificare l'appartenenza a un altro gruppo di amministratore del servizio

Per la versione di Windows 2000 di Active Directory, questi gruppi comprendono:

·    Gruppi controllati dal proprietario di una foresta

• • Domain Admins (dominio radice della foresta)

o  Enterprise Admins

o  Schema Admins

·    Gruppi controllati dal  proprietario di un dominio

o  Gruppo Domain Admins

o  Builtin\Administrators

o  Builtin\Server Operators

o  Builtin\Backup Operators

 Per ridurre la possibilità di attacco da amministratori di servizio o tramite l'accesso fisico ai controller di dominio, sono consigliate le seguenti procedure :

·    Ridurre al minimo il numero dei membri nei

·    Consentire solo altri gruppi di amministratori del servizio la modifica dell'appartenenza a gruppi di amministratori di servizio

·    Non includere utenti o gruppi da foreste trusted esterne in gruppi di amministratore di servizio nella foresta a meno che gli amministratori del servizio dalla foresta esterna siano attendibili come gli amministratori della foresta (interna)

·    Effettuare audit delle modifiche all’appartenenze al gruppo di amministratori del servizio

·    Accedere utilizzando le credenziali dell'amministratore del servizio solo se strettamente necessario; fornire account utente alternativi agli amministratori per lavoro quotidiano

·    Consentire solo ai gruppi amministratori di servizio di gestire le postazioni utilizzate dagli amministratori di servizio

·    Limitare l'accesso fisico ai controller di dominio per gli amministratori dei servizi; non posizionare controller di dominio in luoghi che non possono essere protetti

• Limitare l'accesso fisico al backup system state del controller di dominio agli amministratori dei servizi; non conservare backup system state in posizioni che non possono essere protetto

·    Ridurre al minimo il software utilizzato  sui controller di dominio

• Preparare eprovare un piano di business recovery a livello di foresta

·    Formare gli amministratori dei servizi sull'importanza di osservare le procedure consigliate

Inizio della pagina 

Conclusione

Active Directory fornisce un'infrastruttura che consente la collaborazione tra le persone e le organizzazioni. Durante la progettazione per la delega dell'amministrazione, i progettisti devono definire le loro esigenze di delega, comprendere le implicazioni di sicurezza della delega ed essere consapevoli dei compromessi tra collaborazione, autonomia e isolamento in un'infrastruttura di directory.

Per consentire la massima collaborazione con il minor costo, un'organizzazione può implementare un design di foresta singola con una singola organizzazione IT che possiede tutta la gestione del servizio di foresta e dominio e delegare l'autonomia o isolamento dei dati ad altre organizzazioni utilizzando unità organizzative. Ciascuna organizzazione partecipante deve dare fiducia al proprietario del servizio, prima di entrare nella foresta.

Alcune organizzazioni hanno requisiti specifici di autonomia o di isolamento rendono la fiducia a un proprietario di servizio centrale impraticabile o imprudente. Queste organizzazioni possono realizzare più disegni di foresta e abilitare la collaborazione tra foreste attraverso sistemi di gestione aggiuntivi quali Microsoft Metadirectory Services (MMS).

Per ulteriori informazioni su MMS, vedere http://www.microsoft.com/windows2000/technologies/directory/MMS/default.asp [http://www.microsoft.com/windows2000/technologies/directory/mms/default.asp].

Inizio della pagina 

Appendice – informazioni base per i requisiti di fiducia all'amministratore del servizio e requisiti di accesso fisico ai Domain Controller

Le procedure di progettazione in questo documento presuppongono  che qualsiasi organizzazione che partecipa a una foresta dia fiducia a tutti gli amministratori del servizio foresta (il proprietario della foresta e i proprietari dei domini) e sia soddisfatta della protezione fisica dei controller di dominio. La seguente discussione descrive perché questo è necessario.

Implicazioni di sicurezza dell’accesso come amministratore di servizio e accesso fisico

Active Directory include funzionalità di sicurezza che sono definite dai seguenti componenti fondamentali del sistema :

·    **Software di sistema che costituisce un controller di dominio di Active Directory —**Questo software gestisce processi di autenticazione, costruisce e trasmette le strutture dati che definiscono l'identità di un utente (chiamato anche dati di autorizzazione), impone i criteri e limita l'accesso agli oggetti nella directory basandosi su autorizzazioni per oggetto, e per attributo.

·    **Il database di directory archiviato nei controller di dominio —**Il database di Active Directory archivia le informazioni come le password utente, l'appartenenza a gruppi e le Access Control List che regolano l'accesso agli oggetti.

Se un utente malintenzionato modifica il software di sistema o il database di directory di un controller di dominio, è possibile per l’attaccante disattivare le funzionalità di protezione di Active Directory o modificarle in un modo che è altresì vantaggioso per l'attaccante. Le seguenti persone hanno la capacità di lanciare tali attacchi:

·    **Gli amministratori del servizio —**Gli amministratori dei servizi necessitano della capacità di modificare il software di sistema sui controller di dominio. Ad esempio, gli amministratori del servizio devono essere in grado di applicare le patch software, installare i service pack, installare gli aggiornamenti del sistema operativo e collegare i debugger, azioni che possono modificare il software di sistema. Attraverso questo accesso legittimo, un amministratore del servizio potrebbe installare il software che applica le modifiche dannose al comportamento del sistema.

·    **Persone con accesso fisico ai controller di dominio —**Una persona con accesso fisico a un controller di dominio può attaccare il sistema nei modi seguenti:

o  Modificando o sostituendo i file binari di sistema sul disco fisico che ospita il software di sistema del controller di dominio.

o  Mediante l'accesso offline al database di directory. Un utente malintenzionato può ottenere l'accesso non in linea al database di directory e leggere dati senza che vengano applicate le ACL, potrebbe essere in grado di violare le password memorizzate nel database e potrebbe essere in grado di apportare modifiche al database che cambiano il comportamento di questo e potenzialmente di altri controller di dominio se il database offline viene reinserito nel sistema.

Questi attacchi possono essere realizzati mediante:

o  Accedendo ai dischi fisici mediante l'avvio di un controller di dominio con un sistema operativo alternativo.

o  Rimuovendo i dischi fisici  (e possibilmente sostituendoli) su un controller di dominio.

o  Ottenendo e manipolando una copia di un backup system state di un controller di dominio.

Nota: La funzionalità SYSKEY di Active Directory può fornire una protezione aggiuntiva per le password memorizzate nel database di Active Directory crittografandole con una chiave di sistema memorizzata in un disco floppy. Per individuare le password nel database, l'attaccante ha bisogno di accesso fisico sia database di Active Directory che al disco floppy con la chiave del sistema.

È importante notare che SYSKEY non crittografa l'intero database. Un utente malintenzionato può ottenere una copia fisica del database e leggere o modificare i dati crittografati nel database senza che vengano applicate ACL. Per ulteriori informazioni sulla caratteristiche di SYSKEY, vedere Windows 2000 Server Resource Kit all’uri http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx [http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx].

Gli attacchi che modificano il software di sistema non si limitano a modificare il comportamento delle funzionalità di sicurezza. Ad esempio, il sistema normalmente impone un requisito per cui gli aggiornamenti dello schema possono essere scritti solo o sul controller di dominio che ha il ruolo di schema master. Usando una modifica del software di sistema malevola, è possibile che un utente malintenzionato superi il controllo del ruolo di schema master e aggiorni lo schema sui controller di dominio modificati.

Anche se gli attacchi al software di sistema e le modifiche fisiche al database di directory appaiono difficili, solo un singolo utente malintenzionato altamente competente ha bisogno di creare strumenti per l'attacco. Una volta creati, gli strumenti possono essere distribuite a qualsiasi amministratore.

Vulnerabilità da modificazione del sistema

In un sistema distribuito, la violazione di un singolo computer può influire su molti computer o anche sull'intero sistema. Una foresta di Active Directory è un sistema distribuito strettamente connesso. Un utente malintenzionato che può modificare il software di sistema su un controller di dominio o ottenere l'accesso fisico a un controller di dominio può sfruttare la stretta interoperatività del sistema al fine di estendere l'attacco agli altri computer della foresta. In particolare, l'attacco potrebbe sfruttare le seguenti caratteristiche di Active Directory:

·    Tutti i centri di distribuzione Kerberos Key (KDC) sono considerati ugualmente affidabili.

Quando un utente accede, il software KDC su un controller di dominio compila i dati di autorizzazione che descrivono l'identità dell'utente. Questi dati di autorizzazione contengono identificatori di protezione (SID) dell'utente e dei gruppi di cui l'utente è membro. Quando un utente accede a una risorsa in un altro dominio, KDC dell'utente invia dati di autorizzazione al KDC in tale dominio come presentazione dell'identità dell'utente.

Al fine di permettere a caratteristiche come SID History e gruppi universali di funzionare, il KDC in ciascun dominio deve accettare la validità di dati di autorizzazione utente che includono i SID da domini esterni al dominio dell'utente.

Un utente malintenzionato può sfruttare questa caratteristica modificando il software KDC o il database di directory per inserire dei SID nei dati di autorizzazione dell'utente. In questo modo, un attaccante può autenticarsi su un controller di dominio modificato e utilizzare i SID inserito per impersonare qualsiasi utente nella foresta, o per diventare un membro di un qualsiasi gruppo nella foresta (inclusi gruppi amministrativi). Questo attacco è noto come spoofing di dati di autorizzazione o attacco SID spoofing.

·    **  I dati memorizzati nelle partizioni condivise dello schema e della configurazione su tutti i controller di dominio e i dati memorizzati nelle partizioni parziali di dominio su tutti i server di catalogo globale sono considerati tutti ugualmente affidabili.**

Quando i controller di dominio replicano le modifiche alle partizioni condivise per lo schema e per la configurazione, considerano tutte le copie delle partizioni su tutti i controller di dominio come ugualmente affidabile. Un controller di dominio accetta aggiornamenti replicati a queste partizioni da qualsiasi controller di dominio nella foresta. Inoltre, i software abilitati da Active Directory nei computer client presuppongono che le partizioni schema e configurazione su tutti i controller di dominio sono ugualmente affidabili e accetta le risposte alle query per queste informazioni da qualsiasi controller di dominio nella foresta.

Quando il controller di dominio configurati come server di catalogo globale replicano le modifiche alle partizioni parziali di dominio, si può selezionare come partner di replica o un controller di dominio con una copia completa della partizione o un altro server di catalogo globale, fra tutti i domini nella foresta. Inoltre, i software client abilitati per Active Directory considerano tutti i server di catalogo globale in una foresta come altrettanto affidabile e accettano le risposte alle query da qualsiasi server di catalogo globale nella foresta.

Tali presupposti permettono ai controller di dominio di ottimizzare il flusso di replica tra controller di dominio basato sulla topologia dei siti di una foresta. Questo evita di replicare gli stessi dati di più di una volta su un collegamento di rete lento. Queste assunzioni consentono anche ai client di eseguire query su un server di catalogo globale o sui contenitori di configurazione o dello schema di un controller di dominio nello stesso sito del client, indipendentemente dal dominio di appartenenza del server. Questo evita di limitare i client ai controller di dominio e server di catalogo globale del loro stesso dominio, datosi che tali servizi potrebbero non essere localizzati nello stesso sito del client.

Esiste una vulnerabilità perché, sia attraverso la modifica del software di sistema o tramite l'accesso fisico ai database di directory, un utente malintenzionato può modificare i dati di sicurezza sensibili memorizzati nella partizione dello schema, o nella partizione di configurazione o in qualsiasi partizione parziale di dominio su un controller di dominio violato e causare uno o entrambi i seguenti:

o  Fare in modo che i Controller di dominio a valle accettino questi cambiamenti come aggiornamenti replicati legali

o  Fare in modo che i Software abilitati alla directory dei client accettino questi dati come dati legali

Software di sicurezza sensibili memorizzati in queste partizioni includono quanto segue:

o  Schema — il descrittore di sicurezza predefinito per una classe di oggetti. Un utente malintenzionato potrebbe cambiare il descrittore di sicurezza predefinito per una classe di oggetti e concedere l'accesso a utenti o gruppi sotto il suo controllo. Questo darebbe l'accesso a utente malintenzionato agli oggetti appena creati di tale classe.

o  **Configurazione —**Criteri basati sul sito. Un utente malintenzionato potrebbe alterare i criteri basati sul sito e fare in modo che gli utenti in domini remoti eseguano gli script di accesso definiti dall'utente malintenzionato.

o  **Partizioni parziali di dominio —**Appartenenza a gruppi universali. Un utente malintenzionato potrebbe alterare l'appartenenza a un gruppo universale amministrativo dai privilegi elevati, come ad esempio Enterprise Admins, per includere gli utenti specificati dall'utente malintenzionato.

Sfruttando queste caratteristiche nei modi descritti, un utente malintenzionato può estendere l'impatto di un attacco da un singolo controller di dominio fino a  includere una o più delle seguenti :

·    La configurazione della foresta

·    La configurazione di qualsiasi dominio della foresta

·    Qualsiasi applicazione che si basa sui dati immagazzinati in qualsiasi dominio della foresta o nel contenitore della configurazione della foresta

·    Qualsiasi computer appartenente alla foresta, compresi i dati memorizzati su quei computer o servizi in esecuzione su tali computer

·    Qualsiasi risorsa in qualsiasi dominio di fuori della foresta attaccata che ha una trust con un dominio all'interno della foresta attaccata, e sul quale agli utenti della foresta attaccata è  stato concesso l'accesso

Per i motivi discussi qui, le organizzazioni che partecipano a una foresta non possono essere isolate da qualsiasi amministratore del servizio nella foresta e devono controllare tutto il personale che ha accesso fisico ai controller di dominio. Di conseguenza queste organizzazioni devono adottare misure per mitigare o limitare le vulnerabilità che derivano dall'obbligo di dare fiducia agli amministratori del servizio e il potenziale di accesso non autorizzato ai controller di indominio.

Nota: Le due caratteristiche di cui sopra di Active Directory non possono essere utilizzate per lanciare attacchi tra domini  diverse foreste se vengono rispettate le adeguate precauzioni:

·    Per proteggere i dati da attacchi di  spoofing di autorizzazione, utilizzare la funzionalità di filtro dei SID su collegamenti trust esterni tra domini di diverse foreste. Per ulteriori informazioni sul filtro SID, vedere l'articolo 309172 della Microsoft Knowledge Base al http://search.support.microsoft.com [http://search.support.microsoft.com/default.aspx].

• Nessuna partizione di dati è condivisi o replicata tra controller di dominio in foreste diverse. Gli utenti e gli amministratori di domini con trust esterna entrante nelle foreste remote possono solo aggiornare dati sensibili in una foresta se ad essi sono stati specificamente concessi accessi in scrittura ai dati. Non concedere l'accesso ai dati riservati agli utenti di domini con trust esterna entrante a meno che gli utenti e gli amministratori di servizio del dominio remoto ricevano una trust come gli amministratori di servizio della foresta.