Che cos'è Servizi di dominio Active Directory e come funziona?

Questa è una domanda canonica sui servizi di dominio Active Directory (Servizi di dominio Active Directory).

Che cos'è Active Directory? Cosa fa e come funziona?

Come è organizzata Active Directory: foresta, dominio figlio, albero, sito o unità organizzativa

Mi ritrovo a spiegare parte di ciò che presumo sia una conoscenza comune al riguardo quasi ogni giorno. Si spera che questa domanda funga da domanda canonica e risposta per la maggior parte delle domande di base su Active Directory. Se ritieni di poter migliorare la risposta a questa domanda, modifica.

Che cos'è Active Directory?

Servizi di dominio Active Directory è il Directory Server di Microsoft. Fornisce meccanismi di autenticazione e autorizzazione nonché un framework all'interno del quale è possibile distribuire altri servizi correlati (Servizi certificati AD, Servizi federati AD, ecc.). È un database conforme a LDAP che contiene oggetti. Gli oggetti più comunemente usati sono utenti, computer e gruppi. Questi oggetti possono essere organizzati in unità organizzative (OU) per qualsiasi numero di esigenze logiche o aziendali. Gli oggetti Criteri di gruppo (GPO) possono quindi essere collegati alle unità organizzative per centralizzare le impostazioni per vari utenti o computer all'interno di un'organizzazione.

Quando le persone dicono "Active Directory", in genere si riferiscono a "Servizi di dominio Active Directory". È importante notare che esistono altri ruoli / prodotti di Active Directory come Servizi certificati, Servizi federativi, Servizi di directory leggera, Servizi di gestione dei diritti, ecc. Questa risposta si riferisce specificamente ai servizi di dominio Active Directory.

Cos'è un dominio e cos'è una foresta?

Una foresta è un limite di sicurezza. Gli oggetti in foreste separate non sono in grado di interagire tra loro, a meno che gli amministratori di ciascuna foresta separata non creino una fiducia reciproca. Ad esempio, un account Enterprise Administrator per domain1.com, che di solito è l'account più privilegiato di una foresta, non avrà alcuna autorizzazione in una seconda foresta denominata domain2.com, anche se quelle foreste esistono all'interno della stessa LAN, a meno che non sia presente un trust .

Se si dispone di più unità aziendali disgiunte o se sono necessari limiti di sicurezza separati, sono necessarie più foreste.

Un dominio è un limite di gestione. I domini fanno parte di una foresta. Il primo dominio in una foresta è noto come dominio radice della foresta. In molte organizzazioni di piccole e medie dimensioni (e anche di grandi dimensioni), troverai un solo dominio in una singola foresta. Il dominio radice della foresta definisce lo spazio dei nomi predefinito per la foresta. Ad esempio, se viene chiamato il primo dominio in una nuova foresta domain1.com, quello è il dominio radice della foresta. Se hai bisogno di un dominio figlio, ad esempio una filiale a Chicago, potresti nominare il dominio figlio chi. Il nome FQDN del dominio figlio sarebbechi.domain1.com. Puoi vedere che il nome del dominio figlio era anteposto al nome del dominio radice della foresta. In genere è così che funziona. Puoi avere spazi dei nomi disgiunti nella stessa foresta, ma questa è un'intera lattina separata di worm per un tempo diverso.

Nella maggior parte dei casi, ti consigliamo di provare a fare tutto il possibile per avere un singolo dominio AD. Semplifica la gestione e le versioni moderne di AD rendono molto semplice delegare il controllo basato sull'unità organizzativa, il che riduce la necessità di domini secondari.

Posso nominare il mio dominio come voglio, giusto?

Non proprio. dcpromo.exe, lo strumento che gestisce la promozione di un server in un controller di dominio non è a prova di idiota. Ti consente di prendere decisioni sbagliate con il tuo nome, quindi presta attenzione a questa sezione se non sei sicuro. (Modifica: dcpromo è obsoleto nel Server 2012. Utilizzare il Install-ADDSForestcmdlet di PowerShell o installare Servizi di dominio Active Directory da Server Manager.)

Prima di tutto, non usare TLD inventati come .local, .lan, .corp o qualsiasi altra merda. Quei TLD non sono riservati. ICANN sta vendendo TLD ora, quindi il tuo mycompany.corpche stai usando oggi potrebbe effettivamente appartenere a qualcuno domani. Se possiedi mycompany.com, allora la cosa intelligente da fare è usare qualcosa di simile internal.mycompany.como ad.mycompany.comper il tuo nome di annuncio interno. Se utilizzi mycompany.comcome sito Web risolvibile esternamente, dovresti evitare di utilizzarlo anche come nome AD interno, poiché finirai con un DNS split-brain.

Controller di dominio e cataloghi globali

Un server che risponde alle richieste di autenticazione o autorizzazione è un controller di dominio (DC). Nella maggior parte dei casi, un controller di dominio conterrà una copia del catalogo globale . Un catalogo globale (GC) è un insieme parziale di oggetti in tutti i domini di una foresta. È direttamente ricercabile, il che significa che le query tra domini possono di solito essere eseguite su un GC senza bisogno di un riferimento a un controller di dominio nel dominio di destinazione. Se viene eseguita una query su un controller di dominio sulla porta 3268 (3269 se si utilizza SSL), verrà eseguita una query sul GC. Se viene interrogata la porta 389 (636 se si utilizza SSL), viene utilizzata una query LDAP standard e gli oggetti esistenti in altri domini potrebbero richiedere un riferimento .

Quando un utente tenta di accedere a un computer collegato a AD utilizzando le proprie credenziali AD, la combinazione nome utente e password salata e con hash viene inviata al controller di dominio sia per l'account utente che per l'account computer che accedono. Sì, il anche il computer accede. Questo è importante, perché se succede qualcosa all'account del computer in AD, come qualcuno reimposta l'account o lo elimina, potresti ricevere un errore che dice che non esiste una relazione di fiducia tra il computer e il dominio. Anche se le credenziali di rete vanno bene, il computer non è più attendibile per accedere al dominio.

Preoccupazioni sulla disponibilità dei controller di dominio

Sento "Possiedo un controller di dominio primario (PDC) e desidero installare un controller di dominio di backup (BDC)" molto più frequentemente che mi piacerebbe credere. Il concetto di PDC e BDC è morto con Windows NT4. L'ultimo bastione per PDC era in un AD in modalità mista di transizione di Windows 2000 quando c'erano ancora DC NT4 in giro. Fondamentalmente, a meno che tu non supporti un'installazione di oltre 15 anni che non è mai stata aggiornata, in realtà non hai un PDC o un BDC, hai solo due controller di dominio.

Più controller di dominio sono in grado di rispondere alle richieste di autenticazione da diversi utenti e computer contemporaneamente. Se uno fallisce, gli altri continueranno a offrire servizi di autenticazione senza dover rendere un "primario" come avresti dovuto fare nei giorni NT4. È consigliabile disporre di almeno due controller di dominio per dominio. Questi controller di dominio devono entrambi contenere una copia del GC e devono essere entrambi server DNS che contengono una copia delle zone DNS integrate di Active Directory anche per il tuo dominio.

Ruoli FSMO

"Quindi, se non ci sono PDC, perché esiste un ruolo PDC che può avere un solo controller di dominio?"

Lo sento molto. Esiste un ruolo di emulatore PDC . È diverso dall'essere un PDC. In effetti, ci sono 5 ruoli flessibili Single Master Operations (FSMO) . Questi sono anche chiamati ruoli Operations Master. I due termini sono intercambiabili. Cosa sono e cosa fanno? Buona domanda! I 5 ruoli e la loro funzione sono:

Master dei nomi di dominio : esiste un solo master dei nomi di dominio per foresta. Il Domain Naming Master si assicura che quando un nuovo dominio viene aggiunto a una foresta sia unico. Se il server che ricopre questo ruolo non è in linea, non sarà possibile apportare modifiche allo spazio dei nomi di AD, che include elementi come l'aggiunta di nuovi domini figlio.

Schema Master - Esiste un solo Schema Operations Master in una foresta. È responsabile dell'aggiornamento dello schema di Active Directory. Le attività che lo richiedono, come la preparazione di Active Directory per una nuova versione di Windows Server funzionante come controller di dominio o l'installazione di Exchange, richiedono modifiche allo schema. Queste modifiche devono essere eseguite dal Schema Master.

Master infrastruttura : esiste un master infrastruttura per dominio. Se hai un solo dominio nella tua foresta, non devi davvero preoccupartene. Se si dispone di più foreste, è necessario assicurarsi che questo ruolo non sia ricoperto da un server che è anche titolare di un GC, a meno che ogni controller di dominio nella foresta non sia un GC . Il master dell'infrastruttura ha la responsabilità di assicurarsi che i riferimenti tra domini siano gestiti correttamente. Se un utente in un dominio viene aggiunto a un gruppo in un altro dominio, il master dell'infrastruttura per i domini in questione si assicura che sia gestito correttamente. Questo ruolo non funzionerà correttamente se si trova in un catalogo globale.

Master RID : il Relative ID Master (RID Master) è responsabile dell'emissione di pool RID ai controller di dominio. Esiste un master RID per dominio. Qualsiasi oggetto in un dominio AD ha un identificativo di sicurezza (SID) univoco. È costituito da una combinazione dell'identificatore di dominio e di un identificatore relativo. Ogni oggetto in un determinato dominio ha lo stesso identificatore di dominio, quindi l'identificatore relativo è ciò che rende gli oggetti unici. Ogni controller di dominio ha un pool di ID relativi da utilizzare, quindi quando il controller di dominio crea un nuovo oggetto, aggiunge un RID che non ha ancora utilizzato. Poiché i controller di dominio vengono generati pool non sovrapposti, ogni RID dovrebbe rimanere unico per la durata della vita del dominio. Quando un controller di dominio arriva a ~ 100 RID rimasti nel suo pool, richiede un nuovo pool dal master RID. Se il master RID non è in linea per un lungo periodo di tempo, la creazione dell'oggetto potrebbe non riuscire.

Emulatore PDC - Infine, arriviamo al ruolo più ampiamente frainteso di tutti, il ruolo dell'emulatore PDC. Esiste un emulatore PDC per dominio. Se si verifica un tentativo di autenticazione non riuscito, viene inoltrato all'emulatore PDC. L'emulatore PDC funziona come "tie-breaker" se una password è stata aggiornata su un controller di dominio e non è stata ancora replicata sugli altri. L'emulatore PDC è anche il server che controlla la sincronizzazione temporale nel dominio. Tutti gli altri controller di dominio sincronizzano il loro tempo dall'emulatore PDC. Tutti i client sincronizzano il proprio tempo dal controller di dominio a cui hanno effettuato l'accesso. È importante che tutto rimanga entro 5 minuti l'uno dall'altro, altrimenti Kerberos si rompe e quando ciò accade, tutti piangono.

La cosa importante da ricordare è che i server su cui girano questi ruoli non sono messi in pietra. Di solito è banale spostare questi ruoli, quindi mentre alcuni controller di dominio fanno leggermente più di altri, se scendono per brevi periodi di tempo, tutto funzionerà normalmente. Se rimangono inattivi per lungo tempo, è facile trasferire in modo trasparente i ruoli. È molto più bello dei giorni NT4 PDC / BDC, quindi per favore smetti di chiamare i tuoi DC con quei vecchi nomi. :)

Quindi, um ... come fanno i DC a condividere informazioni se possono funzionare indipendentemente l'uno dall'altro?

Replica, ovviamente . Per impostazione predefinita, i controller di dominio appartenenti allo stesso dominio nello stesso sito replicheranno i loro dati a intervalli di 15 secondi. Questo assicura che tutto sia relativamente aggiornato.

Ci sono alcuni eventi "urgenti" che innescano la replica immediata. Questi eventi sono: un account viene bloccato per troppi accessi non riusciti, viene apportata una modifica alla password del dominio o ai criteri di blocco, il segreto LSA viene modificato, la password viene modificata sull'account del computer di un controller di dominio o il ruolo RID Master viene trasferito a un nuovo DC. Uno di questi eventi attiverà un evento di replica immediata.

Le modifiche alle password si collocano tra urgenti e non urgenti e vengono gestite in modo univoco. Se la password di un utente viene modificata DC01e un utente tenta di accedere a un computer che esegue l'autenticazione DC02prima che si verifichi la replica, ti aspetteresti che ciò fallisca, giusto? Fortunatamente ciò non accade. Supponiamo che qui sia chiamato anche un terzo controller di dominio DC03che detiene il ruolo di emulatore PDC. Quando DC01viene aggiornato con la nuova password dell'utente, anche quella modifica viene immediatamente replicata DC03. Quando il tentativo di autenticazione DC02fallisce, DC02quindi inoltra il tentativo di autenticazione DC03, il che verifica che sia effettivamente valido e l'accesso è consentito.

Parliamo di DNS

Il DNS è fondamentale per un AD correttamente funzionante. La linea ufficiale di Microsoft party è che qualsiasi server DNS può essere utilizzato se impostato correttamente. Se provi a utilizzare BIND per ospitare le tue zone AD, sei in alto. Sul serio. Attenersi all'utilizzo delle zone DNS integrate AD e, se necessario, utilizzare gli spedizionieri condizionali o globali per altre zone. Tutti i client devono essere configurati per utilizzare i server DNS AD, quindi è importante disporre di ridondanza qui. Se si dispone di due controller di dominio, è necessario eseguire entrambi DNS e configurare i client per utilizzarli entrambi per la risoluzione dei nomi.

Inoltre, vorrai assicurarti che, se hai più di un controller di dominio, non vengano elencati per primi per la risoluzione DNS. Ciò può portare a una situazione in cui si trovano su "un'isola di replica" in cui sono disconnessi dal resto della topologia di replica di Active Directory e non possono essere ripristinati. Se hai due server DC01 - 10.1.1.1e DC02 - 10.1.1.2, allora il loro elenco di server DNS dovrebbe essere configurato in questo modo:

Server: DC01 (10.1.1.1)
DNS primario - 10.1.1.2
DNS secondario - 127.0.0.1

Server: DC02 (10.1.1.2)
DNS primario - 10.1.1.1 DNS
secondario - 127.0.0.1

OK, questo sembra complicato. Perché voglio usare AD?

Perché una volta che sai cosa stai facendo, la tua vita diventa infinitamente migliore. AD consente la centralizzazione della gestione di utenti e computer, nonché la centralizzazione dell'accesso e dell'utilizzo delle risorse. Immagina una situazione in cui hai 50 utenti in un ufficio. Se si desidera che ciascun utente disponga del proprio accesso a ciascun computer, è necessario configurare 50 account utente locali su ciascun PC. Con AD, devi creare l'account utente solo una volta e può accedere a qualsiasi PC sul dominio per impostazione predefinita. Se volessi rafforzare la sicurezza, dovresti farlo 50 volte. Una specie di incubo, vero? Immagina anche di avere una condivisione file a cui vuoi solo la metà di quelle persone. Se non stai utilizzando AD, dovrai replicare il nome utente e le password manualmente sul server per fornire un accesso apparente, oppure " Devo creare un account condiviso e fornire a ciascun utente il nome utente e la password. Un modo significa che conosci (e devi aggiornare costantemente) le password degli utenti. L'altro modo significa che non hai audit trail. Non va bene, vero?

Hai anche la possibilità di utilizzare Criteri di gruppo quando hai impostato AD. Criteri di gruppo è un insieme di oggetti collegati a unità organizzative che definiscono le impostazioni per utenti e / o computer in tali unità organizzative. Ad esempio, se si desidera che "Arresto" non sia presente nel menu di avvio per 500 PC da laboratorio, è possibile farlo in un'impostazione in Criteri di gruppo. Invece di dedicare ore o giorni alla configurazione manuale delle voci di registro corrette, si crea un oggetto Criteri di gruppo una volta, lo si collega all'unità organizzativa o alle unità organizzative corrette e non ci si deve più ripensare. Esistono centinaia di oggetti Criteri di gruppo che possono essere configurati e la flessibilità dei Criteri di gruppo è uno dei motivi principali per cui Microsoft è così dominante nel mercato aziendale.

Nota: questa risposta è stata unita a questa domanda da una domanda diversa che faceva domande sulle differenze tra foreste, domini figlio, alberi, siti e unità organizzative. Questo non è stato originariamente scritto come una risposta a questa domanda specifica.

foresta

Vuoi creare una nuova foresta quando hai bisogno di un limite di sicurezza. Ad esempio, potresti avere una rete perimetrale (DMZ) che desideri gestire con AD, ma non desideri che l'AD interno sia disponibile nella rete perimetrale per motivi di sicurezza. In questo caso, si desidera creare una nuova foresta per quella zona di sicurezza. Puoi anche desiderare questa separazione se hai più entità che non si fidano l'una dell'altra, ad esempio una società di comodo che comprende singole aziende che operano in modo indipendente. In questo caso, si desidera che ogni entità abbia la propria foresta.

Dominio figlio

Davvero, non ti servono più. Ci sono alcuni buoni esempi di quando vorresti un dominio figlio. Un motivo legacy è dovuto ai diversi requisiti dei criteri password, ma questo non è più valido, poiché dal Server 2008 sono disponibili Criteri password dettagliati. È necessario un dominio figlio solo se si dispone di aree con un'incredibile scarsa connettività di rete e si desidera per ridurre drasticamente il traffico di replica: una nave da crociera con connettività WAN satellitare è un buon esempio. In questo caso, ogni nave da crociera può essere il proprio dominio figlio, in modo da essere relativamente autonoma pur essendo in grado di sfruttare i vantaggi di trovarsi nella stessa foresta di altri domini della stessa compagnia.

Albero

Questa è una palla strana. I nuovi alberi vengono utilizzati quando si desidera mantenere i vantaggi di gestione di una singola foresta ma si ha un dominio in un nuovo spazio dei nomi DNS. Ad esempio, corp.example.compotrebbe essere la radice della foresta, ma potresti avere ad.mdmarra.comnella stessa foresta utilizzando un nuovo albero. Qui si applicano le stesse regole e raccomandazioni per i domini figlio: usali con parsimonia. Di solito non sono necessari nei moderni annunci pubblicitari.

Posto

Un sito dovrebbe rappresentare un limite fisico o logico nella tua rete. Ad esempio, filiali. I siti vengono utilizzati per selezionare in modo intelligente i partner di replica per i controller di dominio in diverse aree. Senza definire i siti, tutti i controller di dominio verranno trattati come se si trovassero nella stessa posizione fisica e si replicassero in una topologia di mesh. In pratica, la maggior parte delle organizzazioni sono configurate logicamente in un hub e parlato, quindi i siti e i servizi dovrebbero essere configurati per riflettere questo.

Altre applicazioni utilizzano anche siti e servizi. DFS lo utilizza per i riferimenti allo spazio dei nomi e la selezione dei partner di replica. Exchange e Outlook lo usano per trovare il catalogo globale "più vicino" a cui interrogare. I computer aggiunti al dominio lo utilizzano per individuare i controller di dominio "più vicini" per l'autenticazione. Senza questo, il tuo traffico di replica e autenticazione è come il selvaggio West.

Unità organizzativa

Questi dovrebbero essere creati in modo tale da riflettere la necessità dell'organizzazione di delegare l'autorizzazione e l'applicazione dei criteri di gruppo. Molte organizzazioni dispongono di un'unità organizzativa per sito, in quanto applicano l'oggetto Criteri di gruppo in questo modo - questo è stupido, perché è possibile applicare l'oggetto Criteri di gruppo a un sito anche da siti e servizi. Altre organizzazioni separano le unità organizzative per dipartimento o funzione. Questo ha senso per molte persone, ma il design delle unità organizzative dovrebbe soddisfare le tue esigenze ed è piuttosto flessibile. Non esiste un "solo modo" per farlo.

Una multinazionale può avere di primo livello le unità organizzative di North America, Europe, Asia, South America, Africain modo che possano delegare privilegi amministrativi sulla base di continente. Altre organizzazioni possono avere di livello superiore unità organizzative di Human Resources, Accounting, Sales, ecc se questo ha più senso per loro. Altre organizzazioni hanno esigenze politiche minime e usano un layout "piatto" con solo Employee Userse Employee Computers. Non c'è davvero nessuna risposta giusta qui, è qualunque cosa soddisfi le esigenze della tua azienda.