Active Directory: Strutture di Active Directory

Benché la semplicità sia spesso la scelta migliore, potrebbe essere possibile prendere in considerazione l'applicazione di un layout più creativo alla propria infrastruttura Active Directory.

Brien M. Posey

Una cosa che sempre mi ha sorpreso quando guardando le distribuzioni di Active Directory del mondo reale: Anche se ci sono certamente eccezioni, nella maggior parte dei casi, le organizzazioni bastone con il setup più semplice con cui può realisticamente ottenere via.

In qualche modo, questo non dovrebbe essere una sorpresa. Mi ricorda un professore universitario che spesso ha detto dobbiamo vivere la vita secondo il principio di KISS-Keep It Simple, Stupid. Forse da nessuna parte questo principio si applica con maggiore precisione rispetto al mondo dell'IT.

Qualsiasi professionista IT sa mantenere le cose semplici riduce la probabilità di problemi. Inoltre rende molto più facile la risoluzione dei problemi quando qualcosa va storto. Mentre sarò il primo ad ammettere che c'è qualcosa da dire per semplicità, quando si tratta di infrastruttura di Active Directory, potrebbe essere meglio serviti da una struttura più creativa.

Non c'è assolutamente niente di sbagliato con l'utilizzo di una topologia di Active Directory standard. C'è un motivo che Microsoft ha reso la topologia standard predefinito. Questi disegni un po' più dettagliati, tuttavia, potrebbero essere più appropriati per le organizzazioni più grandi che hanno bisogno di separare le responsabilità di gestione.

Domini utente

La maggior parte delle impostazioni di Active Directory del mondo reale, la struttura di dominio imita la struttura geografica dell'organizzazione. Ad esempio, se un'organizzazione ha tre uffici, è probabile avere tre domini. Che certamente non vuol dire che ogni organizzazione utilizza questo disegno, ma è il più comune tipo di struttura di Active Directory. Mentre topologie Active Directory geografiche sono comuni e davvero efficace, potrebbe anche voler prendere in considerazione alcune strutture di dominio alternativo.

Come siete senza dubbio a conoscenza, Active Directory è davvero niente di più che un database elaborato. Un database di Active Directory è riempito con vari tipi di oggetti. Ogni oggetto è assegnato uno o più attributi. Alcune organizzazioni di base struttura del loro dominio su tipi specifici di oggetti Active Directory. Un chiaro esempio di questo tipo di classificazione è domini utente.

Un dominio di utente è un dominio di Active Directory che ha l'unico scopo di gestione degli account utente. Per darvi un'idea del perché questo è utile, si consideri una delle aziende dove andavo a lavorare. Questa particolare organizzazione aveva pochi migliaia di utenti. C'era sempre un alto tasso di turnover dei dipendenti. Di conseguenza, l'organizzazione impiegati due persone di cui lavoro era di creare, eseguire il provisioning e rimuovere gli account utente.

In questo tipo di situazione, un dominio utente si è rivelato utile. Questo tipo di struttura di dominio dà agli utenti il compito di controllo amministrativo completo dell'account manutenzione sopra gli account utente. Esso, tuttavia, consente di accedere ad altri oggetti di Active Directory o funzioni.

Ci sono altri modi per realizzare questo tipo di isolamento amministrativo-dovere. Anche così, una struttura di dominio utente potrebbe aiutare un'organizzazione a stare meglio organizzato. Se non altro, aiuta a rendere i singoli domini che meno ingombra. Inoltre, fornisce un senso di isolamento fisico e amministrativa. Alcune organizzazioni potrebbero preferire questo all'isolamento amministrativo logico che può verificarsi quando i vari tipi di oggetto risiedono in un dominio comune.

Domini di risorse

Domini di risorse sono simili ai domini utente. Queste sono monouso in natura e utilizzate per migliorare la sicurezza o la struttura di Active Directory più logico o più gestibile. Ci sono distribuzioni di Active Directory del mondo reale in cui tutti i computer desktop sono raggruppati in un dominio di risorse dedicate. Ci sono anche altri domini di risorse utilizzati per altri tipi di risorse. Ad esempio, un'organizzazione posta tutti i server che eseguono la sua primaria applicazione di line-of-business (LOB) in un dominio di risorse dedicate.

Domini di risorse sono probabilmente il più utile quando esse sono trattate come domini di gestione. Per esempio, ho creato una foresta di Active Directory dedicata progettata per agire puramente come un dominio di gestione per il mio server Hyper-V. Ci sono un paio di motivi perché ho scelto di fare questo.

Il primo è un motivo di gestione. System Center Operations Manager 2012 (e un certo numero di altri prodotti di gestione) può gestire solo i server che sono membri di un dominio di Active Directory. Non ho voluto unire il mio server Hyper-V al mio dominio primario perché tutti i controller di dominio per il mio dominio primario vengono virtualizzati. Non volevo rischiare di non essere in grado di accedere a un server Hyper-V semplicemente perché il controller di dominio virtuale erano offline. Unendo il server Hyper-V in una foresta di gestione Active Directory dedicato, ha risolto questo problema.

L'altro motivo che ho scelto di creare un dominio dedicato risorse per il mio server Hyper-V ha a che fare con alcune delle nuove caratteristiche di venire in Hyper-V versione 3.0. Una delle caratteristiche di Hyper-V 3.0 che sono più entusiasta è la capacità di replicare una macchina virtuale (VM) dal server uno host a altro.

Questo tipo di replica non è necessariamente una soluzione di clustering di failover, ma piuttosto una soluzione di disaster recovery che può aiutare a mantenere una copia aggiornata del tuo macchine virtuali su un server host alternativo. Se qualcosa dovesse accadere a un array di dischi o un host Hyper-V primario, c'è un'altra copia del tuo macchine virtuali si può ripiegare su. Per poter utilizzare questa funzionalità, tuttavia, sia il server host e server di replica deve essere autenticate.

Il modo più semplice per fornire questa autenticazione è di unire entrambi i server a un dominio comune e utilizzare Kerberos. Come tale, creazione di un dominio di risorse dedicate 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.

Domini di risorse e utente non sono mutuamente esclusivi, tra l'altro. Alcune organizzazioni utilizzano una combinazione di domini utente e di risorse all'interno di una foresta di Active Directory comune. Entrambi hanno i loro punti di forza, e si può applicare sia come necessario.

Topologia geografica

La stragrande maggioranza delle distribuzioni di Active Directory nel mondo reale è basata sulla struttura geografica. Per esempio, un'organizzazione con cinque filiali potrebbe utilizzare cinque domini separati, uno per ogni ufficio che comprende tutte le macchine fisiche all'interno di quell'ufficio. 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, è importante non confondere la struttura di dominio con la struttura del sito. La struttura del sito di Active Directory deve sempre imitare topologia geografica di un'organizzazione. Per ogni collegamento wide area network (WAN) c'è 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 deve usare una subnet dedicata, perché non potete avere una singola subnet estendersi su più siti di Active Directory.

La ragione che della struttura del sito di Active Directory è così importante è perché la struttura del sito ha un impatto diretto sul volume di traffico di replica di Active Directory che può fluire attraverso i collegamenti WAN. Ad esempio, immaginare un'organizzazione ha più filiali, ma ha scelto di configurare Active Directory come un singolo dominio. Ancora una volta, tecnicamente non c'è niente di sbagliato con quell'approccio, ma può essere inefficiente.

In una situazione come quella, aggiornamenti ad Active Directory potenzialmente potrebbero essere fatto a qualsiasi controller di dominio scrivibile ovunque all'interno dell'organizzazione. Quando si verifica un aggiornamento, è responsabilità della DC, quella di rendere disponibile l'aggiornamento per gli altri controller di dominio.

Perché questa organizzazione non fanno uso di una struttura di sito appropriato, un aggiornamento del comune non sarà in grado di passare sopra un collegamento WAN più volte. Ad esempio, se c'erano cinque DCs in un ufficio, quindi un aggiornamento di Active Directory potrebbe potenzialmente inviato attraverso il collegamento WAN cinque volte separati, una volta per ogni controller di dominio.

Un controller di dominio in ogni sito Active Directory agisce come server testa di ponte. Lavoro del server testa di ponte è di ricevere gli aggiornamenti di Active Directory da attraverso il collegamento WAN. Quindi distribuisce gli aggiornamenti per gli altri controller di dominio all'interno del sito. Questo significa che Active Directory aggiornamenti avrebbe solo bisogno di essere inviato a ogni filiale una sola volta, indipendentemente da quanti DCs esiste 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, quindi non è necessario preoccuparsi di definire i siti di Active Directory. D'altra parte, se ogni dominio è un membro di un insieme di strutture comuni, allora sicuramente si dovrebbe implementare un'adeguata struttura del sito Active Directory come un modo di mantenere il traffico di replica di Active Directory foresta-livello nel controllo.

Ci sono molti modi diversi per impostare una topologia di dominio di Active Directory. In definitiva, si dovrebbe scegliere la topologia che fa più senso per il layout fisico della tua organizzazione e infrastrutture di rete. Questo potrebbe essere un modello di dominio singolo, o un modello multi-dominio che si basa sulla vicinanza geografica, gli utenti o anche risorse.

Brien M. Posey

Brien PoseyMVP, è uno scrittore tecnico freelance con migliaia di articoli e decine di libri al suo attivo. Si può visitare il sito Web di Posey presso indirizzo brienposey.com.

Contenuti correlati