Active Directory: Active Directory il tuo modo
Il modo di che impostare la topografia di Active Directory avrà un impatto diretto su quanto bene sei in grado di organizzare gli utenti e le risorse.
Brien M. Posey
Dal rilascio di Windows 2000 Server edition più di un decennio fa — e con essa il rilascio di Active Directory, il servizio di directory Microsoft Time-Tested ha aiutato le organizzazioni a mantenere l'ordine in mezzo al caos. Una strategia che più organizzazioni prendono (anche se ci sono certamente eccezioni) è di attaccare con la distribuzione di Active Directory più semplice che si può realisticamente ottenere via con.
Questo dovrebbe venire come nessuna sorpresa. Sicuramente si applica il principio di mantenere le cose semplici come possibile per il mondo dell'IT. Qualsiasi professionista IT sa che mantenere le cose semplici, riduce la probabilità di problemi e rende molto più facile la risoluzione dei problemi. Non c'è assolutamente niente di sbagliato con l'utilizzo di una topologia di Active Directory standard. C'è un motivo che Microsoft ha impostato la topologia standard come predefinito.
Ma mentre c'è qualcosa da dire per semplicità, quando si tratta di Active Directory, alcune organizzazioni potrebbero essere meglio serviti da una struttura più creativa. Ci sono alcuni disegni alternativi che sono probabilmente più appropriati per le organizzazioni più grandi che hanno bisogno di separare le responsabilità di gestione.
Struttura del dominio
Più spesso, distribuzioni di Active Directory del mondo reale utilizzano una struttura di dominio che imita la struttura geografica dell'organizzazione. Ad esempio, se un'organizzazione ha tre uffici, è probabile che i tre domini. Non ogni organizzazione utilizza questo tipo di design, ma è il tipo più comune di struttura di Active Directory. Qui ci sono alcune strutture di dominio alternativo che si potrebbe prendere in considerazione per l'organizzazione.
Domini utente
Active Directory è davvero niente di più che un database. Il database è pieno di vari tipi di oggetti. Ogni oggetto viene assegnato uno o più attributi. Le organizzazioni di base a volte loro struttura di dominio su tipi specifici di oggetti Active Directory. Un esempio di questo è l'uso di domini utente.
Un dominio di utente è un dominio di Active Directory per il solo scopo di gestione degli account utente. Per darvi un'idea del perché questo è utile, si consideri questo esempio di un'organizzazione con pochi mille utenti e un alto tasso di turnover degli impiegati. Questa organizzazione si avvale di due persone cui compito è quello di creare, eseguire il provisioning e rimuovere gli account utente.
In questo tipo di situazione un dominio utente potrebbe rivelarsi utile, perché questo tipo di struttura di dominio contribuirebbe agli utenti il compito di manutenzione conto di avere il controllo amministrativo completo gli account utente. Potrebbero essere limitate, tuttavia, di avere accesso ad altri oggetti di Active Directory o funzioni.
Non è necessario implementare questo tipo di struttura di dominio appositamente per isolare le responsabilità amministrative. Ci sono altri modi per realizzare questo tipo di isolamento. Tuttavia, una struttura di dominio utente può aiutare un'organizzazione migliore soggiorno organizzato, rendendo i singoli domini che meno ingombra. Fornisce anche un senso di isolamento fisico amministrativa, che alcune organizzazioni potrebbero preferire invece l'isolamento amministrativo logico che può esistere quando tutti i vari tipi di oggetto risiedono in un dominio comune.
Domini di risorse
Domini di risorse sono simili ai domini utente in quanto sono monouso in natura. Questi sono utilizzati per migliorare la sicurezza o la struttura di Active Directory più logico o gestibile. Esistono distribuzioni di Active Directory del mondo reale in cui tutti i computer desktop sono raggruppati in un dominio di risorse dedicate. Altre organizzazioni hanno posto tutti i server che eseguono applicazioni line-of-business primarie in un dominio di risorse dedicate. È possibile utilizzare domini di risorse per qualsiasi altra classe della risorsa pure.
Domini di risorse sono probabilmente più utili quando li trattate come domini di gestione. Ad esempio, si desidera creare una foresta di Active Directory dedicata progettata per agire puramente come un dominio di gestione di Hyper-V Server. Ci sono un paio di motivi perché si potrebbe scegliere di farlo.
La prima ragione ha a che fare con la gestione. System Center Operations Manager 2012 (e una serie di altri prodotti di gestione) può gestire solo i server che sono membri di un dominio Active Directory. Non si vuole unire i server Hyper-V per il dominio principale perché tutti i controller di dominio per il dominio principale vengono virtualizzati. Non si vuole rischiare di mettere l'organizzazione in una situazione in cui erano in grado di accedere a un server Hyper-V perché il controller di dominio virtuale erano offline. Aggiungere il server Hyper-V in una foresta di gestione Active Directory dedicata risolve questo problema abbastanza bene.
Un altro motivo, che è possibile scegliere di creare un dominio dedicato risorse per il tuo server Hyper-V ha a che fare con alcune delle novità che stanno arrivando in Hyper-V versione 3.0. Hyper-V 3.0 avrà la possibilità di replicare una macchina virtuale (VM) dal server di un host a altro. Questo tipo di replica non è una soluzione di clustering di failover, ma piuttosto una soluzione di disaster recovery che ti permette di mantenere una copia aggiornata del tuo macchine virtuali su un server host alternativo. In questo modo, se è successo qualcosa di array di dischi o il vostro host Hyper-V primario, si avrebbe un'altra copia del vostro VMs potrebbe ricadere su.
Per utilizzare questa funzione, tuttavia, il server host e server di replica deve essere autenticato. Il modo più semplice per fornire questa autenticazione è di unire entrambi i server a un dominio comune e utilizzare Kerberos. Come tale, la creazione di un dominio dedicato risorse per Hyper-V Server ha perfettamente senso. Questo è particolarmente vero se si considera che ci sono altre caratteristiche di Hyper-V che richiedono anche l'appartenenza al dominio.
Per inciso, domini di risorse e utente non sono mutuamente esclusive. Alcune organizzazioni utilizzano una combinazione di domini utente e di risorse all'interno di una foresta di Active Directory comune.
Topologia geografica
Mentre queste strutture alternative sono davvero efficace, la stragrande maggioranza delle distribuzioni di Active Directory nel mondo reale è basata sulla struttura geografica. Tecnicamente, non c'è niente di sbagliato con l'utilizzo di questo tipo di topologia di Active Directory, ma ci sono alcune cose che dovreste considerare.
In primo luogo, non confondere la struttura di dominio con la struttura del sito. La struttura del sito di Active Directory deve sempre imitare la topologia geografica di un'organizzazione. Per ogni collegamento wide area network (WAN) tra uffici, ci dovrebbe essere un collegamento al sito corrispondente all'interno di Active Directory. Inoltre, i computer che si trovano all'interno di un ufficio fisico devono essere collocati all'interno di un comune sito di Active Directory. Idealmente, ogni posizione dovrebbe fare uso di una subnet dedicata perché una singola subnet non può estendersi su più siti di Active Directory.
Struttura del sito Active Directory è importante perché la struttura del sito ha un impatto diretto sul volume di traffico di replica di Active Directory che scorrerà attraverso collegamenti WAN. Ad esempio, immaginare un'organizzazione con più filiali. Questa organizzazione ha scelto di configurare Active Directory come un singolo dominio, che non è sbagliato. In una situazione come questa, si potrebbero potenzialmente fare aggiornamenti di Active Directory su qualsiasi controller di dominio scrivibile all'interno dell'intera organizzazione. Quando si verifica un aggiornamento, è responsabilità della DC a disposizione l'aggiornamento dei controller di dominio.
Se questa organizzazione non ha fatto uso di una struttura di sito appropriato, un aggiornamento comune potrebbe passare sopra un collegamento WAN più volte. Ad esempio, se c'erano cinque DCs in un ufficio, un aggiornamento di Active Directory potrebbe potenzialmente inviato attraverso il collegamento WAN cinque volte, una volta per ogni controller di dominio.
Quando si utilizzano siti di Active Directory, un controller di dominio in ciascun sito agisce come server testa di ponte. Il lavoro del server testa di ponte è di ricevere gli aggiornamenti di Active Directory da WAN e distribuire gli aggiornamenti per i controller di dominio all'interno del sito. Questo significa che qualsiasi Active Directory aggiornamenti avrebbero solo bisogno di essere inviati una sola volta, per ogni filiale indipendentemente da quanti DCs ci sono all'interno di quella succursale.
Per quanto riguarda le organizzazioni che utilizzano un dominio separato per ogni filiale? Se ogni filiale ha una foresta di Active Directory dedicato, non dovete preoccuparti per definire i siti di Active Directory. D'altra parte, se ogni dominio è un membro di un insieme di strutture comuni, è necessario implementare una struttura adeguata del sito Active Directory sicuramente come un modo per mantenere il traffico di replica di Active Directory livello di foresta nel controllo.
Come potete vedere, ci sono un sacco di modi per configurare la topologia del dominio di Active Directory. In definitiva, si dovrebbe scegliere la topologia che fa più senso per la propria organizzazione. Questo potrebbe essere un modello di dominio singolo, o un modello multidominio basato sulla vicinanza geografica, gli utenti o anche risorse.
.jpg)
Brien M. Posey, MVP, è scrittore tecnico con migliaia di articoli e decine di libri al suo attivo. Si può visitare il sito Web di Posey all'indirizzo brienposey.com.