Roluri FSMO în Active Directory: ce sunt și cum funcționează

Active Directory (AD) este un serviciu de director creat de Microsoft și vine ca un set de procese și servicii în majoritatea versiunilor sistemelor de operare Windows Server.

vă puteți imagina anunțul ca o bază de date sau o locație sigură care stochează toate atributele utilizatorilor dvs., cum ar fi numele de utilizator, parolele și multe altele. Acest depozit central automatizează multe sarcini, cum ar fi gestionarea datelor Utilizatorului, furnizarea de securitate și inter-operațiuni cu alte directoare.

în versiunile inițiale ale AD, au existat multe șanse de conflicte. De exemplu, să presupunem că un controler de domeniu a adăugat un nou angajat în baza de date. Deoarece modificarea a fost făcută la anunț, aceasta a fost reflectată în întreaga întreprindere, și asta e bine. Câteva secunde mai târziu, un alt controler de domeniu a dorit să șteargă înregistrările angajaților care nu mai lucrau în întreprindere. Accidental, a șters și acest angajat din anunț.

sistemul de gestionare a conflictelor care exista a urmat apoi Politica “ultimul scriitor câștigă”, astfel încât modificarea făcută de al doilea controler de domeniu a fost valabilă, în timp ce modificarea făcută de primul controler de domeniu a fost eliminată. Aceasta înseamnă că noul angajat nu mai era în sistem și nu putea accesa resursele sistemului, ceea ce, evident, nu este corect.

pentru a preveni astfel de conflicte, a fost introdus un model cu un singur maestru. În acest model, un singur controler de domeniu (DC) ar putea efectua un anumit tip de actualizare. În cazul de mai sus, dacă numai primul DC ar fi responsabil de adăugarea și eliminarea angajaților și al doilea DC ar fi responsabil de securitate, atunci un astfel de conflict nu ar fi avut loc.

cu toate acestea, acest lucru a venit și cu limitări. Ce se întâmplă când primul DC se prăbușește? Nu puteți adăuga sau șterge angajați până când nu revine din nou. O astfel de dependență puternică de un singur controler nu este niciodată bună din punct de vedere operațional.

deci, Microsoft a mers puțin mai departe în versiunile ulterioare pentru a include mai multe roluri pentru fiecare DC și pentru a oferi fiecărui DC capacitatea de a transfera întregul rol către orice alt DC din cadrul aceleiași întreprinderi. Avantajul evident aici este nici un rol este legat de orice DC special, astfel încât atunci când unul se duce în jos, puteți transfera automat acest rol la un alt DC de lucru.

deoarece un astfel de model oferă multă flexibilitate, se numește flexibil single Master Operation (FSMO).

în mod eficient, FSMO este un model multimaster care atribuie roluri și responsabilități clare fiecărui DC și, în același timp, oferind flexibilitatea de a transfera roluri dacă este necesar.

roluri FSMO

FSMO este în general împărțit în cinci roluri și sunt:

• Schema master
• Domain naming master
• rid master
• PDC emulator
• Infrastructure master

dintre acestea, primele două roluri FSMO sunt disponibile la nivel de pădure, în timp ce restul de trei sunt necesare pentru fiecare domeniu.

Extensii la distanță

să ne uităm acum la fiecare rol FSMO în profunzime.

Schema master

Schema master, după cum sugerează și numele, deține o copie de citire-scriere a întregii scheme a anunțului. Dacă vă întrebați ce este o schemă, sunt toate atributele asociate cu un obiect utilizator și includ parola, rolul, desemnarea și ID-ul angajatului, pentru a numi câteva.

deci, dacă doriți să schimbați ID-ul angajatului, va trebui să o faceți în acest DC. În mod implicit, primul controler pe care îl instalați în pădurea dvs. va fi schema master.

Domain naming master

Domain naming master este responsabil pentru verificarea domeniilor, deci există doar unul pentru fiecare pădure. Aceasta înseamnă că, dacă creați un domeniu nou într-o pădure existentă, acest controler se asigură că un astfel de domeniu nu există deja. Dacă maestrul dvs. de denumire a domeniului este dezactivat din orice motiv, nu puteți crea un domeniu nou.

deoarece nu creați domenii des, unele întreprinderi preferă să aibă master schemă și master denumire domeniu în cadrul aceluiași controler.

rid master

de fiecare dată când creați un principiu de securitate, fie că este un cont de utilizator, un cont de grup sau un cont master, doriți să adăugați permisiuni de acces la acesta. Dar nu o puteți face pe baza numelui unui utilizator sau grup, deoarece acest lucru se poate schimba în orice moment.

să presupunem că l-ai avut pe Andy cu un anumit rol și a părăsit compania. Deci, ai închis contul lui Andy și în schimb l-ai adus pe Tim. Acum, va trebui să mergeți și să înlocuiți Andy Cu Tim în listele de acces de securitate ale fiecărei resurse.

acest lucru nu este practic, deoarece consumă mult timp și este predispus la erori.

acesta este motivul pentru care asociați fiecare principiu de securitate cu ceva numit ID de securitate sau SID. În acest fel, chiar dacă Andy se schimbă în Tim, SID va rămâne același, așa că va trebui să faceți o singură schimbare.

acest SID are un model specific pentru a se asigura că fiecare SID din sistem este unic. Începe întotdeauna cu litera” S ” urmată de versiune (începe cu 1) și o valoare de autoritate de identificare. Acesta este urmat de domeniul sau numele computerului local care este comun pentru toate SIDs situate în același domeniu. În cele din urmă, numele de domeniu este urmat de ceea ce se numește un ID relativ sau RID.

în esență, RID este valoarea care asigură unicitatea între diferite obiecte din active directory.

un SID va arăta astfel: S-1-5-32365098609486930-1029. Aici 1029 este RID care face un SID unic în timp ce seria lungă de numere este numele dvs. de domeniu.

dar acest lucru poate duce la conflicte, de asemenea. Să presupunem că creăm două conturi de utilizator în același timp. Acest lucru poate provoca conflicte, deoarece există posibilitatea ca ambele obiecte să aibă același SID.

pentru a evita acest conflict, maestrul RID atribuie blocuri de 500 fiecărui controler de domeniu. În acest fel, DC1 primește RIDs de la 1 la 500, DC2 primește RIDs de la 501 la 1.000 și așa mai departe. Atunci când un controler de domeniu rămâne fără RIDs, acesta contactează rid master și, la rândul său, acest rid master atribuie un alt bloc de 500.

deci, rid master este responsabil pentru procesarea cererilor rid pool de la DCs într-un singur domeniu pentru a se asigura că fiecare SID este unic.

PDC emulator

PDC standuri pentru controler de domeniu primar și vine de la un moment în care a existat doar un singur controler de domeniu, care a avut o copie de citire-scriere a schemei. Controlerele de domeniu rămase au fost o copie de rezervă pentru acest PDC. Deci, dacă doriți să schimbați o parolă, ar trebui să mergeți la PDC.

astăzi, nu mai există PDC-uri. Dar câteva dintre rolurile sale, cum ar fi sincronizarea timpului și gestionarea parolelor, sunt preluate de un controler de domeniu numit PDC emulator.

să ne uităm mai întâi la gestionarea parolelor.

să presupunem că merg la un controler de domeniu și îmi resetez parola pentru că a expirat. Apoi mă conectez la o altă mașină pentru un alt site și, să zicem, contactează un controler de domeniu diferit pentru autentificare. Există șansa ca autentificarea mea să eșueze, deoarece este posibil ca primul controler de domeniu să nu fi replicat schimbarea parolei mele către alte controlere.

un emulator PDC evită aceste confuzii fiind controlerul pentru resetările parolei. Deci, clientul meu va contacta emulatorul PDC atunci când o autentificare nu reușește, pentru a verifica dacă a existat o schimbare a parolei. De asemenea, toate blocările contului din cauza parolelor greșite sunt procesate pe acest emulator PDC.

în afară de gestionarea parolelor, emulatorul PDC sincronizează timpul într-un sistem de întreprindere. Aceasta este o funcționalitate importantă, deoarece autentificarea anunțurilor utilizează un protocol numit kerberos pentru securitate. Sarcina principală a acestui protocol este de a se asigura că pachetele de date nu sunt scoase din rețea sau manipulate în timp ce sunt transmise.

deci, atunci când există o diferență de cinci minute sau mai mult între un ceas de server și sistemul dvs. în timpul procesului de autentificare, kerberos crede că acesta este un atac și nu vă va autentifica.

bine, dar care este rolul unui emulator PDC aici?

Ei bine, sistemul dvs. local își sincronizează timpul cu controlerul de domeniu, iar controlerul de domeniu, la rândul său, își sincronizează timpul cu emulatorul PDC. În acest fel, emulatorul PDC este ceasul principal pentru toate controlerele de domeniu din domeniul dvs.

când acest controler este dezactivat, securitatea dvs. scade cu câteva crestături și face parolele vulnerabile la atacuri.

Infrastructure master

funcționalitatea de bază a unui infrastructure master este de a face referire la toți utilizatorii locali și la referințele dintr-un domeniu. Acest controler înțelege infrastructura generală a domeniului, inclusiv ce obiecte sunt prezente.

este responsabil pentru actualizarea referințelor obiectelor la nivel local și se asigură, de asemenea, că este actualizat în copiile altor domenii. Se ocupă de acest proces de actualizare printr-un identificator unic, eventual un SID.

Infrastructure master este similar cu un alt instrument de anunțuri numit Catalog Global (GC). Acest GC este ca un index care știe unde este totul, în interiorul unui active directory. Infrastructura master, pe de altă parte, este o versiune mai mică a GC, deoarece este restricționată într-un singur domeniu.

acum, de ce este important să știm despre GC aici? Deoarece GC și infrastructure master nu ar trebui să fie plasate în același controler de domeniu. Dacă se întâmplă să faceți asta, comandantul Infrastructurii va înceta să funcționeze pe măsură ce GC primește prioritate.

în general, dacă aveți un singur controler de domeniu, acest lucru nu va conta atât de mult. Dar, dacă aveți o pădure mare cu mai multe controlere de domeniu, prezența atât a GC, cât și a infrastructure master va cauza probleme.

să luăm o situație aici. Avem mai multe domenii care caută un server GC. În interiorul unui domeniu, facem o modificare a calității de membru al grupului, iar comandantul infrastructurii știe despre această schimbare. Dar nu actualizează serverul GC, deoarece schimbarea nu a fost făcută unui grup universal. Aceasta înseamnă că există șansa ca Gc și Master-ul dvs. de infrastructură să nu fie sincronizate și, la rândul său, acest lucru poate provoca probleme de autentificare. De aceea, asigurați-vă că aveți fie un master de infrastructură, fie un GC pentru fiecare domeniu, dar nu ambele.

rezumat

după cum puteți vedea. Rolurile FSMO previn conflictele dintr-un active directory și, în același timp, vă oferă flexibilitatea de a gestiona diferite operațiuni din active directory. Acestea pot fi împărțite în cinci roluri, dintre care primele două sunt pentru întreaga pădure, în timp ce celelalte trei se referă la un anumit domeniu.

ați implementat roluri FSMO în organizația dvs.? Vă rugăm să împărtășiți gândurile cu noi.

sursă foto: Wikimedia