Ce este o schemă Active Directory. Extinderea Schemei Active Directory

Schema include o descriere formală a conținutului și structurii bazei de date Active Directory. În special, conține toate proprietățile obiectelor și clasele acestora. Pentru fiecare clasă de obiecte sunt definite toate proprietățile posibile, parametrii suplimentari, precum și care clasă de obiect este și poate fi un strămoș al clasei curente.

Prin instalarea Active Directory, pe primul controler de domeniu este creată o schemă implicită care descrie obiectele cele mai frecvent utilizate și proprietățile obiectelor. În plus, diagrama oferă o descriere a obiectelor și proprietăților interne ale Active Directory.

Schema este extensibilă, astfel încât administratorul de sistem poate crea noi tipuri de obiecte și proprietățile acestora, adăuga proprietăți noi pentru acele obiecte care există deja. Schema este implementată și stocată cu Active Directory în catalogul global. Este actualizat automat, astfel încât o aplicație special creată să îi poată adăuga în mod independent proprietăți și clase noi.
Extinderea schemei standard nu este ușoară. Schimbarea incorect a schemei poate distruge atât serverul, cât și întregul serviciu de director. Pentru a rezolva această problemă, aveți nevoie de experiența și cunoștințele necesare. Deci, în primul rând, trebuie să cunoașteți regulile de denumire.

Reguli de denumire

Fiecare obiect Active Directory are un nume specific. Pentru a identifica obiectele din Active Directory sunt utilizate diverse scheme de denumire, după cum urmează:

Denumiri compuse (DN);
-denumiri distincte relative (RDN);
-identificatori unici la nivel global (GUID);
-Nume de utilizator primar (UPN).

Fiecare obiect Active Directory are nume compus. Numele este un identificator de obiect și conține suficiente date pentru a localiza obiectul în director. Numele distinctiv include numele domeniului care conține obiectul și calea completă către acesta. De exemplu, numele de utilizator compus Andrew Kushnir din domeniul server.com ar putea arăta astfel:
DC=COM/DC=SERVER/CN=Utilizatori/CK=Andrew Kushnir

Dacă aliasul complet al unui obiect este necunoscut sau modificat, puteți găsi obiectul după proprietățile sale, dintre care una este aliasul relativ (parte a aliasului). În exemplul anterior, aliasul relativ pentru obiectul Andrew Kushnir este CK=Andrew Kushnir, iar obiectul părinte este CN=Usere.

Pe lângă numele distinctiv, fiecare obiect Active Directory are un identificator unic global (GUID), care este un număr de 128 de biți. Identificatorul nu se schimbă nici după ce obiectul a fost mutat sau redenumit. Un identificator unic la nivel global este unic în toate domeniile, inclusiv atunci când un obiect este mutat dintr-un domeniu în altul.
Este cel mai ușor să vă amintiți numele de utilizator principal (UPN). Numele principal constă din numele prescurtat al utilizatorului plus numele DNS al domeniului în care se află obiectul. Formatul pentru numele de utilizator principal este următorul:

Nume de utilizator, caractere sufix de domeniu DNS

De exemplu, numele de utilizator principal este Andrew Kushnir în domeniul serverului. soia ar putea arăta [email protected] Numele principal al unui utilizator este independent de numele său distinctiv, astfel încât obiectul utilizator poate fi mutat sau redenumit fără a fi nevoie să schimbați numele de utilizator al domeniului.

04.07.2011 Brian Desmond

Se întâmplă că administratorii Active Directory (AD) și managerii IT sunt, în general, fericiți de extinderea schemei AD. O mare parte din frică provine din documentația Microsoft Windows 2000, care prezintă extinderea schemei ca o operațiune complexă care necesită o atenție extremă. Cu toate acestea, cu o planificare rezonabilă, extinderea schemei este complet fără riscuri.

Schema AD definește structura datelor stocate în director. AD acceptă nativ multe tipuri de obiecte (cum ar fi utilizatori) și atribute (cum ar fi numele și numele). Dacă schema AD subiacentă nu se potrivește bine cu datele pe care doriți să le stocați în director, o puteți mări cu obiecte și atribute personalizate.

De obicei, schema AD este extinsă din mai multe motive, dintre care cel mai comun în multe organizații este implementarea unei aplicații care necesită extinderea schemei. Un bun exemplu este Microsoft Exchange. Uneori, furnizorii de software solicită extinderea schemei pentru compatibilitate cu aplicațiile lor. Adesea, schema este extinsă pentru aplicații dezvoltate intern sau pentru comoditatea stocării datelor companiei în AD.

Opțiuni de stocare

Când planificați extinderea schemei, în special pentru aplicațiile interne, primul lucru de luat în considerare este dacă datele sunt potrivite pentru stocarea în AD. Este deosebit de convenabil să stocați date relativ statice (se modifică rar) în AD, care sunt utilizate în întreaga companie (replicate peste granițele domeniului) și nu sunt confidențiale (de exemplu, nu este recomandat să stocați datele de naștere, numerele cardului de securitate socială, etc. în AD).

Dacă datele nu îndeplinesc aceste criterii, dar trebuie totuși plasate într-un director LDAP, a doua opțiune este optimă. AD Lightweight Directory Services (AD LDS, anterior ADAM) este o versiune de sine stătătoare a AD care poate funcționa ca un serviciu pe un server, un membru al domeniului (sau un controler de domeniu - DC) și, ca AD, poate procesa interogări direcționate către LDAP. Necesitatea de a localiza controlere de domeniu AD pentru autentificare și suport pentru aplicații nu este o limitare nefericită, ci mai degrabă capacitatea de a controla strict cine poate citi datele și direcția de replicare a datelor prin plasarea instanțelor AD LDS în locații adecvate.

Primitive de stocare

Doi termeni joacă un rol cheie în înțelegerea schemei AD: clasă și atribut. Toate elementele AD, inclusiv schema, sunt definite în termeni de clase și atribute. Clasele sunt tipuri de date care trebuie stocate. De exemplu, un utilizator este o clasă în AD, la fel ca un computer. Atributele sunt proprietăți ale claselor. Clasa de utilizator are un atribut de prenume (givenName) și un atribut de nume de familie (sn). Clasa „calculator” are un atribut „sistem de operare”. Schema AD este definită în termeni de două clase: classSchema pentru clase și attributeSchema pentru atribute.

Într-o analogie tipică a bazei de date, puteți compara clasele cu tabelele dintr-o bază de date și atributele cu coloanele dintr-un tabel. Dar rețineți că structura bazei de date AD Directory Information Tree (DIT) este de fapt destul de diferită.

Când rezolvați problema stocării unui nou tip de date în AD, trebuie să vă gândiți la maparea datelor la clase și atribute. În cele mai obișnuite cazuri, este suficient să adăugați un atribut la o clasă existentă (de exemplu, un utilizator sau un grup). Dacă doriți doar să stocați o nouă bucată de date despre un obiect de tip existent (cum ar fi un utilizator), mai întâi încercați să găsiți atribute potrivite dintre cele disponibile în AD. Schema conține mii de atribute, dintre care majoritatea nu sunt utilizate. Deci, de exemplu, pentru a stoca informații despre adresa poștală a unui utilizator, puteți utiliza atributul physicalDeliveryOfficeName.

Reatribuirea unui atribut altor ținte decât aplicația originală este o abordare nefericită. Imaginați-vă că un atribut a fost reatribuit și apoi este achiziționată o aplicație care folosește atributul în scopul său inițial. Va trebui să faceți o muncă dublă pentru că trebuie să reconfigurați vechea aplicație care folosește atributul și apoi să mutați datele. În general, este întotdeauna mai sigur să adăugați un atribut personalizat.

Dar uneori este posibilă doar o abordare bazată pe clasă. În două cazuri, este mai convenabil să adăugați o nouă clasă la schemă decât să folosiți atribute. Prima este necesitatea de a urmări noul tip de date din director. Dacă, de exemplu, doriți să urmăriți mașinile companiei dvs. în AD, puteți defini o nouă clasă „mașină” în schema dumneavoastră. Un alt caz este maparea unu-la-mulți.

Un exemplu ideal este Microsoft Exchange Server 2010. Fiecare dispozitiv mobil sincronizat cu Exchange folosind ActiveSync este stocat ca o instanță a clasei de obiecte speciale msExchActiveSyncDevice în director. Aceste dispozitive mobile sunt stocate ca obiecte copil ale utilizatorului, proprietarul dispozitivului. Această structură permite ca un număr mare de atribute (pe dispozitiv) să fie mapate la un singur utilizator.

Intrare extensie de schemă

Pentru a pregăti o extensie de schemă, trebuie să colectați un număr de intrări. Numai atunci atributul personalizat sau clasa poate fi implementat în mediul de dezvoltare. Multe intrări trebuie să fie unice la nivel global, așa că este important să faceți pregătirea necesară. Neglijența în acest caz amenință cu consecințe periculoase.

Mai întâi, selectați numele clasei sau al atributului. Cea mai importantă parte a numelui este prefixul. Numele atributelor și claselor din schemă (și din schema cumpărătorului de aplicații terță parte) trebuie să fie unice, așa că adăugarea unui prefix va asigura că nu există conflicte între ID-urile atributelor.

Numele prescurtat al companiei este de obicei folosit ca prefix. De exemplu, folosesc bdcLLC ca prefix pentru atributele companiei noastre Brian Desmond Consulting LLC. Pentru o corporație ABC, puteți utiliza prefixul abcCorp. Asigurați-vă că aveți grijă de unicitatea prefixului, deoarece nu există un registru comun al prefixelor. Dacă compania are un nume tipic sau prescurtat, luați în considerare cum să îl faceți unic.

Odată ce a fost ales un nume, un identificator de obiect (OID) trebuie să fie atribuit atributului sau clasei. OID-urile sunt o componentă opțională care trebuie să fie unică la nivel global. AD (mai general, LDAP) nu este singura entitate care folosește un OID ca identificator, așa că Internet Assigned Numbers Authority (IANA) atribuie arbori OID unici la cererea companiilor. O solicitare pentru un număr de întreprindere privată, care este o parte a arborelui OID unic pentru o companie, este deservită gratuit în aproximativ 10 minute. Trebuie să îl obțineți înainte de a putea începe să creați extensii de schemă personalizate. Puteți solicita un număr de întreprindere privată pe site-ul web www.iana.org/cgi-bin/assignments.pl.

Odată ce aveți un număr de întreprindere privată, puteți crea un număr aproape nelimitat de OID-uri unice și le puteți organiza. Figura arată structura arborelui OID pentru numărul întreprinderii private al companiei noastre. OID-urile sunt construite prin adăugarea de ramuri la un arbore, așa că multe companii încep prin a crea o ramură AD Schema (1.3.6.1.4.1.35686.1 în figură) și apoi construind o ramură de clasă și o ramură de atribut sub ea. Sub fiecare dintre aceste ramuri, OID-urile sunt atribuite fiecărui atribut sau clasă nouă. Figura arată OID-ul (1.3.6.1.4.1.35686.1.2.1) alocat atributului personalizat myCorpImportantAttr. Este foarte important să pregătiți un mecanism intern de urmărire (cum ar fi o foaie de calcul Excel sau o listă SharePoint) pentru a vă asigura că OID-urile sunt unice.

Microsoft oferă un script care poate genera un OID cu o valoare aleatorie, dar nu există nicio garanție că va fi unic. Cel mai bun mod este să solicitați o sucursală unică de la organizația IANA și să o utilizați pentru extensii de schemă. Acest proces este atât de simplu încât nu trebuie să utilizați Scriptul de generare OID al Microsoft.

Restul doi parametri de intrare sunt specifici atributelor și depind de tipul acestora. Atributele legate extrem de utile sunt folosite pentru a stoca legături între obiecte în AD. Acestea sunt stocate ca pointeri în baza de date AD, astfel încât legăturile sunt actualizate în timp util în funcție de locația obiectului în pădure. Două exemple tipice de atribute înrudite sunt apartenența la grup (member și memberOf) și relația manager/angajat (manager/directReports). Conceptele de referințe înainte și înapoi se aplică atributelor conexe. O legătură directă este o parte editabilă a unei relații dintre atribute. De exemplu, în cazul apartenenței la grup, atributul de membru al grupului este o legătură directă; atributul memberOf pentru utilizator este o referință înapoi. La editarea apartenenței la grup, modificările sunt aduse atributului membru (referință înainte) și nu atributului memberOf al obiectului membru (referință înapoi).

Pentru a defini atributele legate în AD, trebuie să definiți două atribute (o legătură directă și o legătură înapoi) și să adăugați un identificator de legătură (linkID) la fiecare dintre aceste atribute. ID-urile de legături trebuie să fie unice într-o pădure și, deoarece alte aplicații care necesită extensie de schemă au nevoie și de ID-uri de legături, acestea trebuie să fie unice la nivel global. În trecut, Microsoft a emis ID-uri de legături către terți, dar începând cu Windows Server 2003, AD a introdus în schimb un pointer special care permite generarea de ID-uri de legături unice atunci când crește o schemă asociată cu o pereche de atribute.

În AD, se presupune că ID-urile linkurilor sunt numere consecutive. În special, atributul de legătură directă este un număr par, iar numărul care îl urmează este atribuit atributului de legătură înapoi. De exemplu, pentru member și memberOf (apartenența la grup), ID-ul link-ului pentru membru este 4, iar ID-ul link-ului pentru memberOf este 5. Dacă schema extinsă trebuie să fie compatibilă cu pădurea Windows 2000, trebuie să definiți ID-uri de link statice în modul descris. În caz contrar, utilizați procesul de generare automată a ID-ului legăturii implementat în Windows Server 2003. Pentru a utiliza procesul de generare automată a ID-ului legăturilor, urmați instrucțiunile de mai jos când definiți o extensie de schemă. În timpul procesului de extensie a schemei, așa cum este descris mai târziu în articol, sunt necesari următorii pași pentru a construi atributele asociate (dacă acestea fac parte din extensie).

Mai întâi, pregătiți o legătură directă folosind ID-ul linkului 1.2.840.113556.1.2.50. Rețineți că, deși această valoare a ID-ului de legătură este un OID, Microsoft își rezervă pur și simplu această valoare OID pentru a crea un ID de legătură automată.

Apoi reîncărcați memoria cache a schemei. După aceea, creați un atribut de legătură înapoi folosind id-ul de legătură al numelui atributului de legătură înainte și reîncărcați memoria cache a schemei.

Al doilea element de atribut unic (și, de asemenea, opțional) este identificatorul MAPI. Identificatorii MAPI sunt o caracteristică a Exchange Server. Dacă nu aveți Exchange sau doriți să afișați atributul în Lista globală de adrese (GAL), puteți sări peste această secțiune. Identificatorii MAPI sunt utilizați pentru a afișa atribute pe una dintre paginile de proprietăți din agenda de adrese, cum ar fi șablonul Detalii generale utilizator (vezi ecranul). De exemplu, dacă doriți să afișați clasificarea angajaților (personal sau lucrător contractual) în lista GAL, atribuiți atributul corespunzător ca identificator MAPI. Odată ce un ID MAPI a fost atribuit unui atribut, puteți utiliza Editorul de șabloane de detalii Exchange pentru a introduce datele atributului într-o vizualizare în GAL din interiorul Office Outlook.

Identificatorii MAPI trebuie să fie unici, la fel ca și OID-urile și linkurile. În trecut, nu era posibil să se genereze identificatori MAPI unici, astfel încât acești identificatori au reprezentat întotdeauna un punct slab la extinderea schemei. Din fericire, Windows Server 2008 a introdus o modalitate de a genera automat ID-uri MAPI unice într-un director pentru a reduce riscul de duplicare a ID-urilor MAPI. Pentru a utiliza această caracteristică, setați valoarea 1.2.840.113556.1.2.49 la atributul de identificare MAPI atunci când creați atributul. AD generează un ID MAPI unic pentru atribut după reîncărcarea memoriei cache a schemei. Rețineți că, deși această valoare este un OID, este rezervată în AD pentru a indica generarea automată a ID-urilor MAPI, similar cu generarea automată a ID-urilor link-urilor descrise mai sus.

Rezuma. Există trei intrări critice de luat în considerare atunci când planificați o extindere a schemei. Primul este numele clasei sau al atributului; al doilea este un prefix unic atribuit tuturor claselor și atributelor; al treilea este OID. Pentru a genera un OID, trebuie să solicitați o sucursală unică a OID de la organizația IANA. Dacă urmează să fie creată o pereche de atribute conectate, este necesară o pereche unică de identificatori de legătură. Dacă doriți să afișați un atribut în lista Exchange GAL, trebuie să utilizați un identificator unic MAPI. Cu atât ID-urile link-urilor, cât și ID-urile MAPI, utilizarea unui proces de generare automată în AD este de preferat decât utilizarea valorilor statice.

Planificarea implementării

Când implementați o extensie de schemă personalizată sau o extensie de schemă cu atribute și clase de furnizor, trebuie să luați pași de planificare preliminară pentru a proteja integritatea pădurii dvs. AD. Primul pas este testarea extensiei schemei.

Când pregătiți o extensie de schemă personalizată, utilizați un mediu de dezvoltare temporar. AD Lightweight Directory Service (AD LDS) este disponibil ca descărcare gratuită pe stațiile de lucru Windows XP și Windows 7. Puteți instanția AD LDS pe stația de lucru, puteți construi extensia schemei într-un sandbox și apoi exportați extensia pentru importare într-un test AD pădure. Schema AD LDS este compatibilă cu AD, astfel încât LDIFDE poate fi utilizat pentru export. Puteți importa extensia de schemă finalizată în pădurea AD de testare și apoi verificați dacă importul a avut succes și că aplicațiile critice nu au fost afectate. Pentru AD, ar trebui să plănuiți să testați dacă importul a avut succes și dacă replicarea a fost corectă într-un mediu de testare.

Dacă doriți să testați o extensie de schemă într-o pădure de testare AD, schema acesteia trebuie să se potrivească cu pădurea de producție. În acest caz, testarea va fi completă. Puteți utiliza instrumentul AD Schema Analyzer (inclus cu AD LDS) pentru a detecta diferențele de schemă între două păduri AD. Articolul TechNet „Exportați, comparați și sincronizați schemele Active Directory” (http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx) descrie cum să importați și să exportați extensiile de schemă și cum să utilizați Instrumentul AD Schema Analyzer. Rețineți că pot exista unele diferențe la compararea schemelor, în funcție de pachetele de servicii și versiunile de Windows, cum ar fi indexarea atributelor și stocarea semnelor de ștergere.

Pentru extensiile de schemă obținute din alte surse (de exemplu, împreună cu o aplicație comercială), trebuie să vă asigurați că modificările asociate acestora nu sunt riscante. Împreună cu toate intrările discutate mai sus, asigurați-vă că acordați atenție unui număr de alte circumstanțe. Mai jos sunt parametrii cheie de verificat:

• furnizat într-un fișier LDIF (fișiere LDIF multiple);
• corectitudinea prefixelor de atribute;
• OID-uri înregistrate;
• identificatori de legături înregistrate/generate automat;
• identificatori MAPI generați automat.

Fișierele LDIF sunt un standard industrial: toate extensiile de schemă trebuie să fie livrate în acest format. Aplicațiilor li se permite să utilizeze un mecanism special de import în loc de LDIFDE pentru extensiile de schemă. Dar dacă extensia este furnizată într-un format diferit, există îndoieli cu privire la corectitudinea acesteia și la fiabilitatea furnizorului. B arată un eșantion LDIF pentru crearea unui atribut în schema AD pentru a stoca informații despre mărimea pantofilor utilizatorului. Trebuie remarcate următoarele caracteristici ale acestui model de extindere a schemei.

• Atributul este prefixat pe baza numelui furnizorului (Brian Desmond Consulting, LLC: bdcllc).
• OID-ul unic pentru atribut este emis utilizând numărul de întreprindere privată înregistrat de furnizor.
• Atributul este indexat (semnalele de căutare: 1) și disponibil în catalogul global (isMemberOfPartialAttributeSet: TRUE).

De asemenea, trebuie să verificați dacă atributul este disponibil în setul de atribute parțiale (PAS) global și că indecșii creați pentru atribut sunt corecti dacă atributul urmează să fie utilizat în filtrele de căutare LDAP. De asemenea, este util să ne asigurăm că datele stocate în atribut sunt acceptabile pentru AD în contextul limitărilor și liniilor directoare discutate mai sus.

Odată ce extensia de schemă a fost testată și este gata să intre în producție, trebuie ales momentul potrivit pentru a face acest lucru. De regulă, se poate face în timpul programului de lucru. Va exista o creștere vizibilă a utilizării procesorului atunci când pornește Schema Wizard și o ușoară creștere a încărcării controlerelor de domeniu care reproduc modificările. Companiile mari pot experimenta o pauză de replicare între controlerele de domeniu timp de patru până la șase ore dacă se adaugă atribute la setul de atribute parțiale PAS. Suspendarile vor fi însoțite de mesaje de eroare care indică probleme cu obiectele, dar, de regulă, pot fi ignorate și vor dispărea de la sine. Dacă controlerele de domeniu au fost suspendate de la replicare pentru o perioadă lungă de timp, ar trebui să începeți depanarea.

Abordare planificată

Extinderea schemei AD este sigură dacă luați măsuri de precauție de bază. Când planificați noi extensii de schemă și când examinați atributele și clasele personalizate de la terți, acordați atenție informațiilor de identificare care sunt unice pentru fiecare clasă sau atribut și asigurați-vă că sunt unice la nivel global.

După verificarea integrității, importați noua extensie într-un mediu de testare reprezentativ și verificați dacă mediul de testare și aplicațiile critice funcționează corect. Puteți importa apoi extensia schemei în mediul dumneavoastră de producție.

Listare. Exemple de înregistrări LDIF

Dn: CN=bdcllcShoeSize,CN=Schema,CN=Configuration,DC=X changetype: adăugați objectClass: top objectClass: attributeSchema cn: sfsuLiveServiceEntitlements attributeID: 1.3.6.1.4.1.35686.100.1.1.1.2.25686.100.1.1.1.25Atribut. showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Stochează mărimea pantofului unui utilizator oMSyntax: 64 searchFlags: 1 lDAPDisplayName: bdcllcShoeSize nume: bdcllcShoeSizeSize schemasIDGUID:Merz64A:TrUeSyntax = TRUEMawt3P:

De la lansarea Active Directory cu Windows 2000, Microsoft a oferit utilizatorilor o definiție de bază a schemei pentru implementarea Active Directory.

Lansarea Active Directory® a marcat, de asemenea, o schimbare a numărului de aplicații scrise și implementate pe Windows®. Înainte de aceasta, aplicațiile precum Microsoft® Exchange 5.5 erau construite cu propria lor structură de directoare. De la apariția Active Directory, multe aplicații (Microsoft și non-Microsoft) au profitat de structura de bază oferită în loc să-și construiască propria schemă de la zero.

Inițial, arhitectura de bază furnizată de Active Directory a fost folosită și apoi extinsă după cum a fost necesar. În Microsoft Exchange 2000, de exemplu, Active Directory a fost folosit pentru a implementa sisteme de mesagerie, definind astfel viitorul arhitecturii de mesagerie Microsoft.

Astăzi, multe aplicații create pentru a funcționa într-un mediu Active Directory se bazează pe schema sa de bază și multe aplicații își definesc, de asemenea, propriile modificări ale schemei, după cum este necesar. Acest lucru, desigur, necesită un circuit extensibil, care va fi discutat în acest articol. Mai mult, deoarece multe aplicații depind de definițiile de bază din Active Directory, stabilitatea continuă a schemei de bază este critică. Deoarece multe aplicații trebuie să funcționeze împreună în același Active Directory, modificările aduse unei aplicații nu trebuie să afecteze alte aplicații.

Ce este o schemă?

Pentru mulți, schema Active Directory este o cutie neagră, iar ideea de a schimba singur schema poate fi intimidantă. Desigur, extinderea schemei Active Directory nu este ceva ce trebuie să faceți în fiecare zi, dar pentru unele aplicații sau afaceri, este exact ceea ce aveți nevoie. Prin urmare, este foarte important să înțelegem esența schemei și compoziția acesteia, deoarece Active Directory este un atu important pentru multe organizații, a cărui eșec, din cauza unei actualizări incorecte, poate avea consecințe grave.

Ca strategie, multe organizații folosesc Active Directory Lightweight Directory Services (ADLDS) în Windows Server® 2008 (sau Active Directory Application Mode (ADAM) în Windows Server 2003) ca alternativă pentru testarea sau implementarea directă a definițiilor de schemă personalizate în loc să extindă Active Directory. Directorul Schemei.

O schemă este o structură de bază care oferă un format pentru un serviciu de directoare. Schema Active Directory definește atributele și clasele de obiecte utilizate în Active Directory Domain Services (ADDS). Schema principală conține definiții pentru multe clase cunoscute (cum ar fi utilizator, computer și unitate organizațională) și atribute (cum ar fi telefonNumber și objectSID). Obiectele din definiția principală a schemei sunt numite obiecte de categoria 1, iar obiectele care sunt adăugate sunt numite obiecte de categoria 2.

Schema Active Directory se află într-un container definit de cn=Schema, cn=Configuration,dc=X, unde X este spațiul de nume al pădurii Active Directory. Rețineți că o pădure Active Directory conține o singură schemă; efectuarea de modificări la definiția schemei într-o pădure afectează toate domeniile din acea pădure. Pe orez. unu arată numărul de clase și atribute adăugate la schema Active Directory în diferite versiuni de Windows Server.

Numărul de clase și atribute

Actualizarea schemei pentru diferite versiuni de Windows Server se face folosind utilitarul Adprep. Când faceți upgrade la Windows Server 2003 R2, versiunea schemei este actualizată la 31, iar când faceți upgrade la Windows Server 2008, este actualizată la 44.

Numărul versiunii poate fi obținut prin verificarea valorii atributului objectVersion la cn=Schema,cn=Configuration,dc=X în Active Directory folosind un instrument precum ADSIEdit. Rețineți că unele aplicații, cum ar fi Exchange Server, System Management Server (SMS) și alte aplicații care depind de Active Directory, pot modifica schema pentru a se potrivi cerințelor aplicației.

Componente de bază

Active Directory constă din două tipuri de obiecte: classSchema (shortly - class) și attributeSchema (shortly - attribute). De obicei, extinderea schemei Active Directory este luată în considerare atunci când o organizație trebuie să stocheze date în anumite atribute care nu sunt disponibile în schema existentă. Un atribut într-o schemă Directory este creat prin specificarea unui obiect attributeSchema în containerul de schemă și apoi definirea proprietăților necesare ale noului obiect.

Pentru o listă de proprietăți ale obiectului attributeSchema și informații despre acestea, consultați go.microsoft.com/fwlink/?LinkId=110445 . După cum puteți vedea, un număr mare de proprietăți pot fi definite pentru obiectele attributeSchema, dintre care unele sunt necesare.

Pe lângă atributele obișnuite, schema conține și atribute speciale numite legate și implementate în perechi prin specificarea legăturilor înainte și înapoi. De exemplu, luați în considerare apartenența la grup în Active Directory. Atributul de apartenență al oricărui grup (de exemplu, grupul ContosoEmployees cu membrul John Doe) este o referință directă, iar atributul corespondent memberOf al obiectului membru este o referință inversă (astfel încât atunci când se interogează atributul memberOf al unui membru al lui John Doe). , se calculează numele distinctiv (DN) al grupului ContosoEmployees).

Link-ul înainte funcționează ca orice alt atribut. Valorile pot fi cu o singură valoare sau cu mai multe valori (la fel ca și atributul de apartenență, care poate conține mai multe obiecte ca membri ai unui grup) și sunt stocate în director împreună cu obiectul părinte.

Backlink-urile, pe de altă parte, sunt menținute de sistem pentru a asigura integritatea datelor. La interogarea valorii atributului backlink, rezultatul este calculat pe baza tuturor valorilor link forward care se potrivesc. Backlink-urile sunt întotdeauna multivalorice.

Toate clasele de obiecte din ADDS sunt definite de obiectul classSchema din containerul de schemă. Pentru o listă cu cele mai importante atribute pentru definirea cu succes a unui obiect classSchema, consultați go.microsoft.com/fwlink/?LinkId=110445 .

Există trei tipuri de clase care pot fi definite: structurale, abstracte și helper. Tipul clasei este determinat de valoarea atributului objectClassCategory. (A patra categorie, cunoscută sub numele de 88, include clase definite înainte de standardele X.500 din 1993. Acest tip de clasă este indicat de valoarea 0 din atributul objectClassCategory. Acest tip nu ar trebui să mai fie definit.)

Obținerea și utilizarea identificatorilor

Identitățile tuturor obiectelor classSchema și attributeSchema dintr-un director sunt determinate de identificatorii de obiect obligatorii (OID), guvernsID pentru obiectele classSchema și attributeID pentru obiectele attributeSchema. Acestea sunt valori numerice unice furnizate de anumite centre pentru identificarea obiectelor. Numerotarea este în conformitate cu definiția protocolului LDAP (RFC 2251). Unii identificatori de obiect din schema Active Directory sunt eliberați de Organizația Internațională pentru Standardizare (ISO) și Microsoft. ID-ul obiectului din director trebuie să fie unic.

ID-ul obiectului este un șir de numere, cum ar fi 1.2.840.113556.1.y.z, așa cum se arată în orez. 2. Deci ID-ul obiectului utilizator classSchema este 1.2.840.113556.1.5.9.

ID obiect utilizator

Atunci când o organizație dorește să extindă schema, asigură unicitatea identificatorului de entitate prin obținerea propriului număr OID rădăcină, care este folosit pentru a crea identificatori unici pentru noile atribute și clase de entități ale organizației. Rădăcina identificatorului de obiect poate fi obținută direct de la autoritatea națională de înregistrare ISO (în SUA, American National Standards Institute (ANSI)).

Procedura și taxele de serviciu pentru obținerea identificatorului rădăcină a obiectului pot fi găsite pe ansi.org. În alte regiuni, vă rugăm să contactați organizația membru ISO corespunzătoare, listată la iso.org/iso/about/iso_members.htm.

Anterior, organizațiile primeau un ID de obiect de la Microsoft trimițând un mesaj de e-mail către [email protected]. Totuși, acest lucru are ca rezultat un răspuns automat care vă solicită să descărcați și să rulați VBScript de la go.microsoft.com/fwlink/?LinkId=110453 .

Identificatorilor de obiect eliberați de Microsoft li se atribuie numere în spațiul numerelor de identificare a obiectului Microsoft: 1.2.840.113556.1.8000.x, unde x este un număr unic atribuit organizației. O organizație poate separa acești identificatori pentru a identifica entitățile. De exemplu, puteți utiliza 1.2.840.113556.1.8000.x.1.y pentru noile obiecte classSchema și 1.2.840.113556.1.8000.x.2.z pentru obiectele attributeSchema (unde x este un număr unic de organizare, iar y și z sunt numere atribuite obiectelor classSchema și, respectiv, attributeSchema definite). De asemenea, este recomandat să utilizați un prefix unic de organizare pentru a distinge între aceste nume de obiecte.

Definirea atributelor înrudite

Valoarea backlink attributeSyntax trebuie să fie 2.5.5.1, care este sintaxa Object (DS-DN). De obicei, atributele backlink sunt adăugate la valoarea mayContain a clasei cu cea mai mare abstractizare. Acest lucru face posibilă citirea atributului backlink de la obiecte din orice clasă, deoarece astfel de atribute nu sunt stocate în obiect, ci sunt calculate pe baza valorilor link-ului direct.

Windows Server 2003 a introdus o caracteristică pe care organizațiile o pot folosi pentru a lega două obiecte într-o schemă: generarea automată de linkID-uri. Această caracteristică generează automat un linkID pentru un nou atribut legat dacă linkID-ul atributului este setat la 1.2.840.113556.1.2.50. Legătura de înapoi corespunzătoare este creată prin setarea linkID la attributeId sau ldapDisplayName al link-ului înainte. Cache-ul schemei trebuie reîncărcat după crearea unei legături înainte și înainte de a crea o legătură înapoi. În caz contrar, nu va fi găsit niciun atribut attributeId sau ldapDisplayName la crearea link-ului înapoi. Cache-ul schemei este reîncărcat la cerere la câteva minute după o modificare a schemei sau când un controler de domeniu este repornit.

Dacă Active Directory rulează la nivelul Windows 2000, trebuie să solicitați linkID-uri de la Microsoft trimițând un e-mail la [email protected]. Răspunsul automat va conține următorul rând: „E-mail-uri trimise către [email protected] vor fi procesate numai dacă sunt legate de înregistrările linkID pentru medii vechi.” (E-mailuri trimise la [email protected], vor fi procesate numai dacă se referă la înregistrarea linkID-urilor pentru medii vechi.). Pentru a face acest lucru, în mesajul de e-mail trebuie incluse următoarele informații: numele companiei, numele persoanei de contact, adresa de e-mail, numărul de telefon, prefixul înregistrat (dacă este necesar), ID-ul obiectului înregistrat (dacă este necesar).

Puteți începe să extindeți schema

Să presupunem că decideți să extindeți schema Active Directory. Soluția ar putea fi oprirea utilizării directorului alternativ implementat cu ADLDS (sau ADAM în Windows Server 2003) după ce ați confirmat că nu va îndeplini cerințele. Următorul pas este definirea noilor obiecte attributeSchema care urmează să fie adăugate la schemă; aceasta definește orice valori necesare (cum ar fi cn, ldapDisplayName etc.) care indică aceste noi obiecte. La definirea valorilor atributelor pentru un obiect, ID-ul obiectului este, de asemenea, obținut de la Microsoft sau o altă sursă. Activitățile de mai sus sunt documentate ca cerințe de afaceri și specificații tehnice. Mai mult, este implementat un mediu experimental de laborator care simulează activitatea Active Directory și este gata de testare.

Multe organizații au înființat comitete ad-hoc pentru a aproba sau a respinge astfel de modificări și pentru a stabili un proces de implementare a acestora. Acest sistem de verificări și echilibrări este esențial deoarece Active Directory este folosit ca o sursă de informații de încredere în multe organizații, iar importanța menținerii acestuia în funcțiune după efectuarea modificărilor nu poate fi subliniată.

Odată ce o organizație decide să continue cu un proiect, trebuie definite planuri de testare și implementare a proiectului. Puteți extinde schema adăugând noi obiecte folosind snap-in-ul Schema Active Directory Microsoft Management Console (MMC) sau folosind metode programatice sau semi-software (de exemplu, folosind LDIFDE pentru a importa fișiere LDIF; folosind CSVDE pentru a importa fișiere CSV; sau folosind scripturi pentru interfețele ADSI).

Indiferent de metoda aleasă, această funcție trebuie efectuată pe un server care are sau este conectat la rolul de master schema FSMO (Flexible Single Master Operations) în pădurea Active Directory. De asemenea, contul utilizat pentru actualizarea schemei are nevoie de drepturi administrative suficiente pentru a efectua actualizarea, deci trebuie inclus în grupul de administratori de schemă. În cele din urmă, actualizările de schemă trebuie să fie activate pentru pădure (dezactivate implicit).

Cu excepția cazului în care modificarea este simplă, aceasta ar trebui făcută automat pentru a asigura standardizarea între fazele de testare și implementare și pentru a preveni erorile care ar putea apărea la efectuarea acțiunilor manuale. Să presupunem că decideți să implementați o modificare folosind instrumentul LDIFDE. Pentru a instala actualizări atunci când extindeți schema, trebuie să adăugați atribute și clase noi, să adăugați atribute noi la clase și apoi să declanșați o reîncărcare a memoriei cache. Mai jos sunt câteva exemple.

Adăugarea de atribute

În scopurile noastre, să presupunem că o organizație numită Contoso trebuie să adauge un atribut la Active Directory care specifică mărimea pantofului pentru toți angajații. Există două domenii într-o pădure Active Directory: contoso.com și employees.contoso.com. Este necesar ca toate obiectele create cu definiția clasei de utilizator să conțină și acest nou atribut.

Este important de reținut că modificarea schemei afectează ambele domenii, deoarece acestea se află în aceeași pădure. Să presupunem că un ID de obiect de 1.2.840.113556.8000.9999 este primit de la Microsoft, care se împarte în 1.2.840.113556.8000.9999.1 pentru obiectul classSchema și 1.2.840.113556.840.113556.99990900.attribute. Acum trebuie să definim toate valorile atributelor pentru acest nou obiect, așa cum se arată în orez. 3.

Definirea atributului contosoEmpShoe

De asemenea, deși atributul contosoEmpShoe ar trebui să fie disponibil pentru toate obiectele create ca obiecte ale clasei de utilizator, nu vă recomandăm să modificați definiția implicită a clasei de utilizator. În schimb, definiți o clasă de ajutor contosoUser cu atributul mayContain setat la contosoEmpShoe, așa cum se arată în orez. 4. Apoi, trebuie să adăugați atributele definite pentru clasa de ajutor contosoUser la clasa de utilizator.

Definiția clasei contosoUser

Acum că analiza este făcută și valorile sunt determinate, trebuie să creați un fișier LDIF care să semene cu codul din orez. cinci. Puteți copia codul în orez. cinci notepad și salvați fișierul ca contosoUser.ldif (inclus în descărcări de la technetmagazine.com).

Fișierul LDIF cu extensie de schemă

#Attribute definition for contosoEmpShoe dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: contosoEmpShoe attributeID: 1.2.840.11.295506.11.2.1959506. isSingleValued: TRUE adminDisplayName: contosoEmpShoe adminDescription: contosoEmpShoe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: contosoEmpShoe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow schemaUpdate,NowClass=UpdateNowClass=Update,Class:UpdateNow =X tipul de modificare: ntdsschemaadd objectClass: top objectClass: classSchema cn: contosoUser guvernsID: 1.2.840.113556.1.8000.9999.1.1 mayContain: contosoEmpShoe rDNAttID: cn adminDisplayName obiect: contosoC contolaser USer nume de sistem contolaser administratorUSE: contosoC contolaser USer nume de sistem contolaser USER: contosoC contsolesUSer nume de sistem contolaser : contosoUser objectClass sistem: contosoUserALSE nume: changetype: modifică adăuga: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=Utilizator,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify a dd: auxiliaryClass auxiliaryClass: contosoUser - dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1

După crearea fișierului LDIF, ar trebui să testați temeinic implementarea într-un mediu de laborator pilot, să validați replicarea end-to-end de domeniu și pădure și să permiteți actualizările schemei în pădure. Acum trebuie să vă conectați cu un cont care are drepturi de administrator de schemă. Poate fi necesar să dezactivați replicarea de ieșire pe schema master (unde vor fi făcute modificări) și să rulați următoarea comandă pentru a importa fișierul LDIF:

Ldifde -i -f \contosoUser.ldif -b -k -j. –c „CN=schemă,CN=Configurație,DC=X” #schemaNamingContext

După efectuarea modificărilor, permiteți replicarea de ieșire pe masterul schemei și verificați dacă replicarea a avut loc pentru toate controlerele de domeniu.

Respirați adânc - ați terminat! Ați definit un nou atribut în schemă care va fi asociat cu obiectele create cu clasa de utilizator (adică conturile de utilizator).

Pentru a testa modificările, deschideți Active Directory Users and Computers, conectați-vă la domeniul employees.contoso.com, selectați unitatea organizațională a utilizatorilor și creați un nou cont de utilizator numit ContosoTestUser. Acum deschideți consola adsiedit.msc și conectați-vă la partiția de domeniu dc=employees,dc=contoso,dc=com, extindeți OU Users, faceți clic dreapta pe ContosoTestUser, apoi deschideți pagina Proprietăți. Căutați atributul contosoEmpShoe. Puteți modifica acest atribut pentru a introduce o valoare. De asemenea, puteți utiliza utilitarul Ldp.exe pentru a verifica și modifica atributele.

Acum, să ne uităm la un exemplu de definire și relaționare a două atribute și să ne imaginăm că Contoso este foarte preocupat de mărimea pantofilor angajaților și trebuie să urmărească performanța anuală a persoanelor care măsoară mărimea pantofilor angajaților companiei. Deși acest lucru poate părea ridicol, să presupunem și că Contoso dorește să țină evidența nu numai a persoanelor responsabile cu măsurarea pantofilor angajaților, ci și a angajaților a căror mărime a fost măsurată și a numărului acestora, toate interogând un singur atribut. (Deși ați putea crede că tabelele de baze de date sunt mai potrivite pentru stocarea acestui tip de date, în acest caz, pur și simplu urmărim scopul de a explica cum funcționează legăturile înainte și înapoi.)

Desigur, vei face mai întâi o analiză similară cu cea pe care am menționat-o în exemplul anterior. Cu toate acestea, deocamdată, să mergem mai departe și să creăm fișiere LDIF (linkids1.ldif și linkids2.ldif) așa cum se arată în orez. 6. Apoi rulați următoarea comandă pentru a importa fișierele LDIF:

Legați înainte și înapoi fișierele LDIF

#linkids1.ldif #Definiție atribut pentru Forward Link Attribute dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeShoeSizeTaker attributeID:8901121.890. 2 linkid: 1.2.840.113556.1.2.50 Atributesyntax: 2.5.5.1 Issimaled: ContososiZetaker Admindescription: ContoSosiZetaker Omsyntax: 64 SearchFlags: 1 LDAPDisplayName: Contososhoesizeker Systemonly #Roacadupdate: Schemanow Addtype Modificați DN: Changtype Schema # Linkids2.ldif #Attribute definiție pentru atributul de legătură înapoi dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeShoeSizesTakenByMe attributeID: 8.40.1.125.8.1.9.0.125.8.1.9.0.1.0.9.0.9.0.9 .8000.9999.2.2 attributeSyntax: 2.5.5.1 isSingleValued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe adminDescript ion: ContosoShoeSizesTakenByMe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add ContosoSizesTakenByMe changer ntdsschemamodify add: mayContain mayContain: ContosoShoeSizeTaker mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribute as MayContain in Top dn: CN=Top,CNX change:Schema,DC=CNX=Configuration ntdsschemamodify add: mayContain mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 ldifde –i –f \linkedids.ldif –b -k –j. –c „CN=schemă,CN=Configurație,DC=X” #schemaNamingContext

Acum, când este creat un obiect utilizator, acesta va avea și atributele ContosoShoeSizeTaker și ContosoShoeSizesTakenByMe. Când este creat un obiect utilizator, de exemplu, pentru John, atributul ContosoShoeSizeTaker este populat cu numele distinctiv al persoanei care a măsurat mărimea pantofului, Frank. Dacă acum accesăm proprietățile obiectului utilizator al lui Frank și interogăm atributul ContosoShoeSizesTakenByMe, rezultatul va conține numele distinctiv al lui Frank și al celorlalte persoane ale căror mărime de pantofi le-a măsurat Frank. Pentru a finaliza cazul nostru, conducerea poate recompensa Frank pe baza numărului de nume distincte care există în atributul ContosoShoeSizesTakenByMe al contului său de utilizator.

Sistem de control și echilibru

O actualizare critică, cum ar fi o schimbare de schemă, nu poate fi efectuată fără verificarea conformității arhitecturale. Aceste verificări de securitate și coerență sunt utilizate de Active Directory pentru a verifica dacă modificările nu cauzează inconsecvențe sau alte probleme atunci când Active Directory este extins sau schimbată schema.

În primul rând, valoarea guvernsID pentru fiecare clasă trebuie să fie unică în schemă. Când definiți un obiect schemaClass, toate atributele definite în listele systemMayContain, mayContain, systemMustContain și mustContain trebuie să existe deja. În același timp, toate clasele definite în listele subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors și possSuperiors trebuie să existe deja.

În plus, atributul objectClassCategory al tuturor claselor din listele systemAuxiliaryClass și auxiliaryClass trebuie să fie clasa 88 sau o clasă auxiliară. În mod similar, atributul objectClassCategory al tuturor claselor din listele systemPossSuperiors și possSuperiors trebuie definit ca clasa 88 sau o clasă structurală.

Când se definesc clase diferite, clasele abstracte pot fi derivate numai din alte clase abstracte, clasele auxiliare nu pot fi derivate din clase structurale, iar clasele structurale nu pot fi derivate din clase auxiliare. În plus, atributul specificat în rDNAttID trebuie să fie clar și trebuie să aibă sintaxă ca șir unicode.

Acestea sunt câteva dintre regulile legate de obiectele classSchema. Dar regulile pentru obiectele attributeSchema? La fel ca valoarea guvernsID pentru clase, valoarea attributeID trebuie să fie unică. În plus, valoarea mAPIID (dacă există) trebuie să fie, de asemenea, unică. În plus, dacă rangeLower și rangeUpper sunt prezente, rangeLower trebuie să fie mai mic decât rangeUpper. Valorile attributeSyntax și oMSyntax trebuie să se potrivească. Dacă sintaxa atributului este obiect (oMSyntax =127), acesta trebuie să aibă o oMObjectClass validă. LinkID, dacă există, trebuie să fie unic. De asemenea, o legătură înapoi trebuie să aibă o legătură directă corespunzătoare.

Ce se întâmplă dacă apare o eroare?

Odată ce schema a fost extinsă și noi obiecte (clase și atribute) adăugate la ea, acestea nu pot fi eliminate. Cu toate acestea, clasele și atributele pot fi dezactivate prin setarea atributului isDefunct al obiectului schemă la TRUE. Nu puteți dezactiva obiectele de schemă care fac parte din schema implicită care vine cu Active Directory (obiecte din categoria 1). Puteți dezactiva numai obiectele adăugate la schema implicită, de exemplu. obiecte de categoria 2 și numai după verificarea faptului că clasa nu este utilizată în listele subClassOf, auxiliaryClass sau possSuperiors ale oricărei clase de actori existente.

Când încearcă să dezactiveze orice atribut, Active Directory verifică dacă este utilizat în listele mustContain și mayContain ale oricărei clase efective existente. Obiectele dezactivate pot fi reactivate setând atributul isDefunct la FALSE. Dacă Active Directory rulează la nivelul Windows Server 2003, puteți reutiliza valorile ldapDisplayName, schemaIdGuid, OID și mapiID ale obiectelor dezactivate.

Concluzie.

Când adăugați sau modificați definițiile de clasă sau atribut în schemă, adăugați sau modificați și obiectul classSchema sau attributeSchema corespunzător. Acest proces este similar cu adăugarea sau modificarea oricărui obiect din Active Directory, cu excepția faptului că se fac verificări suplimentare pentru a se asigura că modificările nu cauzează inconsecvențe și nu pot cauza probleme în schemă în viitor.

Deși modificarea schemei Active Directory nu este un proces dificil, este important să înțelegeți structura schemei și procesul de implementare a acestor modificări. Toate modificările aduse schemei Active Directory trebuie planificate cu atenție și executate cu mare grijă. Este important să se definească cerințele de afaceri și specificațiile tehnice pentru noile facilități și să se efectueze teste ample. Deoarece modificările pot avea un efect semnificativ, vă recomandăm să extindeți schema Active Directory numai atunci când este absolut necesar.

Este dificil de subestimat importanța „Schemei Active Directory” pentru rețelele construite pe baza unui mediu de domeniu Active Directory. Aceasta este baza tehnologiei „AD” și este foarte important să înțelegem corect principiile funcționării acesteia. Majoritatea administratorilor de sistem nu acordă suficientă atenție schemei, deoarece este rar tratată. În acest articol vă voi spune ce este o versiune de schemă, de ce trebuie să o știm și, cel mai important, cum să vizualizați versiunea curentă.

În primul rând, câteva cuvinte despre schema în sine, fiecare obiect creat în Active Directory, fie el un utilizator sau un computer, are anumiți parametri numiți atribute. Cel mai simplu exemplu este atributul „Nume” al obiectului utilizator. Schema definește ce obiecte putem crea în Active Directory și ce atribute vor avea.

Active Directory permite utilizarea în cadrul unei organizații a mai multor controlere de domeniu construite pe baza diferitelor versiuni de Windows. Și anume, bazat pe Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Deoarece aceste versiuni au fost lansate în ani diferiți și fiecare versiune nouă are mai multe funcționalități decât cea anterioară, fiecare sistem de operare are propria înțelegere a schema. Prin urmare, atunci când adăugați un nou controler bazat pe Windows Server 2008 la o organizație în care controlerele existente sunt construite pe Windows Server 2003, a trebuit să rulați " Adprep". Făcând acest lucru, v-ați actualizat organigrama la nivelul cu care funcționează Windows Server 2008.

Procesul de actualizare a schemei a fost efectuat înainte de instalarea primului controler Windows Server 2008 și este posibil ca procedura reală de instalare a unui nou controler în sine să nu fi fost efectuată. Dacă abia începi să lucrezi cu o organizație Active Directory și nu știi ce activități au fost desfășurate înainte de a te alătura, va trebui să știi la ce nivel funcționează Schema de organizare curentă pentru a înțelege completitatea structurii.

Versiuni posibile de schema:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 cu Service Pack 1, Windows 2003 cu Service Pack 2
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

Chiar dacă toate controlerele din organizația dvs. rulează Windows Server 2003 R2 și versiunea schemei arată „44”, nu fiți surprinși, acest lucru indică faptul că schema a fost deja actualizată la nivelul Windows Server 2008 RTM, dar controlerul însuși din anumite motive nu a fost instalat.

Puteți vizualiza versiunea schemei în mai multe moduri, cel mai simplu mod este folosirea utilitarului DSQuery. Pentru a face acest lucru, la linia de comandă, introduceți comanda cu următorii parametri:

„dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

Desigur, în dc=numedomeniu,dc=local" trebuie să înlocuiți propriul nume de domeniu. (Exemplu: dc=microsoft,dc=com )

Rezultatul introducerii comenzii este primirea atributului " ObjectVersion”, care va fi numărul versiunii schemei:

Orez. unu Obținerea versiunii schemei prin utilitarul DSQuery.

A doua metodă este mai lungă și implică utilizarea „ ADSIEdit.msc". Pentru a vizualiza versiunea schemei, va trebui să vă conectați la partiția de schemă Active Directory.

"CN=Schema,CN=Configurare,DC=domeniu,DC=local"

Și găsiți valoarea atributului " objectVersion".

Fig.2 Obținerea versiunii Schema prin intermediul snap-in-ului ADSIEdit.msc».

Cunoscând versiunea schemei, puteți spune oricând cu certitudine dacă schema trebuie actualizată și, dacă da, la ce nivel.

Trebuie remarcat faptul că actualizările de schemă pot fi efectuate prin software care este strâns integrat cu Active Directory. Cel mai frapant exemplu este Microsoft Exchange Server. Și adesea, într-o organizație care planifică să implementeze Exchange Server, trebuie să aflați dacă schema a fost pregătită? Și dacă a fost, atunci ce versiune de Exchange Server. În prezent, există trei versiuni de Exchange care funcționează cu Active Directory, dar există șase opțiuni pentru modificarea schemei. Puteți înțelege dacă Schema Exchange Active Directory a fost modificată de server prin atributul " rangeUpper, care ia urmatoarele valori:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 cu Service Pack 3
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 cu Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 cu Service Pack 1

După cum puteți vedea, actualizările de schemă apar și atunci când instalați SP3 pentru Exchange Server 2000/2003 și SP1 pentru Exchange 2007.

Vedeți valoarea atributului " rangeUpper" Puteți utiliza utilitarul DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr rangeUpper"

Orez. 3 Obținerea atributului " rangeUpper" prin utilitarul DSQuery.

Dacă, după introducerea acestei comenzi, este returnat un răspuns care indică absența atributului " rangeUpper" se poate concluziona că schema nu a fost modificată.

Procesul de actualizare a schemei este un pas foarte important pentru fiecare organizație Active Directory, așa că trebuie evitate acțiunile inutile, inutile. Înțelegerea esenței atributelor " objectVersion” și« rangeUpper" oferă unui specialist un avantaj atunci când lucrează cu Active Directory într-o organizație necunoscută și este, de asemenea, un instrument auxiliar pentru rezolvarea problemelor.

Material furnizat de resursă

O schemă în AD DS este un set de definiții pentru toate tipurile de obiecte și atributele asociate acestora dintr-un catalog. Este schema care definește modul în care AD DS trebuie să stocheze și să configureze datele despre toți utilizatorii, computerele și alte obiecte, astfel încât acestea să aibă un aspect standard în întreaga structură AD DS. Este protejat prin utilizarea listelor de control al accesului discreționar (DACL) și este responsabil pentru furnizarea de atribute posibile pentru fiecare obiect din AD DS. În esență, schema este definiția de bază a directorului în sine și este fundamentul funcționalității mediului de domeniu. Trebuie avută mare grijă atunci când delegați gestionarea schemei unui grup selectat de administratori, deoarece modificările aduse schemei afectează întregul mediu AD DS.

Obiecte Schema

Elementele stocate în structura AD DS, cum ar fi utilizatori, imprimante, computere și site-uri, sunt denumite obiecte în cadrul schemei. Fiecare astfel de obiect are propria sa listă de atribute care îi definesc caracteristicile și poate fi folosit pentru a-l căuta.

Extensie de schemă

Unul dintre principalele avantaje ale designului AD DS este capacitatea de a modifica și extinde direct schema pentru a include atribute personalizate. De obicei, extinderea setului de atribute are loc în timpul instalării Microsoft Exchange Server, când schema este extinsă până la aproape dublu în dimensiune. Când faceți upgrade de la Windows Server 2003 sau Windows Server 2008 AD la Windows Server 2008 R2 AD DS, schema este extinsă și pentru a include atribute specifice Windows Server 2008 R2. Multe produse terțe oferă, de asemenea, extensii de schemă proprii, care le permit să-și afișeze propriile tipuri de informații de catalog.