Ce este Active Directory?

Ca ș i alte servicii de directoare, cum ar fi serviciile de directoare Novell (NDS), Active Directory este un sistem centralizat ș i standardizat
sistem care automatizează gestionarea reț elei de date ale utilizatorilor, securitate ș i resurse distribuite ș i permite interoperabilitatea cu
alte directoare.

Active Directory (AD) este o tehnologie creată de Microsoft pentru a oferi servicii de reț ea, inclusiv servicii de director LDAP;
Autentificarea bazată pe Kerberos, denumirea DNS, accesul securizat la resurse ș i altele. Active Directory foloseș te o singură bază de date Jet.
care o varietate de servicii ș i aplicaț ii pot folosi pentru a accesa ș i stoca o varietate de informaț ii. Active Directory este utilizat de
administratorii de sistem pentru a stoca informaț ii despre utilizatori, a atribui politici de securitate ș i a desfăș ura software. AD este utilizat în multe

tipuri ș i dimensiuni diferite de medii, de la cele foarte mici (o duzină de utilizatori) la sute de mii de utilizatori la nivel global
mediu.
Active Directory este conceput în special pentru medii de reț ea distribuite.
AD este funcț ional un loc pentru a stoca informaț ii despre oameni, lucruri (computere, imprimante etc.), aplicaț ii, domenii, servicii,
permisiuni de acces la securitate ș i altele. Aplicaț iile ș i serviciile folosesc apoi directorul pentru a îndeplini o funcț ie.

De exemplu, Microsoft Windows foloseș te informaț iile Active Directory pentru a permite unui utilizator să se conecteze la computerul său ș i a oferi

acces la drepturile de securitate atribuite în Active Directory. Windows accesează directorul ș i apoi oferă drepturi pe baza
în funcț ie de ceea ce găseș te. Dacă un cont de utilizator este dezactivat în Active Directory, directorul în sine setează pur ș i simplu un marcaj pe care Windows îl foloseș te

a interzice unui utilizator să se conecteze.

Am men ț ionat în introducere că administratorii folosesc Active Directory pentru a implementa software - acesta este un lucru incomplet
descriere. Administratorii pot stabili politici ș i informaț ii care să fie aplicate pentru o anumită aplicaț ie software care ar trebui să fie implementată într-un anumit

utilizator - AD în sine nu desfăș oară software-ul, ci un serviciu Windows citeș te informaț iile din Active Directory ș i apoi
instalează software-ul.

De ce să implementăm Active Directory?

În primul rând, Microsoft Active Directory este în general considerat a fi o îmbunătăț ire semnificativă faț ă de Windows NT
Domenii Server 4.0 sau chiar reț ele de servere independente. Active Directory are un mecanism de administrare centralizată asupra
întreaga reț ea. De asemenea, oferă redundanț ă ș i toleranț ă la erori atunci când două sau mai multe controlere de domeniu sunt implementate în cadrul unei
domeniu.
Active Directory gestionează automat comunica ț iile între controlerele de domeniu pentru a asigura că re ț eaua rămâne
viabil. Utilizatorii pot accesa toate resursele de pe reț ea pentru care sunt autorizaț i printr-o autentificare unică. Toate resursele în
reț eaua este protejată de un mecanism de securitate robust care verifică identitatea utilizatorilor ș i autorizaț iile resurselor
la fiecare acces.

LDAP (Protocolul de Acces la Directoare Uș or)

Active Directory ș i LDAP
Microsoft includeLDAP(Protocolul de acces la directorul uș or) ca parte a Active Directory. LDAP este un protocol software
pentru a permite oricui să localizeze organizaț ii, indivizi ș i alte resurse precum fiș iere ș i dispozitive într-o reț ea, fie că este pe
internetul public sau pe un intranet corporativ.
Într-o reț ea, un director îț i spune unde în reț ea se află ceva. Pe reț elele TCP/IP (inclusiv Internetul),
sistemul de nume de domeniu (DNS) este sistemul de director utilizat pentru a corela numele de domeniu cu o adresă de reț ea specifică (o adresă unică
locaț ia în reț ea). Cu toate acestea, s-ar putea să nu cunoș ti numele de domeniu. LDAP îț i permite să cauț i persoane fără
ș tiind unde se află (deș i informaț iile suplimentare vor ajuta la căutare).
Un director LDAP este organizat într-o simplă ierarhie „arbore” care constă din următoarele niveluri:
Directorul rădăcină (locul de plecare sau sursa arborelui), care se ramifică în
Ț ările, fiecare dintre ele se ramifică către
Organizaț ii, care se ramifică la
Unităț i organizaț ionale (divizii, departamente ș i aș a mai departe), care se ramifică pentru a include o intrare pentru
•Indivizi (care includ oameni, fiș iere ș i resurse partajate, cum ar fi imprimantele)
Un director LDAP poate fi distribuit între multe servere. Fiecare server poate avea o versiune replicată a întregului director.
care este sincronizat periodic.
Este important ca fiecare administrator să aibă o înț elegere a ceea ce este LDAP atunci când caută informaț ii în Active
Directory ș i a putea creaInterogări LDAP este deosebit de util atunci când cauț i informaț ii stocate în Active
Baza de date a directorului. Din acest motiv, mulț i administratori depun eforturi considerabile pentru astăpâneș te filtrul de căutare LDAP.

Un arbore de directoare LDAP este o structură ierarhică a organizaț iilor, domeniilor, arborilor, grupurilor ș i unităț ilor individuale.

Exemplu de arbore LDAP

Structura Active Directory

Spre deosebire de Windows NT, Active Directory este conceput pentru a crea o ierarhie funcț ională ș i utilizabilă pentru mediul tău.
Nu doar că face ca mediul să pară mai curat, dar permite ș i administratorilor sistemului central să delege anumite
autoritate asupra domeniilor către alț i administratori, membri ai echipei ș i grupuri. AD are o structură foarte flexibilă, permiț ându-ț i să
creează o ierarhie în orice mod dore ș ti – o unitate mare, împăr ț ită pe loca ț ii geografice, pe departamente, pe
semn astronomic, sau cum preferi.

Realizarea acestei flexibilităț i în designul ierarhic este o structură definită. Structura Active Directory începe cu păduri ș i
domenii ș i se coboară la unităț i organizaț ionale ș i obiecte individuale (cum ar fi un cont de utilizator sau de computer).

Componente de bază Active Directory

Oferă blocurile de bază pentru ca oamenii să-ș i construiască propriul director. Aceste blocuri de bază ale Active Directory
includ domenii, controlere de domenii, încrederi, păduri, unităț i organizaț ionale, grupuri, site-uri, replicare ș i catalogul global.
Păduri: Colecț ia fiecărui obiect, a atributelor sale ș i a sintaxei atributelor în Active Directory.
Domeniu: O colecț ie de computere care împărtăș esc un set comun de politici, un nume ș i o bază de date a membrilor lor.
Unităț i organizaț ionale: Containere în care domeniile pot fi grupate. Ele creează o ierarhie pentru domeniu ș i creează
structura companiei Active Directory în termeni geografici sau organizaț ionali.
Site-uri: Grupări fizice independente de structura domeniului ș i OU. Site-urile fac distincț ia între locaț ii conectate prin conexiuni lente.
ș i conexiuni de mare viteză ș i sunt definite de unul sau mai multe subreț ele IP.
Înț elegerea pădurilor

În vârful structurii Active Directory se află o pădure. O pădure conț ine toate obiectele, unităț ile organizaț ionale, domeniile ș i
atributele în ierarhia sa. Sub o pădure se află unul sau mai multe copaci care deț in domenii, OUs, obiecte ș i atribute.
Pădurile nu sunt limitate de geografie sau de topologia reț elei. O singură pădure poate conț ine numeroase domenii, fiecare având o parte comună.
schema comună. Membrii domeniului din aceeaș i pădure nu trebuie nici măcar să aibă o conexiune LAN sau WAN dedicată între ei.
îi. O reț ea unică poate fi de asemenea căminul mai multor păduri independente. Totuș i, păduri suplimentare pot fi dorite pentru
testare ș i cercetare în afara pădurii de producț ie.

Aș a cum este ilustrat în această imagine, există două copaci în pădure. Ai putea folosi o structură ca aceasta pentru organizaț ii cu mai multe
decât o companie de operare.

De asemenea, ai putea proiecta o structură cu mai multe păduri, dar acestea sunt pentru motive foarte specifice ș i nu sunt comune.

Domenii

Inima structurii Active Directory este domeniul. Domeniul este de obicei de tipul denumirii Internet (de exemplu.
[Link]), dar nu eș ti obligat să te ț ii de această structură - ai putea, în mod tehnic, să îț i numeș ti domeniul oricum vrei.
dorinț ă.
Microsoft recomandă să utiliza ț i cât mai pu ț ine domenii posibil în construirea structurii dvs. Active Directory ș i să vă baza ț i pe
Unităț i organizaț ionale pentru structură. Domeniile pot conț ine mai multe OU imbricate, permiț ându-vă să construiț i o structură destul de robustă ș i
structură specifică.

Controlere de domeniu

În Windows NT, domeniile foloseau un model de Controler Principal de Domeniu (PDC) ș i Controler de Domeniu de Rezervă (BDC). Aceasta avea
un singur server, PDC-ul, care era „responsabil” în timp ce celelalte DC-uri erau subordonate. Dacă PDC-ul eș ua, trebuia să promovai un
BDC va deveni PDC ș i va fi serverul responsabil.

În Active Directory, aveț i mai multe Controlere de Domeniu care sunt colegi egali. Fiecare CD în domeniul Active Directory
conț ine o copie a bazei de date AD ș i sincronizează modificările cu toate celelalte DC-uri prin replicare multi-master. Replicare
se întâmplă frecvent ș i pe o bază de solicitare în loc de una de împingere. Un server solicită actualizări de la un coleg controler de domeniu. Dacă
informaț ii despre o schimbare DC (de exemplu, un utilizator îș i schimbă parola), trimite un semnal celorlalte controlere de domeniu pentru a începe o
replicarea prin pull a datelor pentru a asigura că sunt toate actualizate.

Serverele care nu funcț ionează ca DC-uri, dar se află în domeniul Active Directory, se numesc „servere membre.”
Unităț i organizaț ionale

O Unitate Organizatorică (OU) este un container care oferă o ierarhie ș i o structură de domeniu. Este utilizat pentru uș urinț a în administrare.
ș i pentru a crea o structură AD în termenii geografici sau organizaț ionali ai companiei.

Unităț i organizaț ionale

O unei O poate conț ine O-uri, permiț ând crearea unei structuri multi-nivel, aș a cum se arată în imaginea de mai sus. Există trei
principalele motive pentru crearea OUs:

Structura organizaț ională: În primul rând, crearea UO-urilor permite unei companii să construiască o structură în Active Directory care se potriveș te cu

structura geografică sau organizaț ională a firmei. Acest lucru permite o administrare uș oară ș i o structură clară.

Drepturi de securitate: Al doilea motiv pentru a crea o structură OU este de a aloca drepturi de securitate anumitor OU-uri. Acest lucru, de exemplu,

ar permite să aplici Politici Active Directory la un OU care sunt diferite de altul. Ai putea configura politici
care instalează o aplicaț ie de software contabil pe computerele din OU-ul de Contabilitate.

Administrarea Delegată: Al treilea motiv pentru a crea OUs este de a delega responsabilitatea administrativă. Arhitecț ii AD pot
designaț i structura pentru a permite administratorilor locali anumite responsabilităț i administrative pentru OU-ul lor ș i nimic altceva. Aceasta permite
pentru o administraț ie delegată care nu este disponibilă în reț elele Windows NT.

Site-uri
Prin definiț ie, site-urile sunt colecț ii de subreț ele IP care au legături de comunicare rapide ș i fiabile între toate gazdele.

Un obiect de site Active Directory reprezintă o colecț ie de subnete IP, care constituie de obicei o reț ea locală fizică.
(LAN). Multe site-uri sunt conectate pentru replicare prin legături de site. În mod obiș nuit, site-urile sunt folosite pentru:

Determinarea locaț iei fizice: Permite clienț ilor să găsească resurse locale, cum ar fi imprimante, partajări sau controlere de domeniu.

Replicare: Puteț i optimiza replicarea între controlerele de domeniu prin crearea de legături.

Imediat, Active Directory foloseș te acoperire automată a site-urilor, deș i poț i să configurezi intenț ionat site-uri ș i resurse.

Grupuri

Grupele îndeplinesc două funcț ii în Active Directory: securitate ș i distribuț ie.

Un grup de securitate conț ine conturi care pot fi utilizate pentru accesul la securitate. De exemplu, un grup de securitate ar putea fi atribuit
drepturi asupra unui anumit director pe un server de fiș iere.

Un grup de distribuț ie este folosit pentru a trimite informaț ii utilizatorilor. Nu poate fi folosit pentru acces la securitate.

Există trei tipuri de grupuri:

Global: Grupurile de securitate globale conț in utilizatori doar din domeniul în care sunt create. Grupurile de securitate globale pot fi
membri ai grupurilor Universale ș i Locale de Domeniu.

Universal: Grupurile de securitate cu domeniu universal pot conț ine utilizatori, grupuri globale ș i grupuri universale din orice domeniu. Acestea
grupurile sunt folosite de obicei într-un mediu multi-domeniu dacă este necesar accesul între domenii.

Local de domeniu: Grupurile cu domeniu local sunt adesea create în domenii pentru a atribui acces de securitate unui anumit domeniu local.
resursă. Grupurile de domeniu locale pot conț ine conturi de utilizator, grupuri universale ș i grupuri globale din orice domeniu.
Grupurile cu domeniu local pot conț ine grupuri locale de domeniu în acelaș i domeniu.

Relaț ii de încredere

Relaț iile de încredere sunt importante într-un mediu Active Directory astfel încât pădurile ș i domeniile să poată comunica între ele.
un alt ș i treceț i acreditivele. În cadrul unei singure păduri, încrederile sunt create atunci când un domeniu este creat. Implicit, domeniile au un
încredere transdimensională bidirecț ională implicit creată. Aceasta înseamnă că fiecare domeniu se încrede unul în altul pentru accesul la securitate ș i acreditive. Un utilizator

în domeniul A poate accesa resursele permise lui în domeniul B în timp ce un utilizator din domeniul B poate accesa resursele permise
ea în domeniul A.

AD permite crearea mai multor tipuri diferite de încrederi, dar înț elegerea încrederii transitive bidirecț ionale este cea mai importantă
pentru a înț elege AD.

Replicare
Înț elegerea replicării Active Directory
Replicarea Active Directoryeste cheia sănătăț ii ș i stabilităț ii unui mediu Active Directory. Fără o gestionare adecvată ș i la timp
replicare, un domeniu nu va putea funcț iona eficient. Replicarea este procesul de trimitere a informaț iilor de actualizare pentru date
care s-a schimbat în director către alte controlere de domeniu. Este important să aveț i o înț elegere fermă a replicării ș i
cum se desfăș oară, atât în domeniu, cât ș i în medii cu mai multe locaț ii.
Există trei elemente principale sau componente care sunt replicate între controlerele de domeniu: replica partiț iei de domeniu,
catalogul global ș ischema.
Partiț ia de domeniu replică baza de date Active Directory a unui domeniu. Fiecare controler de domeniu menț ine o copie duplicat.
al replicatului său de partiț ie a domeniului local. Controlerele de domeniu nu menț in copii ale replicatelor din alte domenii. Când un
administratorul face o modificare în domeniu, modificarea respectivă este replicată imediat la toate controlerele de domeniu.
Fiecare pădure conț ine doar un singur catalog global. Prin default, primul controler de domeniu instalat într-o pădure este catalogul global.
server de catalog. Catalogul global conț ine o replică parț ială a fiecărui obiect din fiecare domeniu al pădurii. Catalogul global
catalogul serveș te ca un index principal pentru pădure, ceea ce permite căutări easy ș i eficiente pentru utilizatori, computere, resurse
ș i alte obiecte. Orice controler de domeniu poate fi configurat pentru a acț iona ca un server de catalog global peer. Ar trebui să aveț i cel puț in două
servere de catalog global pe domeniu ș i cel puț in unul pe site. Pe măsură ce se fac modificări asupra obiectelor din pădure, catalogul global
este actualizat. Odată ce catalogul global este modificat pe un controller de domeniu, acesta este replicat la toate celelalte controlere de domeniu din
pădure.
Fiecare controler de domeniu dintr-o pădure are o copie a schemei. Aș a cum se întâmplă ș i cu modificările aduse bazei de date Active Directory (adică,
replica de partiț ie a domeniului), orice modificări aduse schemei Active Directory sunt replicate tuturor celorlalte controale de domeniu din
pădure. Din fericire, schema este de obicei statică, aș a că există puț in trafic de replicare cauzat de modificările schemei.

Replicare multi-master
În interiorul domeniilor Active Directory bazate pe Windows, fiecare controler de domeniu este un server peer. Fiecare controler de domeniu are egalitate
puterea ș i responsabilitatea de a sprijini ș i menț ine baza de date Active Directory. Această bază de date este esenț ială pentru bună-
ființ a ș i existenț a domeniului în sine. Aceasta este o sarcină atât de importantă încât Microsoft a ales să facă posibilă desfăș urarea
sisteme multi-redundante pentru a susț ine Active Directory prin transformarea fiecărui controler de domeniu într-un partener.

Ori de câte ori apare o schimbare la un obiect dintr-un domeniu Active Directory, acea schimbare este replicată automat tuturor
controlere de domeniu în cadrul domeniului. Acest proces se nume ș tereplicare multi-master Replica ț ia multi-master nu
se întâmplă instantaneu pe toate serverele simultan. Mai degrabă, este un proces controlat în care fiecare coleg controler de domeniu este
actualizat ș i validat într-o procedură controlată logic.
Ca administrator, ai un anumit control asupra modului în care are loc replicaț ia multi-master. Cel mai mult control îl obț ii
prin utilizarea site-urilor. Un site este o denumire logică a controlerilor de domeniu într-o reț ea care sunt toț i localizaț i într-un anumit
zona fizică. În cele mai multe cazuri, site-urile controlează traficul pe linkuri WAN de mare cost ș i lăț ime de bandă mică. Când un domeniu există pe două
pentru mai multe site-uri, replicarea normală Active Directory între controlerele de domeniu din site-uri diferite este terminată. În schimb, un
un singur server în fiecare site, etichetat ca server bridgehead, efectuează toate comunicaț iile de replicare. Puteț i configura aceasta.
server de punct de trecere pentru când replicarea este permisă să aibă loc ș i cât de mult trafic poate genera când efectuează replicarea.
Puteț i utiliza site-uri pentru a controla replicarea chiar dacă nu utilizaț i legături WAN în reț eaua dvs. Site-urile oferă efectiv
administratori controlează modul ș i momentul în care replicarea multi-master AD are loc în reț eaua lor.

Proiectarea topologiei de replicare Active Directory

Unul dintre secretele unei infrastructuri Active Directory eficiente ș i fără erori este o topologie de replicare bine concepută. În timp ce
aceasta poate fi uș or de proiectat într-o reț ea simplă, o reț ea mare ș i complexă prezintă o provocare. Proiectarea topologiei AD
eficient este să-l construieș ti astfel încât să profite de punctele forte ș i să minimizeze slăbiciunile reț elei. Într-o
reț ea complexă, este probabil să aveț i un număr de viteze de link diferite care conectează locaț ii îndepărtate.

Thecele mai bune practici pentru designul replicării Active Directoryinclude:

1. Proiectaț i topologia AD pentru a profita de topologia reț elei ș i de vitezele legăturilor.
2. Definirea link-urilor cu viteză mai mică ș i costuri mai mari pentru site-uri. Costul link-urilor se reduce pe măsură ce ajungi la
zone mai rapide în topologie.
3. Evitaț i „zonele moarte” - toate site-urile trebuie să se conecteze între ele, în cele din urmă. Am văzut unele topologii
a lăsat anumite site-uri izolate deoarece nu au proiectat linkurile site-ului pentru a le conecta.
4. Linkurile site-ului ar trebui să aibă doar două site-uri per link. Excepț ia de la aceasta este linkul site-ului Core, care poate
aveț i mai multe. Definirea mai mult de două site-uri per link poate duce la rezultate imprevizibile în cazul unei defecț iuni DC
apare.
5. Diagramaț i fluxul general al replicării (ca în figurile de aici). Puteț i folosi caracteristici sofisticate.
disponibil în instrumente precum HP OpenView (vezi exemplul din Figura 3) sau Microsoft MOM, sau pur ș i simplu
desenează-l într-o diapozitiv PowerPoint aș a cum am făcut eu în Figura 2. Vei fi surprins de câte erori vei găsi prin
realizând un desen al topologiei.
6. Nu defini programarea decât dacă ai cu adevărat un motiv întemeiat, iar apoi ar trebui să o testezi.
în mod temeinic. Deoarece poț i planifica replicarea prin legătura site-ului, precum ș i prin obiectul de conexiune în sine, ș i
deoarece programul de replicare rezultat este o combinaț ie a celor două, poț i ajunge cu un program care interzice
replicare. De asemenea, define ș ti frecven ț a replicării, ceea ce complică ș i mai mult lucrurile. De exemplu, dacă tu
programează link-urile site-ului să se repete de luni până vineri între orele 8:00 ș i 18:00, iar apoi să ai câteva
 obiecte de conexiune care replică doar marț ea ș i joia între 18:00 ș i 22:00, acele conexiuni
obiectele nu vor replica niciodată. Cu excepț ia cazului în care aveț i o reț ea foarte lentă sau limitată (cum ar fi conexiunile VPN),
ar trebui să evite acest nivel de intervenț ie manuală.

7. Rulaț i AD în modul Forest Windows 2003. Aceasta înseamnă că toate DC-urile sunt pe Windows Server 2003 ș i
toate domeniile rulează în modul Windows 2003. Aceasta profită de noua structură a arborelui de extensie ș i
algoritmi de compresie disponibili în Windows Server 2003, precum ș i alte caracteristici care fac replicarea
mult mai eficiente decât cele disponibile în Windows 2000.
8. Monitorizează AD-ul. Odată ce l-ai pus în aplicare, monitorizează-l. Una dintre cele mai simple modalităț i de a-l monitoriza, în afară de
de utilizarea instrumentelor Microsoft sau ale terț ilor, se utilizează instrumentul Repadmin ș i opț iunea sa "Replsum": Repadmin
/replsum /bydest /bysrc /sort:delta. Acest lucru va oferi un tabel frumos ș i ordonat cu toate DC-urile din toate domeniile din pădure.
spunându-ț i cât de mult timp a trecut pentru replicarea externă ș i internă (adică unde fiecare DC apare ca un
sursa ș i destinaț ia). Observând asta timp de câteva zile, vei avea ocazia să găseș ti orice lacune în
topologie.

Depanarea replicării Active Directory

Replicarea ar trebui să se desfăș oare automat. Când nu se întâmplă, cea mai bună soluț ie nu este doar să forț ăm replicarea Active Directory, ci
pentruverificătopologiaDacă topologia de replicare a devenit instabilă sau configurată greș it, trebuie corectată înainte de
iniț ierea unei proceduri manuale de replicare.
Verificatorul de consistenț ă a cunoș tinț elor (KCC) creează automat topologia de replicare utilizată pentru replicarea intra-site.
În loc să creeze o reț ea completă pentru replicare, KCC proiectează o topologie în care fiecare DC are cel puț in două replicări.
parteneri ș i nu este mai mult de trei salturi de orice alt DC. Cu o astfel de topologie, fiecare DC poate fi complet actualizat cu
cât mai puț in de trei cicluri de replicare.
TheInstrumentul REPAdmindin Instrumentele de Suport Windows ș i Kitul de Resurse pot fi folosite pentru a verifica topologia. Comanda
"repadmin /showreps" se execută pe un controler de domeniu ș i produce o listă de parteneri de replicare aș a cum sunt desemnaț i de KCC. Pentru
verificaț i topologia, verificaț i dacă fiecare DC listează cel puț in doi parteneri de replicare ș i că toț i partenerii numiț i se văd unii pe alț ii ca
parteneri. De exemplu, dacă Serverul A listează Serverul B ș i C ca parteneri, atunci atât Serverul B cât ș i C ar trebui să listeze Serverul A înapoi ca un
partener. Dacă descoperiț i o problemă sau o inconsistenț ă în topologie, folosiț i KCC pentru a regenera topologia.
Odată ce eș ti sigur că topologia este corectă, atunci ș i numai atunci ar trebui săforț ează replicarea Active Directory.

Depanarea erorilor de replicare

Cea mai mare parte a problemelor din Active Directory este cauzată, într-o anumită măsură, de eș ecurile de replicare, iar unul dintre cele mai notabile
erori de replicare este1311.
Primul pas în rezolvarea acestei erori de replicare este să determinăm amploarea erorii. Cea mai uș oară modalitate de a face acest lucru este cu
comanda theRepadmin/Replsum. Aceasta îț i va oferi un rezumat complet al tuturor DC-urilor din pădure, inclusiv cele relevante
ID-ul evenimentului dacă este într-o stare de eroare. Forma generală a comenzii este aceasta:

Repadmin /Replsum /bysrc /bydest /sort:delta

Iată un exemplu de rezultat al acestei comenzi. Observaț i că există patru controlere de domeniu care eș uează replicarea. Deș i 1311 poate
nu apare în rezultatul acestui comandament, este comun să fie asociat cu evenimentul 1722 (care în esenț ă înseamnă că nu
conectivitate fizică). Evident, dacă nu există conectivitate fisică (ceea ce ar însemna că a existat o defec ț iune a re ț elei),
replicarea nu va avea loc. Primul lucru de făcut este să verificaț i starea generală a domeniului folosind Repadmin
/replsumcommand a fost descris anterior. De asemenea, poț i să verifici DC-urile defecte prin adresă ș i FQDN, iar tu poț i să rulezi NetDiag ș i
Comenzile DCDiag din linia de comandă (cu opț iunea /v activată pentru fiecare). Aceasta vă va oferi mai multe detalii despre erori ș i
poate relaț ionate.
Notă: Reț eaua care conectează toate site-urile ar trebui să fie complet rutată. Nu creaț i un link de site dacă nu există un link de reț ea subliniat.
obț ineț i între site-uri în linkul site-ului.
Conectivitatea logică este pu ț in mai dificil de diagnosticat. Asta înseamnă, pe scurt, că ceva în topologia site-ului AD
configuraț ia este greș ită, creând o breș ă în topologie. Acest lucru ar putea fi rezolvat prin una dintre următoarele acț iuni: configurarea unei
server de punte preferat, asigurându-vă că toate site-urile sunt definite în linkurile site-urilor ș i asigurându-vă că există o reț ea completă de site-uri în
link-uri site.
DNSde asemenea, trebuie să fie luat în considerare. Având în vedere că replicarea Active Directory se bazează pe rezolvarea numelui DNS pentru a găsi DC-uri pentru
replica cu, dacă DNS-ul este defect, ar putea cauza apariț ia evenimentelor 1311. Ceea ce este util aici este că, dacă DNS-ul este vinovat,
evenimentul 1311 va avea fraza "Eș ec la căutarea DNS" inclusă în descriere. Dacă vezi această frază, atunci te
absolut, cu siguranț ă aveț i o problemă DNS care trebuie rezolvată.
Când depanaț i evenimentele 1311, ar trebui să obț ineț i o imagine de ansamblu a întregului domeniu pentru a vedea care DC-uri nu se replică. Puteț i face acest lucru
cu uș urinț ă folosind comanda Repadmin /Replsum. Reț ineț i că pierderea conectivităț ii fizice, o topologie AD incompletă sau
Eș ecul DNS cauzează de obicei aceste evenimente, cu o ș ansă mică ca acesta să fie un obiect părăsit (un obiect care nu poate fi găsit în
arborii de directoare). De obicei, alte evenimente vor însoț i acele evenimente, cum ar fi 1722 (Server RPC indisponibil), sau evenimentul va
conț ine o declaraț ie descriptivă precum „Eș ec DNS”. Acesta este un eveniment critic care trebuie rezolvat pentru ca
Replicarea Active Directory trebuie să funcț ioneze corect pe toate DC-urile.

Deoarece cele mai multe reț ele Active Directory conț in mai mulț i controlori de domeniu ș i utilizatorii ar putea teoretic să se conecteze la orice DC pentru

autentificare sau informa ț ie, fiecare dintre servere trebuie men ț inut la zi. Controlerele de domeniu rămân la zi prin
replicarea bazei de date între ele. Aceasta se efectuează folosind o metodă de tip apull – serverul solicită noi informaț ii de la o
diferite DC frecvent. După o schimbare, DC iniț iază o replicare după ce a aș teptat 15 secunde (în Windows 2003) sau 5
minute (în Windows 2000). Windows Server 2003 utilizează tehnologia pentru a replica doar informaț iile modificate ș i compresia.
replicare pe legături WAN.

Windows Server configurează o topologie de replicare pentru a determina de unde se actualizează un server. Într-o reț ea mare, acest lucru menț ine
timpul de replicare scade pe măsură ce serverele se replică într-o formă de reț ea în cerc.

Active Directory foloseș te replicarea multi-master. Replicarea multimaster nu se bazează pe un singur controler de domeniu primar.
dar în schimb tratează fiecare DC ca pe o autoritate. Când se face o schimbare pe orice DC, aceasta este replicată la toate celelalte DC-uri. Deș i fiecare
DC-urile sunt replicate în mod similar, dar nu toate DC-urile sunt egale. Există mai multe roluri de operare flexible cu un singur maestru care sunt atribuite.

la un controler de domeniu de fiecare dată.

AD foloseș te Apeluri de Procedură la Distanț ă (RPC) pentru replicare ș i poate utiliza SMTP pentru modificările aduse schemei sau configuraț iei.

Roluri FSMO

Toț i controlerii de domeniu nu sunt egali. Ș tim, este greu de auzit. Ai petrecut tot acest timp citind acest tutorial gândindu-te
toate DC-urile sunt create egale ș i acum trebuie să îț i spargem bula. Unele DC-uri au mai multe responsabilităț i decât altele. Este doar
parte a vieț ii!

Există cinci roluri numite maeș tri ai operaț iunilor, sau operaț iuni flexibile cu un singur maestru (FSMOs). Două dintre ele sunt la nivelul pădurii.
roluri ș i trei sunt roluri la scară de domeniu.

Rolurile la nivelul pădurii sunt:

Schema master: Actualizări de control pentru schema Active Directory.

Master de numire a domeniului: Controlează adăugarea ș i eliminarea domeniilor din pădure.

Cele trei roluri la nivel de domeniu sunt:

Master RID: Alocă grupuri de identificatori unici controlerelor de domeniu pentru utilizare atunci când se creează obiecte. (RID este relativ

identificator).

Masterul infrastructurii: Sincronizează modificările apartenenț ei la grupuri între domenii. Masterul infrastructurii nu poate rula pe un
server de catalog global, cu excepț ia cazului în care toate DC-urile sunt servere de catalog global.

Emulator PDC: Oferă compatibilitate retroactivă pentru clienț ii NT 4 pentru operaț iuni PDC - cum ar fi o schimbare a parolei. PDC
de asemenea, serveș te ca server de timp principal.

Catalog Global
Pe măsură ce o reț ea devine mai mare, aceasta poate conț ine mai multe domenii ș i mulț i controlori de domeniu. Fiecare domeniu conț ine doar înregistrări

din propriul său domeniu în baza de date AD pentru a menț ine baza de date mică ș i replicarea gestionabilă. Domeniul Active Directory
se bazează pe o bază de date de catalog global care conț ine o listă globală a tuturor obiectelor din pădure. Catalogul Global este ț inut pe
DC-uri configurate ca servere catalog global.

Catalogul global conț ine un subset de informaț ii - cum ar fi prenumele ș i numele de familie al unui utilizator - ș i numele distins
obiectul astfel încât clientul tău poate contacta controlerul de domeniu corespunzător dacă ai nevoie de mai multe informaț ii. Numele distins este
adresa completă a unui obiect din director. De exemplu, o imprimantă în OU Contabilitate din domeniul [Link] ar putea
au un nume deosebit de:

CN=AcctLaser1,OU=Contabilitate,DC=Learnthat,DC=com

Baza de date GC este doar un subset al întregii baze de date numit Setul de Atribute Parț iale (PAS), conț inând 151 din cele 1.070
proprietăț i disponibile în Windows Server 2003. Puteț i defini proprietăț i suplimentare pentru replicare la GC modificând
schema.

Gestionarea politicii de grup ș i Active Directory

Este dificil să discutăm despre Active Directory fără a menț iona Politica de Grup. Administratorii pot folosi Politicile de Grup în Microsoft Active
Direcț ie pentru a defini setările pentru utilizatori ș i computere în întreaga reț ea. Aceste setări sunt configurate ș i stocate în ceea ce sunt
apelatObiecte de Politică de Grup(GPO-uri), care sunt apoi asociate cu obiectele Active Directory, inclusiv domenii ș i site-uri. Aici
este mecanismul principal pentru aplicarea modificărilor pe computere ș i utilizatori în întreaga mediu Windows.
Prin gestionarea politicilor de grup, administratorii pot configura global setările desktop pe computerele utilizatorilor, restricț ionând/permise
acces la anumite fiș iere ș i foldere dintr-o reț ea ș i altele.
Este important să înț elegem cum sunt utilizate ș i aplicate GPO-urile. Obiectele de Politică de Grup sunt aplicate în următoarea ordine: Local
politicile de maș ină sunt aplicate mai întâi, urmate de politicile de site, apoi de politicile de domeniu, urmate de politicile aplicate la
unităț i organizaț ionale individuale. Un obiect utilizator sau computer poate aparț ine doar unui singur site ș i unui singur domeniu în acelaș i timp,
astfel că vor primi doar GPO-uri care sunt legate de acel site sau domeniu.
GPO-urile sunt împărț ite în două părț i distincte: Template-ul de Politică de Grup (GPT) ș i Containerul de Politică de Grup (GPC). Grup
Ș ablon de Politicăeste responsabil pentru stocarea setărilor specifice create în cadrul GPO ș i este esenț ial pentru succesul său. Stochează
aceste setări într-o structură mare de foldere ș i fiș iere. Pentru ca setările să se aplice cu succes tuturor utilizatorilor ș i computerelor
obiectele, GPT-ul trebuie să fie replicat la toate controlerii de domeniu din domeniu.
TheContainer de Politici de Grupeste porț iunea unui GPO stocată în Active Directory care se află pe fiecare controler de domeniu în
domeniu. GPC este responsabil pentru păstrarea referinț elor la Extensii pe partea clientului (CSE-uri), calea către GPT, căile către
pachete de instalare a software-ului ș i alte aspecte de referinț ă ale GPO. GPC nu conț ine o bogăț ie de informaț ii
relatate la GPO corespunzătoare, dar este esenț ial pentru funcț ionalitatea Grupului de Politici. Când politicile de instalare a software-ului
sunt configurate, GPC ajută la menț inerea legăturilor asociate în cadrul GPO. GPC păstrează de asemenea alte legături relaț ionale ș i căi
stocate în atributele obiectului. Cunoaș terea structurii GPC ș i modul de accesare a informaț iilor ascunse stocate în
atributele vor da roade atunci când ai nevoie să identifici o problemă legată de Politica de Grup.

Pentru Windows Server 2003, Microsoft a lansat o soluț ie de gestionare a politicilor de grup ca mijloc de unificare a gestionării
Politica de Grup sub forma de osnap-incunoscut sub numele deConsola de gestionare a politicilor de grup(GPMC). GPMC oferă un GPO-
interfaț ă de gestionare concentrată, făcând astfel administraț ia, gestionarea ș i localizarea GPO-urilor mult mai simple. Prin
În GPMC poț i crea noi GPO-uri, modifica ș i edita GPO-uri, copia/tăia/paste GPO-uri, salva GPO-uri ș i efectua Setul Rezultant de
Modelarea politicii.

Active Directory ș i Sistemul de Nume de Domeniu (DNS)

Active Directory este integrat cu Sistemul de Nume de Domeniu (DNS) ș i necesită ca acesta să fie prezent pentru a funcț iona. DNS este
sistem de numire folosit pentru Internet ș i pe multe Intranete. Poț i folosi DNS-ul care este integrat în Windows 2000 ș i versiuni mai noi, sau
folosiț i o infrastructură DNS de terț ă parte, cum ar fi BIND, dacă o aveț i în mediu. Se recomandă să folosiț i Windows.
Serviciul DNS aș a cum este integrat în Windows ș i oferă cea mai uș oară funcț ionalitate.

AD foloseș te DNS pentru a numi domenii, computere, servere ș i a localiza servicii.

Un server DNS corelează numele unui obiect la adresa sa IP. De exemplu, pe Internet, este folosit pentru a corela un nume de domeniu.
[Link]) la o adresă IP (cum ar fi [Link]). Într-o reț ea Active Directory, este folosit nu doar pentru a găsi
nume de domenii, dar ș i obiecte ș i adresele lor IP. De asemenea, foloseș te înregistrări de localizare a serviciilor (SRV) pentru a localiza servicii.

Ce este DNS? Se poate definisistemul de nume de domeniuaș a cum sunt localizate ș i traduse numele de domeniu Internet în
Adresele protocolului Internet. Un nume de domeniu este un „maner” semnificativ ș i uș or de reț inut pentru o adresă de Internet.

este esenț ial să înț elegemcum funcț ionează DNS.

DNS este extrem de important pentru toate aspectele funcț ionării corecte a Active Directory. Oricând oclientface o solicitare pentru un
serviciul de domeniu, trebuie să găsească un controler de domeniu pentru a satisface acea solicitare, ceea ce este locul unde intervine DNS.

Există două tipuri de interogări DNS: recursive ș i iterative. Atunci când un client DNS solicită informaț ii DNS, acesta foloseș te o interogare recursivă.
interogare pentru a face asta. (Ș i în scopurile acestei discuț ii, un client DNS este orice computer care solicită informaț ii DNS, chiar dacă
acel computer se dovedeș te a rula un sistem de operare pentru server.) Într-o interogare recursivă, clientul DNS îș i trimite interogarea la
primul server DNS care a fost configurat în configuraț ia sa TCP/IP. Apoi aș teaptă să primească un răspuns de la server.
răspuns. Dacă serverul returnează un răspuns pozitiv, clientul va merge apoi la adresa IP returnată de server.
Dacă este un răspuns negativ, clientul va returna un fel de eroare "Pagină/Resursă nu găsită" utilizatorului. Un lucru care este
important de remarcat aici este că configurarea mai multor servere DNS pe un client nu va face ca clientul să verifice cu serverele ulterioare
servere dacă primul returnează un răspuns negativ. Singura dată când un client va merge la serverul său DNS secundar este dacă primul
nu este disponibil. Dacă primul server DNS interogat returnează un răspuns negativ, clientul nu va încerca niciun server secundar ș i va
acceptaț i acel răspuns negativ ca final.

Configurarea serverului DNS

DNS este destul de simplu ș i direct. Atâta timp cât urmezi regulile de bază ale configuraț iei, DNS-ul îț i va oferi puț ine
probleme. Cu toate acestea, există anumite configura ț ii complexe care sunt importante de ș tiut ș i de re ț inut
cândconfigurarea serverelor DNS, care poate permite administratorilor să aibă o mai bună înț elegere a opț iunilor care pot face o diferenț ă în
Operaț iuni DNS, jurnalizare ș i depanare.
Una dintre primele lucruri de clarificat atunci când înveț i DNS în Active Directory este să ș tii dacă o proprietate aparț ine serverului DNS
sau o zonă. Ambele sunt expuse în instrumentul de gestionare DNS.
Iată câteva modalităț i de a le menț ine în ordine:
[Link]ă ț ile serverului sunt proprietă ț i generale care se aplică întregului mediu DNS, cum ar fi
Transmisie, Servere de nume, indicii rădăcină ș i jurnalizare.

2. Proprietăț ile zonei sunt proprietăț i specifice care variază în funcț ie de zonă, cum ar fi actualizările dinamice, tipul de zonă.
(AD, Standard Primar sau Secundar) ș i tipul de replicare.

Structura ș i designul DNS

Designul arhitecturii DNSde asemenea, este foarte important. Când se proiectează structura DNS, este important să se ț ină cont de anumite
principiile ș i practicile care vor afecta performanț a generală a rezolvării numelui în reț ea. Structurile DNS care sunt
Împachetate împreună sau nu foarte bine gândite, vor func ț iona, dar au zone de e ș ec care vor afecta Active Directory
performanț ă. De aceea, respectarea celor mai bune practici în structura DNS este extrem de importantă pentru crearea unui sistem eficient ș i
Active Directory productiv
O cheie în proiectarea DNS implică utilizarea deZone integrate Active Directory(ADI). O zonă ADI este o copie scrisibilă a unei
zona de căutare înainte care este găzduită pe un controler de domeniu. Aceasta este o cerinț ă deoarece înregistrările DNS sunt toate păstrate în Active
Director, astfel încât serverul DNS are nevoie de acces la AD. Deoarece fiecare DC găzduieș te o copie modificabilă a zonei DNS, clienț ii
(posturi de lucru, servere ș i alte DC-uri) pot înregistra înregistrările lor DNS pe un controler de domeniu care găzduieș te o zonă principală ADI --
de obicei DC-ul care le-a autentificat - mai degrabă decât să caute în reț ea pentru a găsi un singur server DNS (principal) care va adăuga
înregistrările de găzduire ș i resurse ale clientului.

Deci, cum este concepută o structură DNS folosind zone integrate Active Directory? Zonele ADI pot fi găzduite doar pe DC-uri.
Cu toate acestea, mul ț i administratori doresc să plaseze servere de nume de domeniu în loca ț ii remote pentru a oferi o rezolvare mai bună a numelui.
performanț a ș i pentru a diminua traficul de reț ea. Astfel, utilizatorii nu trebuie să traverseze WAN-ul pentru a găsi un server DNS.
Cu toate acestea, un administrator s-ar putea să nu dorească să plaseze un DC în acea locaț ie. Windows 2000 Server ș i Windows Server 2003 permit
adminii să pună o zonă secundară standard (doar citire) pe un server membru ș i să folosească unul dintre serverele primare ADI ca
maestru.
Regula este că o zonă primară ADI poate exista doar pe un DC, dar administratorii pot avea o secundară standard a acelei zone pe un
server membru. Astfel, clienț ii se pot conecta la serverul lor DNS local, fie că găzduieș te ADI principal sau secundar.
Când un client (DC, server membru sau staț ie de lucru) încearcă să se înregistreze, totuș i, acesta se poate înregistra doar pe un server DNS care găzduieș te
Zona primară ADI. Dacă clientul se îndreaptă spre un server care găzduieș te un secundar, clientul va primi pur ș i simplu o recomandare către unul dintre
primarele să fie înregistrate.

Protejând DNS
Securitatea DNS este o prioritate majoră. Multe dintre func ț iile ș i caracteristicile Active Directory folosesc DNS pentru a localiza domeniul.
controale, sisteme, servicii, clienț i ș i alte obiecte. Ar trebui să fie evident căprotejarea DNSeste aproape la fel de important ca
protejarea Active Directory în sine. Practic, dacă DNS-ul eș uează, Active Directory eș uează ș i el. Acest lucru, la rândul său, înseamnă că dacă DNS-ul eș uează, un
întreaga reț ea poate fi dezactivată.
Oferirea protecț iei pentru DNS ca mijloc de a oferi protecț ie suplimentară pentru DC-urile AD este o parte esenț ială a stabilirii unei
un mediu de reț ea cu adevărat sigur. Protejarea serverelor DNS va necesita o abordare pe mai multe fronturi. În primul rând,
stabilirea aceloraș i proceduri de proiectare, implementare ș i desfăș urare securizate pentru serverele tale DNS, aș a cum am recomandat pentru
DC-urile tale AD.

În continuare, consideraț i implementarea comunicărilor securizate cu serverele DNS, monitorizaț i tot traficul de reț ea ș i reevaluaț i deschiderea
porturile de pe firewall-ul tău. Prin criptarea tuturor comunicaț iilor între serverele DNS ș i toț i clienț ii DNS (care includ nu doar
clienț i utilizatori finali, dar ș i DC-uri Active Directory ș i servere membre), va minimiza sau elimina posibilitatea de trafic
interceptare ș i manipulare. Una dintre cele mai bune modalităț i de a implementa acest lucru este prinIPSec, care este un cadru pentru un set de
protocole pentru securitate la nivelul reț elei sau al procesării pachetelor în comunicaț ia de reț ea.
Notă: Deș i implementarea IPSec pe toate sistemele va provoca probabil o scădere măsurabilă a performanț ei
comunicarea reț elei din cauza suprasarcinii de criptare ș i decriptare a comunicaț iilor, mulț i experț i consideră că a crescut
securitatea ar trebui să compenseze mai mult decât reducerea uș oară a capacităț ii de procesare.

Este de asemenea important sămonitorizează tot traficul de reț ea ș i reevaluează porturile deschise pe firewall-ul tău. Prin monitorizarea reț elei
trafic, administratorii ar trebui să fie capabili să determine când modele de trafic sau conț inut ilegitime sau anormale încep să intre în acestea
reț ea.
Chiar ș i cu toate precauț iile recomandate implementate, totuș i există încă posibilitatea ca o persoană rău intenț ionată să obț ină acces la un
Server DNS. Dacă se întâmplă acest lucru, administratorii trebuie să se bazeze peprecauț ii de securitate DNS interne, care includ:

Actualizări dinamice securizate

Cotele de înregistrare a resurselor DNS

Delegare administrarea DNS
Utiliza ț i rutare securizată

Menț ineț i un spa ț iu de nume DNS împăr ț it

Dezactivează recursivitatea
Depanarea DNS
Diagnosticarea DNS este un proces absolut esenț ial în Active Directory. Este important să menț inem DNS-ul sănătos ș i să ș tim cum
să-l repari când se strică.
Unele dintre problemele comune de DNS ș i instrumentele de utilizat pentruDepanare DNS.

Evitarea breș elor de securitate în Active Directory

Importanț a protejării Active Directory-ului tău a fost deja menț ionată în legătură cu Securitatea DNSCu toate acestea, că
este doar vârful aisbergului când vine vorba de menț inerea unui mediu sigur.
În ceea ce priveș teCele mai bune practici de securitate pentru Active Directorymergi, securitatea stratificată este cea mai bună metodă de utilizat atunci când planifici ș i proiectezi o
soluț ie de securitate. Securitate în straturi sau apărare în adâncime este conceptul simplu de a plasa activele tale valoroase în centrul tău
mediu ș i construirea sau desfăș urarea de mai multe cercuri sau inele concentrice de protecț ie în jurul acelor active. Astfel, încălcările
pentru confidenț ialitate, integritate sau disponibilitate trebuie să depăș ească numeroase restricț ii de securitate, precauț ii ș i protecț ii înainte de
fiind capabil să afecteze activele tale.

În timp ce Microsoft a crescut securitatea implicită în Active Directory (în special dacă aveț i un Windows Server 2003
Instalarea Active Directory), încă trebuie să luaț i în considerare setările suplimentare de securitate după ce este instalat.

Asigurarea controlerelor de domeniu

Unul dintre primele paș i pe care ar trebui să îi faci implică dezvoltarea unui solidpolitica de securitate a controller-ului de domeniu Protejând
domeniul tău
controlerele sunt esenț iale pentru protejarea investiț iei dvs. în Active Directory. Fără controlerele de domeniu, nu veț i avea ...
Infrastructura reț elei Active Directory. Cu controlere de domeniu expuse ș i neprotejate, eș ti, de asemenea, expus riscului ca atacatorii să
enumerarea folderelor partajate ș i a numelui de utilizator, oferind informaț ii valoroase care pot fi folosite pentru a ataca în continuare reț eaua.

Prin urmare, este esenț ial ca controlerele de domeniu să fie în funcț iune ș i protejate pentru ca mediul Active Directory să
rămâne func ț ional ș i stabil. Pentruprotejarea controlerelor de domeniuar trebui să lua ț i în considerare următoarele domenii ale securită ț ii
protection:physical access (keeping DCs in a secure location that is only accessible by the IT staff) and network
acces (protejând DC-urile de cei care ar putea ataca reț eaua ta).
Ca administrator, trebuie să te preocupi de asigurarea că utilizatorii interni au acces corespunzător ș i că potenț ialii intruș i
sunt frustraț i în încercările lor de a compromite un DC. O primejdie este ca o persoană să fie fizic în cameră ș i să atingă un DC
chiar ș i fără drepturi acordate lor. Astfel, dacă o persoană are acces fizic, aceasta deț ine computerul tău, deoarece accesul fizic
accesul le oferă control. Păstrarea DC-urilor într-o locaț ie sigură este o modalitate simplă de a asigura securitatea Active Directory, dar este
adesea trecut cu vederea.

În ceea ce priveș te accesul la reț ea, este important să nu oferiț i privilegii de administrator de domeniu cuiva care nu este suficient de calificat.
să se ocupe de muncă sau să încredinț eze cuiva de care nu eș ti sigur că poț i avea încredere. Oricine are capacitatea de a instala/modifica fiș ierele de sistem, inclusiv
servicii/Ș oferi (cum ar fi operatori de server, operatori de backup sau operatori de imprimare) deț in computerul tău. Există multe modalităț i pentru
acest lucru să se întâmple. În mod natural, un cont sigur ar putea fi compromis, oferind intrusului drepturile de a face asta, dar un titular valid
aceste drepturi ar putea cauza daune neintenț ionate prin instalarea unei aplicaț ii fără a o testa mai întâi.
Cât de bine te descurciUrgenț ele ș i actualizările patch-urilor Microsoft este, de asemenea, esenț ial pentru securitatea DC-urilor dvs. Trebuie să întotdeauna
deplasaț i aceleaș i corecț ii pe toate controlerele de domeniu. DC-urile ar trebui să fie menț inute cât mai aproape de imagini reflectate una faț ă de cealaltă, la
cel puț in în ceea ce priveș te configuraț ia OS. Acest lucru va ajuta la eliminarea incompatibilităț ilor, a datelor pierdute sau deteriorate ș i a erorilor de replicare.

Cu toate acestea, este important să nu aplicaț i actualizări doar pentru că Microsoft oferă un patch. Fiecare patch trebuie testat în mediul dumneavoastră.
pentru relevanț ă ș i fiabilitate. Dacă nu ai nevoie de ea, nu o instala. Patch-urile pot deteriora mediu tău dacă instalarea eș uează.
performă perfect. Nu vrei să îț i pui DC-urile în pericol dacă poț i să eviț i asta.

Securitatea Kerberos cu Microsoft

Odată cu apariț ia Windows 2000, Microsoft a adoptatKerberosca un protocol de autentificare. Nu numai că a fost mult mai
sigur ș i eficient decât NTLM (care a fost folosit anterior), dar de asemenea colaborează bine cu alte sisteme de operare, cum ar fi Unix.
Înainte de a învăț a cum funcț ionează Kerberos în lumea Windows, este cel mai bine să înț elegem mai întâi normalAutentificarea Kerberos ș i
autorizaț ie.
Autentificarea este procesul de prezentare a acreditivelor (nume utilizator/parolă) unui serviciu ș i de validare a ta de către acel serviciu.
Funcț ionează astfel. Atunci când un utilizator introduce numele de utilizator/parola sa într-un mediu Kerberos, acea informaț ie este trimisă la
server care rulează Serviciul de Autentificare. Serviciul de Autentificare transmite acele informaț ii unei baze de date numită Cheia
Centru de Distribuț ie (KDC). Dacă numele de utilizator/parola sunt corecte, Serviciul de Autentificare trimite un Bilet de Acordare a Biletului
(TGT) către client, permiț ând clientului să finalizeze procesul de autentificare. TGT-ul conț ine un marcaj temporal, cheia publică ș i un
certificat.
Autorizareeste procesul de acordare a accesului la resurse pe un server care se află în re ț ea. Continuând de la
discuț ie despre autentificare, odată ce clientul obț ine TGT-ul, clientul poate solicita acces la resurse. TGT-ul este prezentat
la Serviciul de Acordare a Biletelor ș i solicită un bilet de sesiune pentru a accesa o resursă pe, să zicem, Serverul 1. Dacă Serverul 1 este în domeniu,
Serviciul de acordare a biletelor observă că există un TGT valid, astfel că acreditivele sunt verificate ș i se oferă un bilet de sesiune pentru Server
1. Clientul prezintă apoi biletul de sesiune serverului 1 pentru acces la o resursă, cum ar fi o imprimantă, un share de fiș iere sau un document.
Serverul 1 va verifica apoi drepturile de acces asupra acelei resurse pentru a vedea ce poate face utilizatorul (citi, scrie, etc.).

Într-un domeniu Windows, toate serviciile legate de Kerberos descrise anterior sunt gestionate de fiecare controler de domeniu. Când un utilizator
oferă acreditive pentru autentificare într-un domeniu Windows, acelaș i proces de autentificare Kerberos descris mai sus este
folosit -- cu o singură excepț ie. Pentru a găsi un controler de domeniu care este de asemenea KDC, un client trebuie să folosească Localizatorul DC
proces, care necesită un server DNS pentru a localiza un DC adecvat ș i a trimite aceste informaț ii înapoi clientului. Clientul atunci
transmite acreditivele la controlerul de domeniu, care acordă TGT-ul ș i apoi un bilet de sesiune dacă serverul la care se accesează este în
domeniul DC-ului. Drepturile de acces sunt verificate de server ș i acordate clientului.

Setările de securitate ale politicii de grup

Unul dintre cele mai importante paș i către securitatea Active Directory implicăSetările de securitate ale politicii de grup. Cu aproape 1.800
setări de politică într-un singur Obiect de Politică de Grup(GPO), nu este de mirare că oferă atât de multă putere, control, securitate ș i
managementul peste o întreprindere Active Directory.
Există două GPO-uri implicite în fiecare domeniu Active Directory. Aceste GPO-uri implicite există din motive foarte distincte ș i
trebuie să fie investigate pentru a se asigura că sunt configurate corespunzător pentru a oferi cea mai bună securitate pentru reț eaua companiei tale. Primul
GPO-ul implicit este Politica Implicită a Domeniului. Acest GPO este responsabil pentru stabilirea ș i menț inerea politicilor de cont pentru
conturile utilizatorilor de domeniu, care sunt esenț iale pentru a ajutaprotejaț i parolele conturilor de utilizator ale domeniului.
Al doilea GPO implicit este Politica Implicită a Controlerului de Domeniu. Acest GPO este responsabil pentru stabilirea bazei de referinț ă.
securitate pentru toate controlerele de domeniu din domeniu. Setările principale de securitate care sunt stabilite în GPO sunt utilizatorul
drepturi. Drepturile comune ale utilizatorilor includ:

Permi ț ând unui utilizator să se logheze folosind tastatura conectată la computer (local)
Schimbarea timpului sistemului
Realizarea copiilor de siguran ț ă ale fi ș ierelor ș i folderelor

Accesarea computerului ș i a resurselor sale prin intermediul unei re ț ele

Cu toate acestea, fiecare reț ea care rulează Active Directory ar trebui să aibă mai mult decât cele două GPO-uri implicite. Motivul este că Grupul
Politica oferă o metodă automatizată ș i centralizată pentru configurarea ș i desfăș urarea setărilor de securitate pentru toate calculatoarele ș i utilizatorii.
în domeniu. Unele setări comune legate de securitate ș i domenii de configurare includ capacitatea de a restricț iona care
aplicaț iile pot fi rulate pe fiecare computer, folosiț i Securitatea IP pentru a cripta datele între computere, restricț ionaț i conexiunile anonime
către computere ș i setările politicii de audit pe fiecare computer.

Aminteș te-ț i că există mai multeatacuri de securitate a reț eleicare poate fi evitat cu uș urinț ă prin Politica de Grup, inclusiv paș i simpli
pentruConfigurarea Kerberos, aș a că asiguraț i-vă că profitaț i.

Modificări în Active Directory pentru Windows Server 2008

Încă o dată, mulț imodificări în Active Directoryau fost realizate cu Windows Server 2008. Microsoft a încorporat două foarte
caracteristici semnificative ale Windows Server 2008 care vor avea probabil legătură cu majoritatea implementărilor Active Directory: versiunea doar pentru citire
controler de domeniu (RODC) ș i roluri de server.
Thecontroler de domeniu doar pentru citireeste poate cea mai importantă caracteristică pentru Active Directory în Windows Server 2008. RODC
găzduieș te o copie doar pentru citire a bazei de date Active Directory. Adică, nu poț i face nicio modificare în baza de date Active Directory
de la un controler de domeniu doar pentru citire. Te poț i conecta la un RODC pentru a citi orice informaț ie doreș ti (cu câteva excepț ii,
la care vom ajunge în câteva momente), dar nu veț i putea efectua nicio operaț iune de scriere fără a vă conecta sau a fi
se referă la un controler de domeniu scriabil.
De asemenea, cu RODC, administratorul poate determina ce conturi vor fi replicate la controlerul de domeniu ș i replicarea
este unidirecț ional. RODC nu efectuează nicio replicare externă. Aceasta este o schimbare fundamentală faț ă de tipica multi-
modelul de replicare master cu care mulț i s-au familiarizat în Active Directory. În Windows 2000 Server ș i Windows
Server 2003, un administrator poate să se conecteze la orice controler de domeniu pentru a face o modificare, iar acea modificare va fi replicată în afară.
restul Active Directory prin replicare externă de la DC de la care a avut loc modificarea.
Acest lucru nu este valabil în cazul RODC. Controlerul de domeniu doar în citire va primi replicare în intrare de la alte controlere de domeniu scriabile.
DC-uri Windows Server 2008, dar nu va replica nicio informaț ie către alte DC-uri. Acest lucru rezolvă multe probleme de securitate.
probleme la site-urile remote, deoarece va minimiza conturile expuse la site (presupunând că nu sunt conturi de administrator) ș i orice altceva
compromis la faț a locului nu va ieș i din site. Combinate cu noulTehnologia BitLockerRODC va permite
implementarea DC-urilor la site-uri mai mici unde nu era fezabil înainte.
Nucleu de server a fost de asemenea dezvoltat pentru Windows Server 2008 ca un răspuns la cererile clienț ilor de a oferi un server uș or
sistem de operare care ar permite funcț ii specifice ale serverului să ruleze fără toată povara interfeț ei grafice. A fost denumit
de Microsoft ca o instalare de bază a Windows Server 2008.
Cu Server Core, după autentificare, un utilizator va fi prezentat cu un desktop fără meniu Start, bara de activităț i sau pictograme ș i două comenzi.
Windows. Instalarea rolurilor precum Protocolul de Configurare Dinamic a Gazdelor (DHCP), DNS, servicii de fiș iere ș i server de imprimare va
poate fi făcut complet din linia de comandă. Totuș i, acest mediu va permite în continuare utilizatorilor să deschidă aplicaț ii precum
Event Viewer, notepad ș i altele. Pe lângă îmbunătăț irea serverului pentru scopuri administrative ș i reducerea
resurse hardware necesare, Server Core permite de asemenea o securitate mai bună în locaț ii remote, permiț ând o mică expunere.
Alte modificări includ Active Directory Restartabil, care permite AD să fie repornit fără a reporni serverul.
poate realiza acest lucru prin linia de comandă ș i prin MMC Snap-ins. Este conceput pentru a economisi timpul administratorilor în operaț iuni offline (ca
o defragmentare offline a Directorului Activ) fără a pune serverul offline ș i a închide alte servicii ș i aplicaț ii.

Bazele planificării Active Directory

Când efectuezi o migrare Active Directory, ai în esenț ă două opț iuni: actualizarea domeniului sau domeniul
[Link] domeniului este puț in mai mult decât actualizarea fiecărui controler de domeniu Windows existent la o versiune mai actuală
Controler de domeniu Windows. Procesul de upgrade începe prin actualizarea PDC-urilor din fiecare domeniu, urmat de
Restructurarea [Link] implică crearea unei reț ele Active Directory de la zero. Într-o restructurare, veț i muta
sisteme ș i redirecț ionarea conexiunilor pentru a se conforma cu o nouă infrastructură ș i design de layout. De multe ori, restructurarea va duce la
mai puț ine, dar mai mari domenii.

Aș adar, întrebarea devine: "Ar trebui să îmbunătăț eș ti sau să restructurezi?"

Decizia privind calea de urmat sau procesul de efectuat mai întâi depinde în totalitate de situaț ia ta specifică. Dar sunt câteva
ghiduri care te pot ajuta să faci alegerea.
În primul rând, dacă structura dumneavoastră de domeniu actuală susț ine sarcinile de lucru ș i nu pare să implice o cantitate neobiș nuită de
administrare excesivă, atunci actualizarea poate fi preferabilă. Cu toate acestea, dacă structura domeniului actual nu este adecvată ș i este
motivarea principală pentru migraț ie, restructurarea este cu siguranț ă calea de urmat. În al doilea rând, dacă trebuie să susț ineț i producț ia
Mediul pe parcursul procesului de migrare, actualizarea va păstra funcț ionalitatea generală a reț elei ș i, prin urmare, este de preferat.
Dar dacă î ț i po ț i permite să pierzi productivitate în timpul migra ț iei, restructurarea este mai bună. Cu toate acestea, restructurarea poate fi
efectuate conform unui program escaladat, astfel încât să nu se observe o pierdere semnificativă a productivităț ii.

Amintiț i-vă că, deș i actualizarea va cauza cel mai mic timp de nefuncț ionare în ceea ce priveș te readucerea domeniului în ordine de funcț ionare, aceasta
de multe ori este o migraț ie insuficientă. Multe dintre beneficiile domeniilor Active Directory bazate pe Windows 2000 ș i Windows 2003
nu poate fi realizat pe deplin fără a reconfigura designul reț elei tale. Restructurarea va necesita o muncă semnificativă pentru
implementează, dar face mai uș or pentru organizaț ia ta să valorifice beneficiile Active Directory.

Dezvoltarea unei strategii de migrare Active Directory

Atunci când preiei un proiect de migrare Active Directory, la fel ca în cazul tuturor proiectelor mari, este cel mai bine să ai o strategie în vigoare. Este esenț ial
a crea unLista de verificare pentru migrarea Active Directory, cu paș i precum colectarea diagramelor ș i configurarea DNS-ului actual
ș i structura reț elei (lăț ime de bandă, locaț ii remote, stabilitate etc.), determinând drepturile, obiectele ș i politicile care vor fi necesare
a fi migrat ș i a crea proceduri de rezervă în caz de eș ec.
O altă parte dindezvoltarea strategiei tale de migrareeste conș tient de lucrurile cheie pe care ar trebui ș i nu ar trebui să le faci când
efectuând o migrare Active Directory.
Pentru început, este important să te asiguri că personalul de suport este la curent înainte de a începe migrarea oricărei
sistem de producț ie. În funcț ie de dimensiunea ș i structura organizaț iei dumneavoastră, ar trebui să aveț i un personal de help desk care să ofere suport.
apeluri. Pentru un proiect complex precum Active Directory, este o idee bună să ai disponibili câț iva ingineri de reț ea. Fii
asigură-te că îi instruieș ti pe toț i membrii personalului de suport implicaț i în proces. Altfel, vei avea personal IT care va răspunde la întrebări care
nu ș tiu cum să răspundă, iar frustrarea va fi prezentă din toate părț ile.
De asemenea, ar trebui să stabiliț i un mediu de testare care să imite cât mai aproape de mediu dvs. de producț ie în ceea ce priveș te hardware-ul.
specificaț ii ș i viteză de reț ea. Nu lăsa nimic la întâmplare în faza de testare. Vorbind despre testare, asigură-te că testezi numele
rezolvare ș i replicare înainte de a desfăș ura Active Directory în producț ie. Spre deosebire de replicarea sub NT4, Active Directory
replicarea este posibil cel mai important element necesar pentru ca AD să funcț ioneze corect. Al doilea, după replicarea fiș ierelor pentru
o implementare solidă a Active Directory esterezolvarea numeluiIndiferent dacă implementaț i WINS sau DNS, asiguraț i-vă că toate
sisteme care trebuie să poată comunica eficient între ele.

Designul Active Directory în mod simplu

Active Directory este foarte flexibil. Atât de flexibil încât po ț i proiecta o pădure Active Directory care este complexă dincolo de
imaginatie. Atât Windows 2000 Server, cât ș i Windows Server 2003 acceptă containerele Active Directory de forestă, domeniu,
site ș i unitate organizaț ională (OU). Cu singura restricț ie reală de un forest pe spaț iul de nume, poț i desfăș ura atât de multe
domenii, site-uri ș i UOs după cum consideri necesar.
Cu toate acestea, nu fi atât de grăbit să pleci ș i să proiectezi o reț ea Active Directory care include un domeniu pentru fiecare departament în
întreprinderea ta. Thecheia pentru designul Active Directoryeste simplitatea. Ca regulă generală, doriț i să menț ineț i numărul de domenii
la un minim ori de câte ori este posibil. Dacă ai cu adevărat nevoie de diviziuni la nivel de departament în reț eaua ta care să reflecte organizaț ia
dacă afacerea ta, atunci foloseș te OU-uri în schimb. OU-urile sunt mult mai flexibile ș i mai uș or de gestionat în general decât domeniile.

Dacă migraț i de la o reț ea Windows NT 4.0 la un server Windows 2000 sau la un server Windows 2003 Active Directory
reț ea, compară numărul de domenii din sistemul tău legacy existent ș i compară-l cu numărul de domenii în
noua dvs. design bazat pe AD. Dacă noua dvs. reț ea Active Directory are mai multe domenii decât reț eaua dvs. veche, este posibil să aveț i nevoie
să-ț i reconsideri designul. Da, este posibil să foloseș ti câte domenii doreș ti, dar probabil că vei regreta această decizie mai târziu.
linie. Dacă ai nevoie de multe grupări ș i diviziuni, cel mai bine este să te bazezi pe OUs.

Designul domeniului Active Directory

Atunci când proiecta ț i re ț eaua dvs. Active Directory, este important să utiliza ț i cele patru diviziuni (forests, domains,
unităț i organizaț ionale ș i locaț ii) la potenț ialul lor maxim. Acest lucru este valabil mai ales pentruDesignul domeniului Active Directory.
Diviziunile de domeniu sunt cel mai adesea folosite ca recipiente logice. Cu toate acestea, Microsoft recomandă să folosiț i ș i domenii.
ca recipiente fizice. Cu alte cuvinte, creaț i domenii ale căror membri sunt toț i geografic aproape, mai degrabă decât îndepărtaț i. Acest lucru este
un aspect important al designului deoarece nivelul de trafic într-un domeniu este considerabil mai mare decât cel dintre un domeniu ș i
altul. În general, un domeniu cu dimensiuni fizice limitate este mai pu ț in probabil să includă costuri mariWANlinkuri sau plăti-pe-bit
conexiuni. Atunci când linkurile lente trebuie incluse într-un design de re ț ea, este adesea benefic să se creeze mai multe domenii
conectat prin conexiuni mai lente.
Aminteș te-ț i că nu este necesar să creezi domenii separate pentru a împărț i privilegii administrative. În cadrul Active Directory, este
posibil să delegate privilegii administrative pe baza unităț ilor organizaț ionale.

Proiectarea grupurilor ș i unităț ilor organizaț ionale

Cu pregătirea adecvată ș i cunoaș terea în avans a utilizării lor, un funcț ionaldesignul unităț ii organizaț ionale (OU) ș i al grupuluipot
face minuni pentru a simplifica mediul tău Active Directory. De asemenea, poate ajuta foarte mult în obț inerea controlului ș i
reducerea cheltuielilor.

Adesea, UOs sunt folosite fără discriminare ș i fără motiv, iar structura grupului este ineficientă ș i confuză. Fără o formă de
organizarea logică a utilizatorilor în cadrul mediului dvs. de reț ea, haosul domneș te ș i administrarea se opreș te. Unele cele mai bune
practicile atunci când se proiectează UO includ:

Men ț ineț i structura OU cât mai simplă posibil

Nu îngropa OUs mai mult de 10 straturi adânc.
Menț ine numărul unită ț ilor organiza ț ionale la un minim

Aplică Politica de Grup pentru grupuri prinFiltrarea politicii de grup

Nu utiliza ț i grupuri locale pentru permisiuni într-un mediu de domeniu
Utiliza ț i grupuri locale de domeniu pentru a controla accesul la resurse ș i utiliza ț i grupuri globale pentru a organiza grupuri similare de utilizatori.

Ai de asemenea opț iunea deascunzând unităț ile organizaț iei taleScopul principal al OUs ascunse este de a preveni un administrator dintr-un OU
de la a putea vizualiza, accesa sau modifica un alt OU. OUs ascunse sunt adesea folosite în medii care oferă re ț ea
servicii de aplicaț ie către departamente interne sau clienț i externi. Permite o separare solidă a atribuț iilor fără a necesita
domenii sau păduri separate.

Reguli de proiectare pentru site-urile Active Directory

Site-urile sunt un element de design extrem de util pentru domeniile Active Directory. Site-urile sunt limitate la orice obiect computer dintr-un
pădure. Astfel, ele pot traversa domenii ș i unităț i organizaț ionale (OU-uri) fără preferinț e. Apartenenț a unui obiect la un domeniu sau
OU nu exclude calitatea de membru simultan într-un loc. Site-urile sunt utilizate pentru a impune diviziuni fizice ale reț elei în scopul
a fluxului de trafic.

Prin utilizarea site-urilor, puteț i controla ș i reduce cantitatea de trafic care circulă prin link-urile WAN mai lente. Acest lucru poate duce la
flux de trafic mai eficient pentru sarcini de productivitate. Poate servi, de asemenea, pentru a menț ine costurile linkului WAN la un nivel scăzut pe baza plăț ii per bit
servicii.
În general, cândproiectarea site-urilor, ț ine cont de următoarele:
Site-urile ar trebui să reflecte în general topologia fizică sau geografică a re ț elei.
Fiecare site ar trebui să con ț ină cel pu ț in un DC local.
Site-urile nu ar trebui să con ț ină linkuri lente de niciun fel.

Clien ț ii de acces la distan ț ă nu au nevoie de un site dedicat.

Site-urile ar trebui folosite ori de câte ori este necesară sau dorită controlul asupra traficului de replicare.

Site-urile pot fi adăugate, eliminate, modificate ș i mutate cu u ș urinț ă fără a afecta configura ț ia oricărui alt container AD.

Ierarhii Active Directory

Acum că înț elegi blocurile de construcț ie ale Active Directory, poț i începe să înț elegi cum să construieș ti o ierarhie în
Active Directory. Una dintre fundaț iile designului pentru AD a fost flexibilitatea de a permite companiilor să construiască o structură care
se integrează în organizaț ia lor. Această flexibilitate permite organizaț iilor de toate dimensiunile să utilizeze Active Directory pentru a-ș i satisface nevoile.

Domenii ș i OUs

Cel mai de bază design al unui Active Directory este o singură pădure, un singur domeniu, fără design de Unitate Organizatorică.
Instalare de bază AD

Pentru o organizaț ie mică, acest lucru ar putea fi suficient, dar aproape fiecare organizaț ie poate beneficia de pe urma unei structuri.

Crearea mai multor domenii nu este întotdeauna cea mai bună soluț ie de design, aș a că Microsoft a creat unităț i organizaț ionale în Active Directory.
care pot fi nestelate pentru a oferi control ierarhic al mediului dvs. AD. Este o idee grozavă să vă gândiț i ș i să schiț aț i
Designul OU înainte de a-l angaja în Active Directory.

În general, companiile îș i proiectează arborii OU pe baza separării geografice (de exemplu, Americi, EMEA, PacificRim) sau
bazat pe designul organizaț ional (de exemplu, contabilitate, marketing, tehnologie, vânzări). Nu există o modalitate greș ită de a-ț i proiecta AD
mediu, totuș i, coerenț a ar trebui să fie cheia. Nu ar trebui să amesteci cele două metode de design ș i să ai un nivel superior pentru Americi
OU ș i un OU de vânzări de nivel superior. Facând asta, administrarea devine dificilă, deoarece nu vei ș ti unde se află un anumit vânzător.
contul este.

De asemenea, aminteș te-ț i că UO-urile permit administratorilor de întreprindere să delege responsabilitatea administrativă echipelor locale. Construind un

Un design eficient al OU vă va permite să delegaț i corect autoritatea.

Cealaltă raț iune pentru care se folosesc UO-urile este aplicarea politicilor. Politicile sunt reguli pentru securitate, acces ș i funcț ionalitate care pot fi aplicate la

mai multe containere diferite în Active Directory. Frecvent, politicile sunt aplicate de OU - aș a că, deș i ai putea separa
din punct de vedere geografic (ș i, prin urmare, doriț i să vă stabiliț i structura bazându-vă exclusiv pe geografie), ar putea avea mai mult sens să configuraț i

publicitatea dvs. prin diviziile organizaț ionale. De ce? Pentru că, dacă toț i angajaț ii dvs. de marketing au nevoie de acelaș i software ș i setări,

veț i stabili politici bazate pe departament în loc de locaț ia fizică a angajaț ilor.
Arbori de domenii

Odată ce o organizaț ie devine mare ș i nu poț i avea întreaga bază de date AD replicată peste tot, ar putea avea sens
a se muta într-un arbore de domenii. Un arbore de domenii permite unei organizaț ii să devină mai descentralizată, deoarece este mai independentă decât
utilizând un arbore OU.

Politicile la nivel de domeniu pot fi schimbate pe fiecare domeniu dintr-un arbore de domenii, ceea ce nu este posibil doar cu o structură OU. Politicile

cum ar fi vârsta minimă ș i maximă a parolei, lungimea minimă a parolei ș i blocarea contului sunt politici la nivel de domeniu ș i
nu poate fi schimbat pe o bază per-OU. Prin crearea mai multor domenii, administratorii pot stabili aceste politici pentru fiecare domeniu.

Arbore de domeniu

În ilustraț ia de mai sus, [Link] are un arbore de domenii în domeniul Active Directory.

Pădurea arborilor de domeniu

În medii mai complexe, o companie poate folosi mai multe arbori de domeniu într-o singură pădure. Acest lucru ar putea fi un sistem de operare mare.

companie cu mai multe filiale – fiecare necesitând propriul domeniu, de exemplu, [Link] este compania mamă
ș i subsidiarele ar putea include [Link], [Link], [Link]. Această structură are sens dacă ai
personal administrativ diferit pentru fiecare domeniu, împreună cu politici diferite ș i cerinț e de securitate diferite.

Puteț i încă să configuraț i încrederi între domenii pentru a permite utilizatorilor să se autentifice pentru resurse în oricare dintre domenii.

Multiple Păduri

Ultima posibilitate este utilizarea mai multor păduri. Aceasta este cea mai puț in frecventă alegere de design, dar poate fi utilizată dacă doriț i o absolută
separare dintr-un motiv sau altul. Această structură este cel mai frecvent întâlnită atunci când companiile fuzionează sau în cazul achiziț iilor.
În Windows 2003, poț i configura încrederi de pădure între păduri pentru a permite un anumit acces.

Instalarea Active Directory

Unele organizaț ii mai mari durează luni (ș i, în unele cazuri, peste un an) pentru a planifica un design adecvat al Active Directory ș i a obț ine feedback.

dintr-o organizaț ie globală de lideri în tehnologie. Este extrem de important să acorzi multă atenț ie designului tău AD pentru a
asiguraț i-vă că îndeplineș te nevoile organizaț iei dumneavoastră.
Alegerea layout-ului AD

Aș a cum am menț ionat anterior, sunt multe moduri în care poț i structura Active Directory-ul tău. Dintr-o perspectivă de nivel superior,
majoritatea companiilor încep fie cu o separare geografică, fie cu o separare a structurii organizaț ionale, de exemplu, Americi,
EMEA, PacificRIM pentru geografie sau Contabilitate, Marketing, Tehnologie, Vânzări pentru structura organizatorică. Nu este
indiferent de ceea ce alegi: oricare va oferi un punct de plecare bun pentru structura domeniului tău, dar trebuie să te asiguri că alegi
o direcț ie ș i fii consecvent cu alegerile tale.

Multe organizaț ii încep cu geografia la nivelul superior, apoi se împart în unităț i de afaceri sau departamente sub acesta.
nivel superior. Este important să se scrie conven ț ii ș i standarde de denumire astfel încât o echipă din Europa să nu numească un OU
„VânzăriMarketing” în timp ce o echipă din America de Nord numeș te un OU „Vânzări.” Coerenț a permite un proces eficient ș i gestionabil.
Structura Active Directory.

Există multe combinaț ii diferite pe care le-ai putea alege atunci când îț i proiectezi structura AD.

Cerinț e de instalare

În această secț iune, vom analiza cerinț ele de instalare a Active Directory. Instalarea AD nu este un proces complex, dar ...
designul ș i configurarea pot fi.

Iată cerinț ele pentru instalarea Active Directory pe Windows Server 2003:

O partiț ie NTFS cu suficient spaț iu liber

Numele de utilizator ș i parola unui administrator

NIC cu Conexiune de Reț ea

TCP/IP configurat corect (adresă IP, mască de subreț ea ș i - opț ional - gateway implicit)

Un server DNS operaț ional (care poate fi instalat pe DC-ul însuș i)

Un nume de domeniu pe care doriț i să-l utilizaț i

Media CD Windows Server 2003 sau folderul i386

Niveluri Funcț ionale

În Windows 2000, aț i ales între două niveluri: modul mixt sau modul nativ. Când a fost introdus Windows 2000 Server, NT
4 era în continuare o opț iune populară de server. Pentru a asigura compatibilitatea cu aceste servere ș i clienț i, Windows 2000 a fost setat implicit

în modul mixt în care puteai adăuga servere Windows NT 4 în domeniul Active Directory Windows 2000.
Windows Server 2003 a introdus niveluri funcț ionale - un nivel setat de compatibilitate retroactivă pentru sistemele de operare anterioare. Dacă
te afli într-un mediu cu servere NT 4 ș i servere Windows 2000 la care se accesează încă, poț i configura un funcț ional
nivel pentru a asigura compatibilitatea retroactivă.

Windows 2003 se extinde de la cele două moduri la unul dintre numeroasele niveluri funcț ionale ale domeniului, inclusiv Windows 2000 Mix.

Windows 2000 Native, Windows Server 2003 Interim ș i Windows Server 2003. De asemenea, în Windows Server 2003, aveț i
trei niveluri func ț ionale ale pădurii disponibile: Windows 2000, Windows Server 2003 Interim sau Windows Server 2003. Fiecare
nivelul funcț ional aduce noi caracteristici disponibile ș i pierde compatibilitatea cu unele seturi de servere sau clienț i.

În mod implicit, Windows Server 2003 porneș te la nivelul funcț ional mixt al Windows 2000. Nu toate caracteristicile din 2003 sunt disponibile.
în acest mod, aș a că dacă proiectaț i un nou mediu AD Windows 2003, veț i dori să profitaț i de noul
funcț ii adăugate în Windows Server 2003.

În Windows 2000, ne-am referit la această schimbare ca „schimbarea modului”, dar în Windows 2003, acum ridicăm nivelul funcț ional
cu fieActive Directory Utilizatori ș i Computere sauDomenii ș i Încredere.

Această schimbare nu poate fi inversată – odată ce iei o decizie de a ridica nivelul funcț ional, nu te poț i întoarce la un nivel inferior.
nivel funcț ional.
Instalarea Active Directory

Vă rugăm să reț ineț i: aceste instrucț iuni de instalare sunt pentru un domeniu complet nou – nu pentru adăugarea unui server ca server membru sau domeniu
controler într-un domeniu existent. Urmarea acestor instrucț iuni într-o reț ea de producț ie nu este recomandată.

Vom revizui procesul de instalare AD de la o instalare curată a Windows Server 2003. Este posibil să fi configurat deja
unele dintre aceste setări, aș a că verificaț i paș ii ș i efectuaț i orice sarcini pe care nu le-aț i îndeplinit.

Setări reț ea

1. Acest server va fi atât un controler de domeniu, cât ș i un server DNS, aș a că vom seta o adresă IP statică.

2. Faceț i clic pe Start, Panoul de control, Conexiuni de reț ea ș i selectaț i conexiunea dvs. de reț ea.

3. ClickProprietăț i.
4. Faceț i clic pe Protocol Internet (TCP/IP) ș i faceț i clic pe Proprietăț i.

5. Introduceț i informaț iile dvs. despre adresa IP statică ș i serverele DNS preferate. Observaț i că unul dintre serverele DNS pe care le-am enumerat este

serverul în sine - acesta va fi un server DNS în câteva momente.

6. Apasă OK.

7. ClickÎnchide.

8. Închideț i.

9. Faceț i clic pe Start. Faceti clic dreapta pe Computerul meu ș i selectaț i Proprietăț i.

10. Face ț i clic pe fila Numele Computerului.

11. Face ț i clic pe butonul Mai multe.

12. Introduce ț i numele de domeniu pe care urmează să-l folosi ț i pentru domeniul AD în sufixul DNS principal al acestui calculator.
câmp.
13. Face ț i clic pe OK.
14. Face ț i clic pe OK. Accepta ț i că trebuie să reporni ț i ș i face ț i clic pe OK.

15. Face ț i clic pe Da la promptul care vă întreabă dacă dori ț i să reporni ț i.

Instalaț i serviciul DNS

16. În fereastra Gestionează- ț i serverul, selectează Adaugă sau elimină un rol. (Nu vezi această fereastră la pornire? O găse ș ti la Start >
Toate programele > Instrumente administrative > Gestionaț i serverul

17. Face ț i clic pe Următorul.

18. Face ț i clic pe Server DNS ș i apoi pe Următorul.

19. Face ț i clic pe Următorul.

Introduce ț i CD-ul de instalare Windows Server 2003 ș i face ț i clic pe OK.

21. Naviga ț i la loca ț ia unde se află folderul i386 ș i face ț i clic pe OK.
22. Face ț i clic pe Următorul pentru a începe asistentul DNS.

23. Face ț i clic pe În continuare pentru a crea o zonă de căutare înainte.

24. Face ț i clic pe Următorul astfel încât acest server să re ț ină zona.

25. Denumi ț i zona dvs. cu numele domeniului dvs. Face ț i clic pe Următorul.

26. Accepta ț i numele de fi ș ier implicit ș i face ț i clic pe Următorul.

27. Apăsa ț i Permite ț i atât actualizările dinamice nesecurizate, cât ș i cele securizate. Apăsa ț i Următorul.
28. Selecta ț i dacă acest server DNS ar trebui să redirec ț ioneze interogările sau nu. Dacă utiliza ț i un ISP pentru rezolvarea DNS pentru site-uri Internet,
introduceț i serverele DNS ale ISP-ului dumneavoastră în prima opț iune. Dacă acest server DNS va rezolva toate interogările, selectaț i a doua opț iune.

ClickNext.

29. Apăsa ț i Finalizare.

30. Face ț i clic pe Finalizare.

31. Felicitări! Ai configurat un server DNS!

Configurarea Active Directory

32. În fereastraGestionează- ț i serverul, fă clic peAdaugă sau elimină o rol.

33. Apăsa ț i Următorul.

34. Selecta ț i Controler de Domeniu (Active Directory) ș i face ț i clic pe Următorul.

35. Face ț i clic pe Următorul.

36. Face ț i clic pe Următorul când se deschide asistentul pentru Active Directory.

37. Face ț i clic pe Următorul.

38. Faceti clic pe Următorul.

39. Face ț i clic pe Următorul.

40. Introduce ț i numele domeniului dvs. ș i face ț i clic pe Următorul.

41. Introduce ț i un nume NetBIOS sau accepta ț i valoarea implicită ș i face ț i clic pe Următorul.

42. Face ț i clic pe Următorul pentru a accepta loca ț iile implicite pentru baza de date ș i jurnal, sau selecta ț i o loca ț ie pentru aceste fi ș iere.

43. Introduce ț i o loca ț ie pentru Spa ț iul Sistemului Partajat ș i face ț i clic pe Următorul.
44. Face ț i clic pe Următorul.

45. Face ț i clic pe Următorul.

Introduce ț i o parolă ș i face ț i clic pe Următorul.

47. Face ț i clic pe Următorul.

48. Asistentul va configura Active Directory.

49. Face ț i clic pe Finalizare pentru a termina asistentul.

50. Faceti clic pe Repornire acum.

Felicitări, acum ai finalizat asistentul Active Directory ș i AD este instalat.

Crearea Unităț ilor Organizatorice (OU)

Aș a cum am discutat mai devreme, Unităț ile Organizaț ionale oferă un mecanism pentru a proiecta o structură ierarhică în cadrul Active
Mediul director. Odată ce ai proiectat structura AD, eș ti pregătit să creezi UOs în mediu.

1. ClickStart>Instrumente administrative>Utilizatori ș i calculatoare Active Directory.

2. Faceț i dublu clic pe numele domeniului pentru a îl deschide.

3. Ve ț i vedea o structură implicită fără Unită ț i Organizatorice. Face ț i clic dreapta pe numele domeniului ș i
selectaț iNou>Unitate Organizatorică.
4. Introdu numele OU-ului pe care doreș ti să-l creezi ș i apasă OK.

5. Acum vei vedea OU-ul pe care tocmai l-ai creat. Continuă procesul ș i construieș te OUs-urile de nivel superior.

6. Acum aveț i o structură din care să construiț i structura organizaț ională. Pentru o organizaț ie mică, am crea
unitate organizaț ională a utilizatorilor ș i computerelor sub fiecare dintre OUs de nivel superior.

7. Faceti clic dreapta pe Contabilitate ș i selecta ț i Nou > Unitate organiza ț ională ș i introduce ț i Computere. Face ț i clic pe OK. Repeta ț i aceasta

proces pentru utilizatoriiOU.

8. Acum repetă procesul pentru fiecare departament ș i vei avea o structură de UO-uri create.
Post Instalare Active Directory

Există mai mulț i paș i pe care ar trebui să îi urmezi după instalarea Active Directory pentru a te asigura că instalarea a decurs corect ș i pentru a face

Sigur AD funcț ionează corect în mediul tău.

Verificaț i instalarea

În primul rând, poț i să te asiguri că instrumentele AD sunt instalate. Fă clic pe Start ș i apoi pe Instrumente administrative. Ar trebui să ai aceste instrumente.

instalat:

Apoi, deschide Active Directory Sites and Services. Ar trebui să ai un Default-First-Site-Name listat ș i când îl deschizi,
ar trebui să găsiț i controlerul de domeniu listat ca server.

În cele din urmă, deschide gestionarea DNS. Deschide numele serverului DNS, zonele de căutare directă, numele domeniului ș i _tcp.
ar trebui să arate aș a cu patru înregistrări SRV:
Odată ce ai efectuat aceste sarcini, ai confirmat că mediu AD este instalat.
Utilitare de management

Există mai multe utilitare de gestionare pe care le foloseș ti pentru a gestiona mediul Active Directory. Aș a cum ai văzut după instalare,
ai aceste utilităț i (care sunt snap-in-uri MMC):

Active Directory Domenii ș i Încrederi: Gestionează domeniile ș i încrederile între domenii folosind acest instrument.

Active Directory Site-uri ș i Servicii: Configuraț i ș i gestionaț i site-uri (reț ele fizice).

Utilizatori ș i Computere Active Directory: Creaț i ș i gestionaț i utilizatori, computere, alte obiecte, UOs.