Serviciul de director Microsoft Windows Active Directory este un depozit central pentru toate obiectele întreprinderii și atributele corespunzătoare. Această bază de date are o structură ierarhică, este capabilă să suporte mai multe noduri master și să stocheze milioane de obiecte. Suportul multi-master permite modificarea bazei de date de la orice controler de domeniu din cadrul companiei, indiferent de starea de conectivitate la rețea.

Windows 2000 Multiple Master Support Model

O bază de date multi-master (cum ar fi Active Directory) acceptă modificări de la orice controler de domeniu din cadrul întreprinderii, provocând posibil conflicte atunci când datele sunt replicate pe alte computere. Una dintre metodele de eliminare a actualizărilor conflictuale din Windows 2000 este algoritmul „last-written-first”, care acceptă valoarea datelor de la controlerul de domeniu care a fost modificat cel mai recent și elimină valorile de pe controlerele de domeniu rămase. Cu toate acestea, unele conflicte sunt atât de complexe încât nu pot fi rezolvate în acest fel. Este mai ușor să le preveniți decât să le eliminați după fapt.

Unele tipuri de modificări în Windows 2000 sunt gestionate folosind metode care împiedică conflictele de actualizare Active Directory.

Windows 2000 Single Master Support Model

Pentru a preveni apariția actualizărilor conflictuale, Active Directory efectuează actualizări pentru anumite obiecte folosind un model single-master. Conform acestui model, un singur controler de domeniu din întregul director are dreptul de a face actualizări. Acest proces similar cu rolul atribuit controlerului de domeniu primar (PDC) la început versiuni Windows(de exemplu, în Microsoft Windows NT 3.51 și 4.0), unde PDC este responsabil pentru procesarea tuturor actualizărilor dintr-un anumit domeniu.

Windows 2000 Active Directory extinde modelul single-master utilizat în versiunile anterioare de Windows pentru a include suport pentru mai multe roluri și abilitatea de a delega roluri altor controlori din cadrul întreprinderii. Deoarece rolul Active Directory nu este strict legat de un singur controler de domeniu, acesta se numește rol Flexible Single Master Operation (FSMO). Există cinci roluri FSMO în Windows 2000:

• maestru al circuitului
• master de nume de domenii
• proprietar RID
• Emulator PDC
• demonul infrastructurii

Rolul FSMO „Scheme Master”

Controlerul de domeniu, care acționează ca master schema, este responsabil pentru actualizarea schemei de director (adică contextul de denumire a schemei sau LDAP://cn=schema,cn=configuration,dc= ). Numai acest controler de domeniu poate face modificări în schema de director. După ce o schemă este actualizată, aceasta este replicată de la masterul schemei la alți controlere de domeniu din director. Într-un director poate exista un singur master de schemă.

Rolul FSMO „Maestru de denumire a domeniilor”

Controlerul de domeniu, care acționează ca master de denumire a domeniului, este responsabil pentru schimbarea spațiului de nume de domeniu al directorului din pădure (adică contextul de denumire partiții\configurație sau LDAP://CN=Partiții, CN=configurație, DC= ). Doar acest controlor are dreptul de a elimina și adăuga domenii în director. În plus, adaugă și elimină referințele încrucișate la domenii din directoare externe.

Rolul FSMO „RID Master”

Controlerul de domeniu, care acționează ca master RID, este responsabil pentru procesarea cererilor de pool RID de la alți controlori dintr-un anumit domeniu și pentru eliminarea obiectelor din domeniu și plasarea lor într-un alt domeniu.

Când un controler de domeniu creează un obiect principal de securitate primar (cum ar fi un utilizator sau un grup), îi atribuie un identificator de securitate (SID). Acest identificator constă dintr-un SID de domeniu (unic pentru toți identificatorii de securitate creați în același domeniu) și un identificator relativ (RID) (unic pentru fiecare principal de securitate creat în același domeniu).

Fiecare controler de domeniu Windows 2000 dintr-un domeniu are un grup de identificatori relativi (RID) pe care îi poate atribui principalelor de securitate pe care îi creează. Când numărul de RID-uri din pool-ul unui controler de domeniu scade sub un prag, acesta solicită noi ID-uri de la master RID. Maestrul RID preia identificatorii din pool-ul nealocat al domeniului și îi atribuie pool-ului controlerului de domeniu solicitant. Există un singur master RID în fiecare domeniu de director.

Rol FSMO „Emulator PDC”

Este necesar un emulator PDC pentru sincronizarea timpului într-o întreprindere. Windows 2000 include serviciul de timp W32Time (Windows Time) care este utilizat de protocolul de autentificare Kerberos. Toate computerele sunt sub Control Windows 2000 într-o singură întreprindere folosesc timpul total. Pentru a asigura sincronizarea corectă a orei, serviciul Windows Time trebuie să utilizeze o structură de relații ierarhice care controlează permisiunile și previne buclele în management.

Emulatorul de domeniu PDC acționează ca emulator de domeniu principal. Emulatorul PDC de la rădăcina pădurii devine principalul emulator în cadrul întreprinderii. Ar trebui configurat să primească valoarea timpului de la o sursă internă. Deținătorii de rol FSMO emulator PDC urmează ierarhia domeniului atunci când aleg o sursă de timp.

Într-un domeniu Windows 2000, deținătorul rolului de emulator PDC păstrează următoarele funcții: Modificările parolei făcute de alte controlere de domeniu sunt mai întâi replicate pe emulatorul PDC.

Modificările parolei făcute de alți controlere de domeniu sunt mai întâi replicate pe emulatorul PDC.

Înainte ca utilizatorul să primească mesajul de eroare corespunzător, mesajele despre eșecuri de autentificare pe un anumit controler de domeniu cauzate de o parolă incorectă sunt trimise la emulatorul PDC.

Cazurile de blocare a contului sunt procesate pe emulatorul PDC.

Emulatorul PDC îndeplinește toate funcțiile emulatorului de server PDC pentru Microsoft Windows NT 4.0, Versiuni anterioare emulatoare activate Bazat pe Windows Clienți NT 4.0 sau anterioare.

Nu este nevoie să utilizați această parte a rolului de emulator PDC dacă toate stațiile de lucru, serverele și controlerele de domeniu care rulează Windows NT 4.0 sau o versiune anterioară sunt actualizate la Windows 2000. Emulatorul PDC îndeplinește toate aceleași funcții ca într-un mediu Windows 2000.

Următoarele descriu modificările care apar în timpul procesului de actualizare: Clienții Windows 2000 (stații de lucru, servere) și clienții anteriori care au instalat pachetul de client pentru servicii distribuite nu acordă preferință controlerului de domeniu atunci când fac scrieri în director (cum ar fi modificări de parolă) , care sa declarat un PDC și să folosească orice controler de domeniu pentru aceasta.

După actualizarea la Windows 2000, controlere de rezervă (BDC) în domenii nivel inferior Emulatorul PDC nu mai primește cereri de replicare de la nivelul inferior.

Clienții Windows 2000 (stații de lucru, servere) și clienții anteriori care au instalat pachetul de client pentru servicii distribuite folosesc Active Directory pentru a localiza resursele de rețea. Nu necesită serviciul de navigare Windows NT.

Rolul FSMO „Infrastructură”

O referință la un obiect dintr-un domeniu în cadrul unui obiect dintr-un alt domeniu este determinată de GUID, SID (pentru principii de securitate) și numele distinctiv (DN) al obiectului. Controlerul de domeniu, care acționează ca maestru al infrastructurii, este responsabil pentru actualizarea identificatorilor de securitate și a numelor distincte ale obiectelor în referințele de obiecte între domenii.

Notă.

Rolul Infrastructure Master (IM) nu ar trebui să fie deținut de un controler de domeniu care este un server de catalog global. În caz contrar, masterul infrastructurii nu va actualiza informațiile despre obiect deoarece nu conține referințe la obiecte pe care nu le stochează. Motivul pentru acest comportament este că serverul de catalog global menține replici parțiale ale tuturor obiectelor din pădure. Drept urmare, legăturile de obiecte între domenii din acest domeniu nu vor fi actualizate și un avertisment corespunzător va apărea în jurnalul de evenimente al acestui controler de domeniu.

Dacă controlorii dintr-un singur domeniu stochează și catalogul global, toți controlorii de domeniu vor avea cele mai recente informații, indiferent de controlerul de domeniu care deține rolul de maestru al infrastructurii.

Nu există postări similare...

Mutăm FSMO. Scopul evenimentului nostru este de a transfera FSMO de la un controler de domeniu la altul. Pentru orice eventualitate, voi lua în considerare mai multe modalități de a transfera roluri, inclusiv cazul în care proprietarul actual FSMO nu este disponibil.

În primul rând, o mică teorie:
FSMO (Flexible single-master operations - „operații cu un singur executant”) - tipuri efectuate de controlori domeniu Activ Operațiuni de director care necesită unicitatea obligatorie a serverului care le realizează.

Adică toți controlorii de domeniu sunt egali, dar unul (sau mai mulți) sunt mai egali decât alții, în măsura în care efectuează aceleași operațiuni cu un singur executor. În funcție de tipul de operațiune, unicitatea FSMO este implicată fie într-o pădure de domenii, fie într-un domeniu.

În total, corporația small-soft ne-a oferit 5 roluri:

• Proprietarul schemei (Schema master) este un server cu acest rol pentru întreaga pădure. Rolul este necesar pentru a extinde schema păduri Activ Director, această operație este de obicei efectuată cu comanda adprep /forestprep
• Proprietarul numelor de domenii (Domain naming master) este unul pentru întreaga pădure. Un server cu acest rol trebuie să asigure nume unice pentru toate domeniile și partițiile de aplicații create în pădurea AD.
• Proprietarul identificatorilor relativi (emulator PDC) este un server pe domeniu. Îndeplinește mai multe funcții: este browserul principal în Rețeaua Windows, monitorizează blocările utilizatorilor atunci când parolele sunt introduse incorect, este principalul server NTP din domeniu, conceput pentru a sprijini clienții cu sisteme de operare anterioare Windows 2000.
• Emulator al controlerului de domeniu principal (Infrastructure Master) - un server per domeniu. Este necesar un server cu acest rol pentru a executa cu succes comanda adprep /domainprep. Responsabil pentru actualizarea identificatorilor de securitate (GUID-uri, SID-uri) și a numelor distincte ale obiectelor din referințele de obiecte pe mai multe domenii.
• Proprietarul infrastructurii de domeniu (RID Master) - un server per domeniu. Serverul distribuie RID-uri (500 fiecare) altor controlori de domeniu pentru a crea SID-uri unice.

Pentru a gestiona rolul de master Schema, trebuie să vă aflați în grupul „Administratori Schema”.
Pentru a gestiona rolul de master al denumirii domeniului, trebuie să fiți membru al grupului de administratori Enterprise.
Pentru a gestiona rolurile de emulator PDC, Maestru de infrastructură și Maestru RID, trebuie să aveți drepturi de administrator de domeniu.

Necesitatea transferului de roluri poate apărea din diverse motive, inclusiv rețele mari aceste roluri pot fi îndeplinite de servere diferite, deși în cazul nostru toate rolurile sunt îndeplinite de un singur server. Este important ca fiecare rol să fie executat în domeniul dvs.; dacă vreun rol nu este atribuit unui server, atunci este posibil să aveți o mulțime de surprize neplăcute, atât imediat, cât și pe o perioadă lungă de timp, în funcție de structura AD.

Când creați un domeniu, în mod implicit toate rolurile sunt atribuite primului controler de domeniu din pădure. Reatribuirea rolurilor este rareori necesară. Microsoft recomandă utilizarea transferului de rol FSMO în următoarele cazuri:

• Retrogradarea planificată a unui controler de domeniu care deține roluri FSMO, de exemplu, pentru a dezafecta un server (acesta este exact cazul meu);
• Dezactivarea temporară a unui controler de domeniu, de exemplu pentru a efectua munca preventivă. Acest lucru este deosebit de important atunci când dezactivați emulatorul PDC. Dezactivarea temporară a altor operațiuni master are un impact mai mic asupra funcționării AD.

Captarea rolurilor FSMO va trebui făcută în următoarele cazuri:

• Dacă titularul actual al rolului FSMO se confruntă cu o întrerupere care împiedică îndeplinirea cu succes a funcțiilor asociate rolului și împiedică transferul rolului;
• Pe controlerul de domeniu care deținea rolul FSMO, sistemul de operare a fost reinstalat sau nu a pornit;
• Controlerul de domeniu care deținea rolul FSMO a fost retrogradat forțat folosind comanda dcpromo /forceremoval.

Deci, primul lucru de care avem nevoie este să aflăm care server este gazda FSMO. Cel mai simplu mod de a face acest lucru este utilizarea utilitarului netdom. Tastând în consolă:

> interogare netdom fsmo

Vom primi o listă cu toate cele cinci roluri cu FQDN-ul proprietarilor. Puteți folosi același utilitar după transferul rolurilor pentru a asigura succesul operațiunii.

Acum puteți trece direct la transferul FSMO:

Prima metodă este cea mai simplă și îmi place cel mai mult - transferul rolurilor FSMO folosind utilitarul ntdsutil:

ntdsutil.exe este un utilitar de linie de comandă conceput pentru a menține directorul Active Directory. Oferă multe capacități de management AD, inclusiv transferul și preluarea rolurilor FSMO.
Pentru a transfera roluri, mergeți la orice controler de domeniu (Acesta nu trebuie să fie proprietarul actual sau viitor al FSMO), situat în pădurea în care trebuie transferate rolurile. Este recomandat să vă conectați la controlerul de domeniu căruia îi sunt atribuite roluri FSMO. Lansați consola și introduceți:
>ntdsutil
După care utilitarul pornește în modul interactiv și poate accepta comenzi. Prima noastră comandă indică faptul că vrem să lucrăm cu FSMO
>roluri
Ca răspuns, promptul se va schimba în fsmo maintenance: Apoi, pentru a apela conexiunea „meniu”, intrați
> conexiuni
Și promptul se modifică la conexiunile la server: Acum putem specifica la ce server vrem să ne conectăm (<Имя_сервера>- numele controlerului de domeniu căruia doriți să transferați rolul FSMO.)
> conectați-vă la server<Имя_сервера>
pentru a ieși din meniul de conectare, intrați
>q
și apăsați Enter. Acum, după ce a primit întreținerea fsmo: prompt din nou, putem începe să transferăm roluri. Comanda de transfer este concepută pentru aceasta:
> transfer<имя_роли>
La fel de<имя_роли>trebuie să specificați rolul pe care doriți să îl transferați:

• naming master - transfer al rolului de proprietar al numelor de domenii;
• infrastructure master - transferarea rolului de infrastructure master;
• RID master - transfer al rolului de master RID;
• schema master - transferul rolului de master schema;
• PDC - transferul rolului de emulator PDC.

În versiunile de Windows anterioare Windows Server 2008R2, masterul de denumire a domeniului este numit master de denumire a domeniului. După cum se obișnuiește în sistemele Windows, cazul nu contează.

După introducerea fiecărei comenzi de transfer, apare o casetă de dialog care cere confirmarea (puteți cere confirmarea și în consolă, altfel se dovedește „nu în consolă”), faceți clic pe „OK” de fiecare dată, cu excepția cazului în care, desigur, ați tastat toate comenzile anterioare din întâmplare. :)
Pentru a opri Ntdsutil, introduceți comanda q și apăsați Enter.

Forțarea rolurilor fsmo folosind Ntdsutil

Dar ce ar trebui să facem dacă proprietarul rolului este indisponibil, deteriorat și nu există nicio speranță de a-l repune în funcțiune în viitorul apropiat? Și aici ntdsutil.exe ne va ajuta din nou:
Atribuirea forțată (sechestrarea) rolurilor se efectuează numai în cazul unei defecțiuni complete a serverului, cu imposibilitatea recuperării acestuia. Dacă este posibil, este mai bine să restabiliți funcționalitatea unei gazde FSMO eșuate. Procedura de captare în sine este similară cu cea descrisă mai sus. Mergem la controlerul de domeniu căruia dorim să-i transferăm rolurile și facem la fel cum a fost scris în paragraful anterior introducând:
>ntdsutil
>roluri
> conexiuni
> conectați-vă la server<имя_сервера>
>q
Singura diferență este că, în loc de comanda de transfer, comanda este folosită pentru a forța preluarea rolului apuca
> apuca<имя_роли>
Unde<имя_роли>Ca înainte

• naming master - domain name master (înainte de Windows Server 2008R2 - domain naming master);
• infrastructure master - maestru de infrastructură;
• rid master - proprietar al RID-ului;
• schema master - schema master;
• pdc - emulator PDC.

Nu uitați să încercați să transferați rolul utilizând comanda de transfer înainte de a prelua rolul și să utilizați seize numai dacă nu reușiți.

Dacă este posibil, nu atribuiți rolul de maestru al infrastructurii unui controler de domeniu care este un server de catalog global, deoarece nu va actualiza informațiile despre obiect. Motivul pentru acest comportament este că serverul de catalog global menține replici parțiale ale tuturor obiectelor din pădure.

În niciun caz nu trebuie să reveniți la service un controler de domeniu care a îndeplinit anterior roluri FSMO dacă rolurile pe care le-a îndeplinit au fost preluate de comanda seize deoarece atunci când apare în rețea, va apărea un conflict, care poate duce la mari necazuri. Trebuie eliminat din Active Directory. În Windows Server 2008 și mai vechi, acest lucru se poate face prin simpla ștergere a obiectului server din snap-in-ul Active Directory Users and Computers, iar în Windows Server 2003 utilizând programul Ntdsutil folosind comanda ntdsutil - metadata cleanup.

A doua opțiune este transferul voluntar al rolurilor FSMO folosind snap-in-uri de management Active Directory, ciudat și incomod, dar aceasta este doar părerea mea subiectivă, metoda în sine funcționează grozav.

Puteți transfera roluri la nivel de domeniu (RID Master, PDC Emulator și Infrastructure Master) folosind snap-in-ul Active Directory Users and Computers. Pentru a face acest lucru, mergeți la controlerul de domeniu către care dorim să transferăm roluri, lansați snap-in-ul și faceți clic tasta dreapta mouse-ul pe domeniul dorit, selectați „Operation Masters”.

În fereastra care se deschide, selectați rolul de care avem nevoie și faceți clic pe butonul „Schimbare”, apoi confirmăm transferul rolului și ne uităm la rezultat. Numele proprietarului operațiunii ar trebui schimbat cu numele serverului curent.

Pentru a migra rolul Domain Naming Master, veți avea nevoie de snap-in Active Directory Domains and Trust. Lansăm snap-in-ul, dacă este necesar, ne conectăm la controlerul de domeniu dorit, facem clic dreapta în rădăcina snap-in-ului și selectăm elementul de meniu „Operations Master”.

Se deschide o fereastră în care trebuie să faceți clic pe butonul „Schimbare” și apoi să confirmați modificările în același mod ca în cazul precedent.

Pentru a transfera rolul Schema Master, va trebui să efectuați manipulări ceva mai complexe. Mai întâi trebuie să înregistrați Biblioteca de gestionare a schemelor Active Directory în sistem. Acest lucru se poate face cu o echipă
> regsvr32 schmmgmt.dll

Apoi deschideți consola MMC și adăugați la ea snap-in Schema Active Directory.

Acum puteți intra în snap-in și puteți schimba proprietarul rolului Schema Master, ca în exemplele anterioare, făcând clic dreapta pe schemă și selectând „Operations Master...”.

Ura! Toate rolurile au fost transferate. Încă o dată, nu părăsiți niciodată domeniul fără FSMO desemnati. Nu! :)

• Înapoi

Comentarii

Articole noi:

• Descoperirea rețelei nu se activează în Windows 7/8/2008/2012

  Esența problemei este că sistemul Windows 7 al utilizatorului nu pornește descoperirea rețeleiîn setările de rețea. Mai exact, se aprinde, dar dacă îl închizi și...

• Eroare: această aplicație nu a reușit să pornească deoarece nu a putut găsi sau încărca pluginul platformei Qt „windows”.

  Deci, după instalare prin copierea directă a unei aplicații scrise în C++ folosind biblioteca Qt, obținem următoarea eroare: Această aplicație nu a pornit...

hb860 25 noiembrie 2011 la 14:02

Tot ce ai vrut să știi despre maeștrii de operațiuni, dar ți-a fost teamă să întrebi

• Administrarea sistemului

Majoritatea administratorilor de sistem au mediul corporativ Pentru a oferi un sistem de identificare și accesare a utilizatorilor lor la resurse, întreprinderile folosesc domeniul Servicii active Director, care poate fi numit în siguranță inima întregii infrastructuri a întreprinderii. După cum mulți dintre voi știți, structura Serviciilor de domeniu din organizații poate include una sau mai multe păduri (un set de domenii care include o descriere a configurației rețelei și o singură instanță a directorului), în funcție de factori precum limitările domeniului de aplicare relații de încredere, separarea completă a datelor din rețea, obținerea izolării administrative. La rândul său, fiecare pădure mare ar trebui să fie împărțită în domenii pentru a simplifica administrarea și replicarea datelor. În fiecare domeniu pentru a gestiona serviciile de domeniu și pentru a efectua sarcini cum ar fi autentificarea, pornirea serviciului „Centrul de distribuție a cheilor Kerberos” iar controlul accesului folosește controlere de domeniu. Și pentru control trafic de rețea Site-urile web sunt dezvoltate între birouri.
Toate informațiile despre păduri, domenii și site-uri, desigur, trebuie coordonate în timpul proiectării Serviciilor de domeniu Active Directory, în conformitate cu cerințele corporative precum: cerințele de afaceri, cerințele funcționale, cerințele legale, de securitate, precum și restricțiile de proiectare privind documentația . Adesea, toate aceste puncte înainte de implementarea serviciilor de domeniu sunt planificate cu atenție de departamentul IT al companiei în sine sau de echipa de proiect implicată în infrastructura întreprinderii și sunt înscrise într-un acord special de nivel de serviciu care determină nivelul așteptat de performanță și calitate a serviciu prestat.
Informațiile obținute după proiectare sau, mai des, după implementarea Serviciilor de domeniu Active Directory ar trebui documentate cu atenție. O astfel de documentație ar trebui să includă informații despre structura logică și fizică a serviciilor de domeniu în sine, modele administrative, infrastructura de rezoluție a numelor, orice modificări planificate în mediul organizației, precum și componente suplimentare ale infrastructurii, cum ar fi implementarea serverelor de e-mail. Microsoft Exchange, servere System Center și multe altele. În cele mai multe cazuri, personalul IT al organizației ignoră procesul de documentare și, atunci când schimbă personalul IT, poate dura ceva timp pentru ca noii administratori să înțeleagă pe deplin infrastructura actuală a organizației.
De asemenea, trebuie să înțelegeți că într-un serviciu de directoare, aproape toți controlorii de domeniu sunt egali (în acest context nu luăm în considerare controlorii de domeniu doar pentru citire, RODC), adică toți controlorii de domeniu au dreptul de a scrie în baza de date și poate replica aceste date altor controlori. Această topologie gestionează perfect cele mai banale operațiuni Active Directory și este numită replicare multi-peer(Multimaster). Dar, cu toate acestea, există unele operațiuni care trebuie efectuate pe un server autorizat special desemnat pentru astfel de operațiuni. Cu alte cuvinte, controlorii de domeniu care efectuează anumite operațiuni sau roluri în domeniul lor sunt numiți operațiuni master (sau masters). Este necesar să se cunoască și să se înțeleagă scopul tuturor rolurilor maeștrilor de operațiuni, deoarece în cazul recuperare în caz de dezastru, upgrade-uri sau migrări, controlorii de domeniu care acționează ca maeștri de operațiuni pot juca unul dintre cele mai importante roluri. În consecință, maeștrii operațiunilor vor fi discutați în acest articol.
Din acest articol veți învăța:

• Despre ce s-ar întâmpla dacă nu ar exista maeștri de operațiuni;
• Despre rolurile maeștrilor operațiuni la nivel forestier;
• Despre rolurile maeștrilor operațiuni la nivel de domeniu;
• Cum să determinați ce controlor are rolul FSMO;
• Cu privire la sechestrarea și transferul rolurilor de comandanți de operațiuni;
• Despre plasarea corectă a operațiunilor master pe controlerele de domeniu.

• Planificați și documentați controlerele de domeniu cu roluri de master operațiuni. Acesta este un subiect separat care implică înțelegerea nuanțelor planificării pentru Active Directory Domain Services și depășește scopul acestui articol;
• Servere de catalog global. Mulți administratori de sistem echivalează serverele de catalog globale cu roluri de master operațiuni. De fapt, aceasta este o propunere falsă. Un catalog global este un depozit de date distribuite care stochează informații despre fiecare obiect și permite utilizatorilor și aplicațiilor să găsească obiecte în orice domeniu al pădurii curente prin căutarea atributelor incluse în catalogul global, care sunt identificate în schemă ca un set privat de atribute. Catalogul global în sine rezidă pe controlere de domeniu desemnate ca servere de catalog global și este, la rândul său, replicat prin replicarea Multimaster. Deși catalogul global conține lista plina dintre toate obiectele din pădure, iar serverele de catalog global pot răspunde la toate solicitările fără a fi nevoie să se refere la alți controlere de domeniu, catalogul global nu este un rol de maestru de operațiuni. Puteți citi următorul articol despre serverele de catalog globale: „Servere de catalog globale”;
• Cum interacționează vrăjitorii de operații cu controlerele de domeniu numai pentru citire. Controlerele de domeniu numai pentru citire sunt un special, relativ tip nou controlori de domeniu, care este recomandabil să fie implementați în sucursalele unei organizații care nu au un nivel adecvat de securitate și personal IT calificat. La fel ca în cazul operațiunilor de programare master și al serverelor de catalog global, controlerele de domeniu numai în citire sunt un subiect amplu pe care nu are rost să îl tratam în acest articol. Dar merită să acordați atenție imediat faptului că controlerele de domeniu numai în citire nu pot acționa ca un controler de domeniu cu rolul de maestru de operațiuni;
• Depanare și erori legate de vrăjitorii de operare. Un subiect interesant și destul de voluminos care nu va fi discutat, datorită faptului că articolul de față discută conceptele generale ale rolurilor maeștrilor de operațiuni.

Ce s-ar întâmpla dacă nu ar exista maeștri de operațiuni?

• Protocol ușor de acces la director (LDAP);
• SMTP.

Roluri de maestru al operațiunilor la nivel de pădure

• Schema Master;
• Expertul de denumire a domeniilor

Rol de maestru al schemei

Rolul maestrului de nume de domenii

• Adăugarea și eliminarea domeniilor. Atunci când efectuează o operațiune precum adăugarea sau ștergerea unui domeniu copil folosind Active Directory Installation Wizard sau un utilitar de linie de comandă, expertul de instalare contactează Domain Naming Wizard și solicită dreptul de a adăuga sau, în consecință, de a-l șterge pe acesta din urmă. Domain Naming Master este, de asemenea, responsabil pentru a se asigura că domeniile din pădure au nume unice NETBIOS în întreaga pădure. Desigur, din motive evidente, dacă Domain Naming Wizard nu este disponibil, nu veți putea adăuga sau elimina domenii din pădure;
• Adăugarea și eliminarea referințelor încrucișate. După cum știți deja, atunci când creați primul controler de domeniu într-o pădure, schema, configurația și partițiile directorului de domeniu sunt create în ea. În acest moment, pentru fiecare partiție de director din containerul Partiții din secțiunea de configurare (CN=partiții,CN=configurare,DC=forestRootDomain) este creat un obiect de referință încrucișată (clasa crossRef). Obiectul de referință încrucișată specifică numele și locația serverelor care stochează fiecare partiție de director în pădure. Când fiecare domeniu ulterioar sau partiția de director de aplicație este creată, crearea unui obiect de referință încrucișată este declanșată în containerul Partiții.
• Adăugarea și eliminarea partițiilor din directorul de aplicații. Partițiile din directorul de aplicații sunt partiții speciale pe care le puteți crea pe controlere de domeniu Windows Server 2003, Windows Server 2008 sau Windows Server 2008 R2 pentru a oferi stocare pentru datele dinamice ale aplicației LDAP. Dacă pădurea ta lucrează pentru Nivel Windows Server 2000, apoi într-o astfel de pădure, toate datele non-domeniu sunt limitate la date de configurare și schemă, care sunt replicate tuturor controlerelor de domeniu din pădure. Într-o pădure Windows Server 2003/2008 și 2008R2, partițiile directorului de aplicații oferă stocarea datelor specifice aplicației pe un controler de domeniu care poate fi replicat pe orice controler de domeniu din pădure.
• Confirmarea instrucțiunilor de redenumire a domeniului. Ultima acțiune efectuată de Expertul de denumire a domeniilor este confirmarea instrucțiunilor de redenumire a domeniului. De obicei, domeniile sunt redenumite folosind un utilitar special de linie de comandă. Deci, atunci când utilizați utilitarul Rendom.exe, care este conceput pentru a redenumi domeniile, pentru a redenumi un domeniu, utilitarul trebuie să aibă acces la Domain Naming Wizard. Pe lângă caracteristicile de mai sus, Expertul de denumire a domeniilor este, de asemenea, responsabil pentru confirmarea instrucțiunilor de redenumire a domeniului. Când rulați instrumentul specificat pe un controler de domeniu cu rolul Expert Naming Wizard, un script XML care conține instrucțiuni pentru redenumirea domeniilor este scris în atributul msDS-UpdateScript al obiectului container Partitions (CN=partiții,CN=configurație,DC=forestRootDomain). ) din secțiunea Director de configurare. Merită să ne amintim că containerul Partitions poate fi actualizat numai pe un controler de domeniu care conține rolul Domain Naming Master. Pe lângă valoarea atributului msDS-UpdateScript, Rendom.exe scrie noul nume DNS al fiecărui domeniu redenumit în atributul msDS-DnsRootAlias ​​al obiectului crossRef corespunzător acelui domeniu. Din nou, deoarece obiectul de referință încrucișată este stocat în containerul Partitrions, acest obiect poate fi actualizat numai pe un controler de domeniu cu rolul de Master Naming Domain. Datele modificate ale atributelor msDS-UpdateScript și msDS-DnsRootAlias ​​sunt replicate tuturor controlerelor de domeniu din pădure.

Roluri de master pentru operațiuni la nivel de domeniu

• Expert RID relativ
• Emulator PDC Master Domain Controller
• Maestru de infrastructură

Maestru RID

Emulator PDC

• Participați la replicarea actualizărilor parolelor de domeniu. Când parola unui utilizator este schimbată sau resetată, controlerul de domeniu care efectuează modificarea reproduce modificarea către emulatorul PDC prin replicare flash. Această replicare asigură că controlorii de domeniu recunosc rapid parola schimbată. În cazul în care un utilizator încearcă să se conecteze imediat după ce și-a schimbat parola, este posibil ca controlerul de domeniu care răspunde la această solicitare să nu știe încă Parolă Nouă. Înainte de a respinge încercarea de autentificare, acest controler de domeniu trimite o cerere de autentificare emulatorului PDC, care verifică dacă noua parolă este corectă și îi cere controlerului de domeniu să accepte cererea de autentificare. Aceasta înseamnă că de fiecare dată când utilizatorul introduce o parolă incorectă, o verificare de autentificare este trimisă emulatorului PDC pentru o concluzie finală;
• Gestionarea actualizărilor politicilor de grup într-un domeniu. După cum știți, politicile de grup sunt folosite pentru a controla majoritatea setărilor din configurația computerelor și utilizatorilor din organizația dvs. Dacă un GPO este modificat pe două controlere de domeniu aproximativ în același timp, pot apărea ulterior conflicte între cele două versiuni care nu sunt rezolvate atunci când GPO-urile sunt replicate. Pentru a evita astfel de conflicte, emulatorul PDC funcționează după cum urmează: la deschiderea unui GPO, snap-inul Editor de gestionare a politicilor de grup este legat de controlerul de domeniu care îndeplinește rolul PDC și toate modificările GPO-urilor sunt făcute implicit în emulatorul PDC;
• Servind ca browser central pentru un domeniu. Clienții folosesc Active Directory pentru a descoperi resursele rețelei. La deschiderea unei ferestre "Net" Sistemul de operare afișează o listă de grupuri de lucru și domenii. După ce utilizatorul deschide cea specificată grup de lucru sau domeniu, el va putea vedea o listă de computere. Aceste liste sunt generate prin intermediul serviciului de browser, iar pe fiecare segment de rețea, browserul gazdă creează o listă de navigare cu grupurile de lucru, domeniile și serverele acelui segment. Browserul central acumulează apoi listele tuturor browserelor principale, astfel încât mașinile client să poată vizualiza întreaga listă de navigare. Cred că dintre toate funcțiile emulatorului PDC, este posibil să aveți întrebări legate direct de browserul de domeniu central, prin urmare, acest subiect va fi discutat în detaliu într-un articol separat;
• Furnizarea unei surse de timp pentru domeniul master. Deoarece Active Directory, Kerberos, DFS-R și Serviciul de replicare a fișierelor FRS utilizează marcaje temporale, sincronizarea timpului este necesară în toate sistemele de domeniu. Emulatorul PDC din domeniul rădăcină pădurii servește ca sursă de timp principală pentru întreaga pădure. Controlerele de domeniu rămase sincronizează ora cu emulatorul PDC, iar computerele client sincronizează ora cu controlerele lor de domeniu. Garanția pentru respectarea timpului este oferită de serviciul de sincronizare ierarhică, care este implementat în serviciul Win32Time.

Maestru de infrastructură

Cum pot determina ce controler de domeniu are rolul FSMO?

Determinarea deținătorilor de rol Operations Master folosind GUI

Determinarea deținătorilor de rol de master al operațiunilor folosind linia de comandă

Orez. 6. Definirea rolurilor FSMO folosind utilitarul Dcdiag

Captarea și transferul rolurilor de master operațiuni

1. Deschis Linie de comandași în ea mergi la utilitate ntdsutil;
2. Accesați gestionarea rolurilor NTDS utilizând comanda roluri;
3. Trebuie să stabiliți o conexiune la controlerul de domeniu, care în viitor va acționa ca proprietar al masterului operațiunilor. Pentru a face acest lucru, executați comanda conexiuni;
4. În linie "conexiuni la server" introduce conectați-vă la serverși specificați controlerul de domeniu necesar;
5. Intoarce-te la managementul fsmo folosind comanda părăsi;
6. Acum la coadă managementul fsmo specifica comanda apucași faceți clic pe introduce;
7. În acest ultim pas, trebuie să selectați rolul FSMO care va fi preluat de la controlerul de domeniu inactiv.

1. Deconectați fizic un astfel de controler de domeniu de la rețea;
2. Retrogradați un controler de domeniu la un server membru folosind comanda Dcpromo/forceremoval;
3. Ștergeți metadatele pentru controlerul de domeniu actual. Puteți curăța metadatele folosind utilitarul Ntdsutil cu echipa Curățarea metadatelor;
4. După eliminarea metadatelor, trebuie să aduceți serverul online, să îl alăturați unui domeniu și apoi să promovați serverul la un controler de domeniu;
5. În ultimul pas, pur și simplu transferați rolul acestui controler de domeniu.

Găzduire operațiuni de master pe controlere de domeniu

• Plasați rolurile RID Master și PDC Emulator pe același controler de domeniu. Colocarea acestor roluri de master operațiuni este din motive de echilibrare a sarcinii. Deoarece aceste roluri sunt parteneri de replicare directe, plasând aceste roluri pe controlere de domeniu separate, va trebui să stabiliți o conexiune rapidă pentru cele două sisteme corespunzătoare și să creați obiecte explicite pentru acestea în Active Directory. În plus, dacă aveți servere în organizația dvs. care joacă rolul de master al operațiunilor de rezervă, pe astfel de servere aceste roluri trebuie să fie și parteneri direcți;
• Plasați schema și rolurile master de denumire a domeniului pe același controler de domeniu. Ca regulă generală, se recomandă ca rolurile Schema Master și Domain Naming Master să fie plasate pe același controler de domeniu care servește ca server de catalog global. Rolul Domain Naming Master trebuie să fie, de asemenea, un server de catalog global, deoarece la adăugarea unui nou domeniu, masterul trebuie să se asigure că nu există niciun obiect în pădure cu același nume cu noul domeniu care este adăugat. Dacă controlerul de domeniu cu rolul Domain Naming Master nu este un server de catalog global, operațiuni precum crearea de domenii secundare pot eșua. Deoarece aceste roluri sunt cele mai puțin utilizate, ar trebui să vă asigurați că controlerul de domeniu care le gestionează este cât mai sigur posibil;
• Rolul Infrastructure Master trebuie să fie găzduit pe un controler de domeniu care nu servește ca server de catalog global. De obicei, Expertul pentru infrastructură ar trebui să fie implementat pe un controler de domeniu care nu servește ca server de catalog global, dar are un obiect conexiune directa la unul dintre directoarele globale din pădure. Deoarece serverul de catalog global stochează replici parțiale ale tuturor obiectelor din pădure, masterul de infrastructură găzduit pe serverul de catalog global nu va efectua actualizări deoarece nu conține referințe la obiecte pe care nu le stochează.

În loc de concluzie