Versiunea Schema Active Directory. Ce este Schema Active Directory

O schemă în AD DS este un set de definiții pentru toate tipurile de obiecte și atributele asociate acestora într-un director. Schema definește modul în care AD DS trebuie să stocheze și să configureze datele despre toți utilizatorii, computerele și alte obiecte pentru ca aceștia să aibă vedere 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 baza pentru funcționalitatea mediului de domeniu. Trebuie folosită precauție extremă atunci când delegați drepturi de gestionare a schemei unui grup selectat de administratori, deoarece modificările aduse schemei afectează întregul mediu AD DS.

Obiecte schema

Elementele care sunt stocate în structura AD DS, cum ar fi utilizatori, imprimante, computere și site-uri, sunt numite 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 direct și de a extinde schema pentru a include atribute speciale. De obicei, extinderea setului de atribute are loc în timpul instalării sistemului. Microsoft Exchange Server, în care schema este extinsă, astfel încât aproape să se dubleze în dimensiune. Când efectuați o actualizare de la Windows Server 2003 sau Windows Server 2008 AD la Windows Server 2008 R2 AD DS, schema este, de asemenea, extinsă, în urma căreia i se adaugă atribute specifice Windows Server 2008 R2. Multe produse terțe oferă, de asemenea, propriile extensii de schemă care le permit să-și afișeze propriile tipuri de informații de catalog.

Diagrama include o descriere formală a conținutului și structurii bazei de date Date active Director. În special, indică toate proprietățile obiectelor și clasele acestora. Pentru fiecare clasă de obiecte, sunt definite toate proprietățile posibile, Opțiuni suplimentare, precum și ce clasă de obiecte este și poate fi un strămoș al clasei curente.

Instalare Director activ , pe primul controler de domeniu este creată o schemă standard care conține o descriere a obiectelor și proprietăților obiectelor cele mai frecvent utilizate. Î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 și poate adăuga noi proprietăți 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 perturba funcționarea atât a serverului, cât și a întregului serviciu de director. Pentru a rezolva această problemă aveți nevoie de experiența și cunoștințele necesare. Deci, mai întâi de toate, trebuie să cunoașteți regulile de denumire.

Reguli de denumire

Fiecare Obiect activ Directorul are un nume specific. Pentru a identifica obiectele din Active Directory, acestea sunt folosite diverse scheme denumire, și anume:

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

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

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

Cu excepția numelui calificat, fiecare obiect Active Directory are un identificator unic global (GUID), care este un număr de 128 de biți. ID-ul nu se schimbă nici după ce obiectul este mutat sau redenumit. Un identificator unic la nivel global este unic în toate domeniile, inclusiv atunci când un obiect se mută de la un domeniu la altul.
Cel mai simplu mod de a vă aminti este numele principal al utilizatorului (UPN). Numele principal constă din numele prescurtat al utilizatorului plus numele DNS al domeniului în care se află obiectul. Formatul numelui de utilizator principal este următorul:

Nume de utilizator, caracter de 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 final, astfel încât un obiect utilizator poate fi mutat sau redenumit fără a fi nevoie să se schimbe numele de conectare al domeniului utilizatorului.

După cum știți, nimic nu durează pentru totdeauna, totul se schimbă, mai ales într-o industrie precum IT. Odată implementată, infrastructura evoluează, se extinde, se îmbunătățește în mod constant și vine un moment în care trebuie să adăugați un controler de domeniu gestionat de mai multe persoane la Active Directory. versiune ulterioară sistem de operare.

S-ar părea - care este problema? Dar, după cum arată practica, problemele apar în mare parte datorită faptului că administratorii de sistem au puțină stăpânire a teoriei și sunt în mod deschis confuzi în această problemă. Prin urmare, este timpul să ne dăm seama ce este Schema ADși cum se raportează la cazul nostru.

Circuitul AD se numește o descriere a tuturor obiectelor director și a atributelor acestora. În esență, schema reflectă structura de bază a directorului și are o importanță capitală pentru buna funcționare a acestuia.

Noile versiuni ale sistemului de operare conțin noi obiecte și atribute, așa că pentru ca acestea să funcționeze corect ca controlori de domeniu, va trebui să actualizăm schema.

Pare clar, dar nu în totalitate, așa că să trecem la greșelile și concepțiile greșite comune.

• Actualizarea schemei este necesară pentru a include computerele care rulează versiuni mai noi de Windows în domeniu. Acest lucru nu este adevărat, chiar și cel mai mult ultimele versiuni Windows poate rula cu succes într-un domeniu Windows 2000 fără a actualiza schema. Deși, dacă actualizați schema, nu se va întâmpla nimic rău.

• Pentru a include un controler care rulează un sistem de operare mai nou într-un domeniu, trebuie să actualizați domeniul (pădurea). Acest lucru nu este, de asemenea, adevărat, dar spre deosebire de cazul precedent, această operațiune va face imposibilă utilizarea controlerelor de domeniu care rulează un sistem de operare mai mic decât modul său de operare. Prin urmare, în cazul unei erori, va trebui să restabiliți structura AD dintr-o copie de rezervă.

Vă vom atrage atenția și asupra modului de funcționare al pădurii și domeniului. Domeniile incluse în pădure pot avea diverse moduri lucru, de exemplu, unul dintre domenii poate funcționa modul Windows 2008, iar restul în modul Windows 2003 Schema de operare forestieră nu poate fi mai mare decât schema de operare a celui mai vechi domeniu. În exemplul nostru, modul de operare forestier nu poate fi mai mare decât Windows 2003.

În același timp, modul de funcționare inferior al pădurii nu împiedică în niciun fel folosirea mai multor modul înalt lucrează în domeniu, tot ce este necesar este actualizarea schemei.

După ce ne-am familiarizat cu teoria, să trecem la un exemplu practic. Să presupunem că avem un domeniu de nivel Windows 2000 (mod mixt) - cel mai mult nivel scăzut AD - care are un controler sub Control Windows 2003, iar scopul nostru este să creăm un nou controler care să îl înlocuiască pe cel defect.

Noul server rulează Windows 2008 R2. Vă rugăm să rețineți că nu am avut dificultăți la activare a acestui server la un domeniu existent.

Cu toate acestea, când încercăm să adăugăm un nou controler de domeniu, vom primi o eroare:

Pentru a porni cu succes un controler sub controlul a mai mult de versiune noua OS va trebui să actualizăm schema pădurii și schema domeniului. Excepția este Windows Server 2012, care va actualiza schema de la sine la adăugarea unui nou controler de domeniu.

Pentru a actualiza schema, utilizați utilitarul Adprep, care se află în folder \support\adprep asupra instalatiei disc Windows Server. Începând cu Windows Server 2008 R2, acest utilitar este implicit pe 64 de biți, dacă trebuie să utilizați versiunea pe 32 de biți, ar trebui să îl rulați adprep32.exe.

Pentru a efectua o actualizare a schemei de pădure această utilitate ar trebui lansat pe Proprietarul schemei, și pentru a actualiza schema de domeniu la Proprietarul infrastructurii. Pentru a afla ce controlere au rolurile FSMO de care avem nevoie, utilizați comanda:

Interogare Netdom FSMO

În Windows 2008 și mai nou, acest utilitar este instalat implicit, iar în Windows 2003 trebuie instalat de pe discul din director \support\instrumente

Rezultatul acestei comenzi va avea ca rezultat o listă a tuturor rolurilor și controlorilor FSMO care au următoarele roluri:

În cazul nostru, toate rolurile sunt pe același controler, așa că copiem folderul \support\adprep pe HDD(în cazul nostru la rădăcina unității C:) și treceți la actualizarea schemei pădurii. Pentru a finaliza cu succes operațiunea, contul dumneavoastră trebuie să fie inclus în următoarele grupuri:

• Administratori de schemă
• Administratorii întreprinderii
• Administratorii domeniului în care se află proprietarul schemei

Pentru a actualiza schema pădurii, executați comanda:

C:\adprep\adprep /forestprep

Citiți avertismentul standard și continuați făcând clic C, apoi introduce.

Procesul de actualizare a schemei va începe. După cum puteți vedea, versiunea sa se va schimba de la 30 (Windows 2003) la 47 (Windows 2008 R2).

După actualizarea schemei pădurii, trebuie să actualizați schema domeniului. Înainte de a face acest lucru, ar trebui să vă asigurați că domeniul rulează cel puțin în modul Windows 2000 (mod nativ). După cum ne amintim, domeniul nostru funcționează în modul mixt, așa că ar trebui să schimbăm modul de operare al domeniului în principal sau să îl facem upgrade la Windows 2003. Deoarece în acest domeniu nu avem controlere care rulează Windows 2000, ar fi cel mai rezonabil să facem upgrade domeniului. modul.

Pentru a actualiza cu succes schema de domeniu, această operație ar trebui efectuată pe Proprietarul infrastructurii si au drepturi Administrator de domeniu. Executăm comanda:

C:\adprep\adprep /domainprep

Și citiți cu atenție informațiile afișate. Când actualizați o schemă de domeniu din Windows 2000 sau Windows 2003, trebuie să modificați permisiunile Sistemul de fișiere Pentru politici de grup. Această operațiune este efectuată o dată și în viitor, de exemplu, actualizarea schemei de la nivelul 2008 la 2008 R2, trebuie efectuată. Pentru a actualiza permisiunile GPO, introduceți comanda:

C:\adprep\adprep /domainprep /gpprep

În AD au apărut versiuni începând de la Windows 2008 tip nou Controlere de domeniu: Controller de domeniu numai pentru citire (RODC), dacă intenționați să implementați un astfel de controler, atunci trebuie să pregătiți o schemă. În general, vă recomandăm să faceți această operațiune indiferent dacă veți instala RODC în viitorul apropiat sau nu.

Această operațiune poate fi efectuată pe orice controler de domeniu, dar trebuie să fiți membru al Administratorii întreprinderiiȘi Maestru al numiriiȘi Maestru de infrastructură trebuie sa fie disponibil.

C:\adprep\adprep /rodcprep

După cum puteți vedea, actualizarea schemei de domeniu, dacă este planificată corespunzător, nu provoacă dificultăți, totuși, în orice caz, ar trebui să vă amintiți că aceasta este o operațiune ireversibilă și să aveți la îndemână copiile de rezervă necesare.
Sursa http://interface31.ru/tech_it/2013/05/obnovlenie-shemy-active-directory.html

După cum știți, nimic nu durează pentru totdeauna, totul se schimbă, mai ales într-o industrie precum IT. Odată implementată, infrastructura evoluează, se extinde, se îmbunătățește în mod constant și vine un moment în care trebuie să adăugați un controler de domeniu care rulează o versiune ulterioară a sistemului de operare la Active Directory.

S-ar părea - care este problema? Dar, după cum arată practica, problemele apar în mare parte din cauza faptului că administratorii de sistem au puține cunoștințe despre teorie și sunt sincer confuzi în această chestiune. Prin urmare, este timpul să ne dăm seama ce este Schema ADși cum se raportează la cazul nostru.

Circuitul AD se numește o descriere a tuturor obiectelor director și a atributelor acestora. În esență, schema reflectă structura de bază a directorului și are o importanță capitală pentru buna funcționare a acestuia.

Noile versiuni ale sistemului de operare conțin noi obiecte și atribute, așa că pentru ca acestea să funcționeze corect ca controlori de domeniu, va trebui să actualizăm schema.

Pare clar, dar nu în totalitate, așa că să trecem la greșelile și concepțiile greșite comune.

• Actualizarea schemei este necesară pentru a include computerele care rulează versiuni mai noi de Windows în domeniu. Acest lucru nu este adevărat, chiar și cele mai recente versiuni de Windows pot rula cu succes într-un domeniu Windows 2000 fără o actualizare a schemei. Deși, dacă actualizați schema, nu se va întâmpla nimic rău.

• Pentru a include un controler care rulează un sistem de operare mai nou într-un domeniu, trebuie să actualizați domeniul (pădurea). Acest lucru nu este, de asemenea, adevărat, dar spre deosebire de cazul precedent, această operațiune va face imposibilă utilizarea controlerelor de domeniu care rulează un sistem de operare mai mic decât modul său de operare. Prin urmare, în cazul unei erori, va trebui să restabiliți structura AD dintr-o copie de rezervă.

Vă vom atrage atenția și asupra modului de funcționare al pădurii și domeniului. Domeniile incluse într-o pădure pot avea moduri de operare diferite, de exemplu, unul dintre domenii poate funcționa în modul Windows 2008, iar restul în modul Windows 2003 Schema de funcționare a pădurii nu poate fi mai mare decât schema de funcționare a celui mai vechi domeniu. În exemplul nostru, modul de operare forestier nu poate fi mai mare decât Windows 2003.

În același timp, modul de funcționare inferior al pădurii nu împiedică în niciun fel utilizarea unui mod de funcționare superior în domeniu, tot ce este necesar pentru aceasta este actualizarea schemei;

După ce ne-am familiarizat cu teoria, să trecem la un exemplu practic. Să presupunem că avem un domeniu de nivel Windows 2000 (mod mixt) - cel mai scăzut nivel AD - în care există un controler care rulează Windows 2003, iar scopul nostru este să creăm un nou controler care să îl înlocuiască pe cel defect.

Noul server rulează Windows 2008 R2. Vă rugăm să rețineți că nu am avut dificultăți în încorporarea acestui server într-un domeniu existent.

În cazul nostru, toate rolurile sunt pe același controler, așa că copiem folderul \support\adprep pe hard disk (în cazul nostru, la rădăcina unității C:) și treceți la actualizarea schemei de pădure. Pentru a finaliza cu succes operațiunea, contul dumneavoastră trebuie să fie inclus în următoarele grupuri:

• Administratori de schemă
• Administratorii întreprinderii
• Administratorii domeniului în care se află proprietarul schemei

Pentru a actualiza schema pădurii, executați comanda:

C:\adprep\adprep /forestprep

Citiți avertismentul standard și continuați făcând clic C, apoi introduce.

Procesul de actualizare a schemei va începe. După cum puteți vedea, versiunea sa se va schimba de la 30 (Windows 2003) la 47 (Windows 2008 R2).

După actualizarea schemei pădurii, trebuie să actualizați schema domeniului. Înainte de a face acest lucru, ar trebui să vă asigurați că domeniul rulează cel puțin în modul Windows 2000 (mod nativ). După cum ne amintim, domeniul nostru funcționează în modul mixt, așa că ar trebui să schimbăm modul de operare al domeniului în principal sau să îl facem upgrade la Windows 2003. Deoarece în acest domeniu nu avem controlere care rulează Windows 2000, ar fi cel mai rezonabil să facem upgrade domeniului. modul.

Pentru a actualiza cu succes schema de domeniu, această operație ar trebui efectuată pe Proprietarul infrastructurii si au drepturi Administrator de domeniu. Executăm comanda:

C:\adprep\adprep /domainprep

Și citiți cu atenție informațiile afișate. Când actualizați o schemă de domeniu din Windows 2000 sau Windows 2003, trebuie să modificați permisiunile sistemului de fișiere pentru politicile de grup. Această operațiune este efectuată o dată și în viitor, de exemplu, actualizarea schemei de la nivelul 2008 la 2008 R2, trebuie efectuată. Pentru a actualiza permisiunile GPO, introduceți comanda:

C:\adprep\adprep /domainprep /gpprep

Versiunile AD de la Windows 2008 au introdus un nou tip de controler de domeniu: un controler de domeniu doar pentru citire (RODC), dacă intenționați să implementați un astfel de controler, atunci trebuie să pregătiți o diagramă. În general, vă recomandăm să efectuați această operațiune indiferent dacă intenționați să instalați RODC în viitorul apropiat sau nu.

Această operațiune poate fi efectuată pe orice controler de domeniu, dar trebuie să fiți membru al Administratorii întreprinderiiȘi Maestru al numiriiȘi Maestru de infrastructură trebuie sa fie disponibil.

C:\adprep\adprep /rodcprep

După cum puteți vedea, actualizarea schemei de domeniu, dacă este planificată corespunzător, nu provoacă dificultăți, totuși, în orice caz, ar trebui să vă amintiți că aceasta este o operațiune ireversibilă și să aveți la îndemână copiile de rezervă necesare.

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

Lansarea Active Directory® a marcat, de asemenea, o schimbare în modul în care multe aplicații au fost scrise și implementate pe Windows®. Anterior, aplicațiile precum Microsoft® Exchange 5.5 erau construite cu propria lor structură de directoare. De la introducerea Active Directory, multe aplicații (de la Microsoft și alte companii) au început să profite de structura de bază oferită, mai degrabă decât să-și creeze propria schemă de la zero.

Inițial, a fost folosită arhitectura de bază oferită de Active Directory, care a fost apoi extinsă după caz. Microsoft Exchange 2000, de exemplu, a folosit Active Directory pentru a implementa sisteme de mesagerie, definind astfel viitorul arhitecturii de mesagerie Microsoft.

Astăzi, multe aplicații create pentru a rula într-un mediu Active Directory se bazează pe schema de bază și multe aplicații își definesc, de asemenea, propriile modificări de schemă pentru a face modificările necesare. Pentru a face acest lucru, desigur, aveți nevoie de un circuit care poate fi extins, despre care va fi discutat în acest articol. În plus, deoarece multe aplicații depind de definiții de bazăîn Active Directory, stabilitatea continuă a schemei de bază este extrem de importantă. Deoarece multe aplicații trebuie să funcționeze împreună în același Active Directory, modificările aduse unei aplicații nu ar trebui să afecteze alte aplicații.

Ce este o schemă?

Pentru mulți oameni, schema Active Directory este un pic o cutie neagră, iar ideea de a schimba schema în sine poate fi descurajantă. Desigur, expansiune Scheme active Directorul nu trebuie făcut în fiecare zi, dar unele aplicații sau companii o cer. Prin urmare, este foarte important să înțelegem natura 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 testare sau implementare directă definiții personalizate schema în loc să extindă schema Active Directory.

Schema este structură de bază, care oferă un format pentru serviciul de directoare. Schema Active Directory definește atributele și clasele de obiecte utilizate în servicii de domeniu Active Directory (ADDS). Schema de bază conține definiții pentru multe clase binecunoscute (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 calea 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 modificărilor unei definiții de schemă într-o pădure afectează toate domeniile din acea pădure. Pe orez. 1 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 versiuni diferite Windows Server este implementat 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.

Puteți găsi numărul versiunii verificând valoarea atributului objectVersion la cn=Schema,cn=Configuration,dc=X în Active Directory utilizând un instrument precum ADSIEdit. Vă rugăm să rețineți că unele aplicații, de ex. Exchange Server, Managementul sistemului Serverul (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 (clasa pe scurt) și attributeSchema (atribut pe scurt). De obicei, o extensie de schemă 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ă. Atribut în Schema directorului creat prin specificarea unui obiect attributeSchema în containerul de schemă și apoi definirea proprietățile necesare obiect nou.

Pentru o listă a proprietăților și informațiilor obiectului attributeSchema, consultați go.microsoft.com/fwlink/?LinkId=110445. După cum puteți vedea, pentru obiecte poate fi definită attributeSchema un numar mare de proprietăți, dintre care unele sunt necesare.

Pe lângă atributele obișnuite, schema conține și atribute speciale numite atribute legate, care sunt 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, un grup ContosoEmployees cu membrul John Doe) este o legătură directă, iar atributul memberOf corespunzător al unui obiect membru este o legătură înapoi (astfel încât, atunci când atributul memberOf al membrului John Doe este interogat, se calculează numele distinctiv (DN) al grupului ContosoEmployees).

Link-ul înainte funcționează la fel ca orice alt atribut. Valorile pot fi cu o singură valoare sau cu mai multe valori (cum ar fi 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. Atunci când este interogată o valoare de atribut de legătură înapoi, rezultatul este calculat pe baza tuturor valorilor de legătură directă corespunzătoare. Backlink-urile sunt întotdeauna ambigue.

Toate clasele de obiecte din ADDS sunt definite de un obiect classSchema din containerul de schemă. Pentru o listă a atributelor care sunt cele mai importante 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 utilitare. 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 printr-o valoare de 0 în atributul objectClassCategory. Acest tip nu ar trebui să mai fie definit.)

Obținerea și utilizarea identificatorilor

Identitățile tuturor obiectelor classSchema și attributeSchema din director sunt definite folosind identificatorii de obiect obligatorii (OID), guvernsID pentru obiectele classSchema și attributeID pentru obiectele attributeSchema. Acestea sunt unice valori numerice, cu condiția anumite centre pentru a identifica obiectele. 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. Identificatorul obiectului din director trebuie să fie unic.

ID-ul obiectului este un șir de numere, de exemplu 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

Când o organizație dorește să extindă o schemă, se asigură că identificatorul de entitate este unic 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 biroul național de înregistrare ISO (în SUA, Institutul American de Standarde Naționale (ANSI)).

Procedura și taxele de serviciu pentru obținerea ID-ului obiectului rădăcină pot fi găsite pe ansi.org. În alte regiuni, contactați organizația membru ISO corespunzătoare, care este listată la iso.org/iso/about/iso_members.htm.

Anterior, organizațiile au primit un ID de obiect de la Microsoft prin trimiterea unui mesaj E-mail dupa adresa [email protected]. Cu toate acestea, acum rezultă 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 un număr de spațiu numeric Microsoft Object Identifier: 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 obiecte. Deci, puteți folosi 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 numărul unic al organizației, iar y și z sunt numerele atribuite anumite obiecte classSchema și, respectiv, attributeSchema). De asemenea, este recomandat să utilizați un prefix de organizare unic pentru a distinge numele acestor obiecte.

Definirea atributelor asociate

Valoarea attributeSyntax a legăturii înapoi trebuie să fie 2.5.5.1, care este sintaxa obiectului (DS-DN). De obicei, atributele back link sunt adăugate la valoarea mayContain a clasei cu cea mai mare abstractizare. Acest lucru asigură că atributul legăturii înapoi poate fi citit de la obiecte din orice clasă, deoarece astfel de atribute nu sunt stocate în obiect, ci sunt calculate pe baza valorilor legăturii directe.

Windows Server 2003 a introdus o caracteristică pe care organizațiile o pot folosi pentru a lega două obiecte într-o schemă: crearea automată linkID-uri. Această funcție asigură că un linkID este generat automat 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, atributul attributeId sau ldapDisplayName nu va fi găsit la crearea unui link înapoi. Cache-ul schemei este reîncărcat la cerere la câteva minute după o modificare a schemei sau când controlerul de domeniu este repornit.

Dacă serviciul Active Directory rulează Nivel 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, trebuie să indicați în mesajul dvs. de e-mail următoarele informații: numele companiei, nume persoana de contact, adresa de e-mail, număr de telefon, prefix înregistrat (dacă este necesar), ID obiect înregistrat (dacă este necesar).

Puteți începe să extindeți schema

Să presupunem că decideți să vă extindeți schema Active Directory. Soluția poate implica întreruperea utilizării directorului alternativ implementat prin ADLDS (sau ADAM în Windows Server 2003) odată ce se stabilește că nu va îndeplini cerințele. Următorul pas este definirea noilor obiecte attributeSchema care trebuie adăugate la schemă; aceasta definește orice valori necesare (cum ar fi cn, ldapDisplayName etc.) care indică aceste noi obiecte. Când definiți valori de atribut pentru un obiect, obțineți și identificatorul de obiect de la Microsoft sau de la o altă sursă. Activitățile de mai sus sunt documentate ca cerințe de afaceri și specificații tehnice. Mai mult, a fost implementat un mediu experimental de laborator care simulează funcționarea Active Directory și este gata de testare.

Multe organizații creează comitete speciale pentru a aproba sau a respinge astfel de modificări și pentru a stabili un proces pentru implementarea lor. Aceste verificări și echilibrări sunt esențiale deoarece Active Directory este folosit ca o sursă de informații de încredere în multe organizații, ceea ce este important de întreținut. in stare de functionare Odată făcute modificările, nu se poate exagera.

Odată ce o organizație decide să continue cu un proiect, trebuie definite planuri de testare și implementare a proiectului. Vă puteți extinde schema prin adăugarea de noi obiecte utilizând programul de completare Schema Console Active Directory management Microsoft(MMC) sau utilizarea metodelor programatice sau semi-programatice (de exemplu, utilizarea LDIFDE pentru a importa fișiere LDIF; utilizarea CSVDE pentru a importa fișiere CSV; sau utilizarea scripturilor pentru interfețele ADSI).

Indiferent de metoda aleasă, această funcție trebuie efectuată pe un server care are rolul FSMO(Flexible Single Master Operations) master schema în sau conectat la o pădure Active Directory. In afara de asta, cont Utilizatorul folosit pentru a actualiza schema necesită drepturi administrative suficiente pentru a efectua actualizarea, așa că trebuie inclus în grupul Administratori de schemă. În cele din urmă, trebuie să activați actualizările de schemă 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 pot apărea cu pașii manuali. 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ă executați o reîncărcare a memoriei cache. Mai jos sunt câteva exemple.

Adăugarea de atribute

De dragul acestei discuții, să presupunem că o organizație numită Contoso trebuie să adauge un atribut la Active Directory care identifică mărimea pantofilor tuturor angajaților. Există două domenii în pădurea Active Directory: contoso.com și employees.contoso.com. Toate obiectele create folosind definiția clasei utilizator trebuie să conțină și acest nou atribut.

Este important să ne amintim că o modificare a schemei afectează ambele domenii, deoarece acestea se află în aceeași pădure. Să presupunem că primiți ID-ul obiectului 1.2.840.113556.8000.9999 de la Microsoft, care se împarte în 1.2.840.113556.8000.9999.1 pentru obiectul classSchema și 1.2.840.113556.8000.9999999.8000.attributeSchema.9. Acum trebuie să definiți toate valorile atributelor pentru acest nou obiect, așa cum se arată în orez. 3.

Definirea atributului contosoEmpShoe

În plus, deși atributul contosoEmpShoe ar trebui să fie disponibil pentru toate obiectele create ca obiecte de clasă de utilizator, nu se recomandă modificarea definiției implicite a clasei de utilizator. În schimb, ar trebui să 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.

Definirea clasei contosoUser

Acum că analiza a fost făcută și valorile au fost determinate, trebuie să creați un fișier LDIF care va arăta ceva ca codul din orez. 5. Puteți copia codul în orez. 5în Notepad și salvați fișierul ca contosoUser.ldif (inclus în descărcarea de la technetmagazine.com).

Fișier LDIF pentru extensia schemei

#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.9050.11.9050 : 2.5.5.1 2 isSingleValued: TRUE adminDisplayName: contosoEmpShoe adminDescription: contosoEmpShoe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: contosoEmpShoe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow Classes: schemaUpdateNow=CN1Shoe ,CN=Configurare , DC =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: contoryUser ID: contornUser: contoryName: contoryUser PUG DisplayName: contosoNume utilizator: contosoUser systemOnly: FALSE dn: changetype: modifică adăuga: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=Utilizator,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: auxiliaryClass auxiliaryClass: contosoUser - dn: changetype: modifică add: schemaUpdateNow: schemaUpdateNow 1

După ce creați fișierul LDIF, trebuie să testați temeinic implementarea într-un mediu de laborator pilot, să verificați replicarea de la capăt la capăt al domeniului și al pădurii și să activați actualizările schemei în pădure. Acum trebuie să vă conectați folosind 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ările) ș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, activați replicarea de ieșire pe schema master și asigurați-vă că replicarea este completă 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 folosind 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 partiția Users, faceți clic dreapta pe ContosoTestUser, apoi deschideți pagina Proprietăți. Găsiți atributul contosoEmpShoe. Puteți modifica acest atribut pentru a introduce o valoare. De asemenea, puteți utiliza program utilitar 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ă compania Contoso este foarte importantă pentru mărimea pantofilor angajaților săi și trebuie să urmărească productivitatea anuală a specialiștilor care măsoară mărimea pantofilor angajaților companiei. Deși acest lucru poate părea ridicol, să presupunem, de asemenea, că Contoso trebuie să urmărească nu numai cine este responsabil pentru măsurarea mărimii de pantofi ale angajaților, ci și angajații ale căror mărimi de pantofi au fost măsurate și numărul acestora, toate interogând un singur atribut. (Deși ați putea crede că tabelele de baze de date ar fi mai potrivite pentru stocarea acestui tip de date, scopul aici este pur și simplu de a explica cum funcționează legăturile înainte și înapoi.)

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

Fișiere LDIF de legături înainte și înapoi

#linkids1.ldif #Attribute definition for Forward Link Attribute dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizeTaker attributeID.1.0.9401.1.0.940 9.2. 2 LinkID: 1.2.840.113556.1.2.50 attributeSyntax: 2.5.5.1 isSingleValued: TRUE adminDisplayName: ContosoShoeSizeTaker adminDescription: ContosoShoeSizeTaker oMSyntax: 64 SearchNameShoeSizeTaker Contoso ly: FALSE d n: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Reîncărcare schema #linkids2.ldif #Attribute definition for Backward Link Attribute dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizes.18.14.14.14 .8000,99 99.2 .3 LinkID: 1.2.840.113556.8000.9999.2.2 attributeSyntax: 2.5.5.1 isSingleValued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe adminDescription: Conizes oMSTakenByS4 1 lDAPDisplayN ame: ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - # Adăugați atributul ContosoShoeSizeTaker și ContosoShoeSizesTakenByMe ca MayContain în #contosoUser class dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizeSize:Metosotype change:Taker adăugați: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribute as MayContain in Top dn: CN=Top,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow: schemaUpdateNow ldifde – i –f \linkedids.ldif –b -k –j. –c „CN=schemă,CN=Configurație,DC=X” #schemaNamingContext

Acum, când creați un obiect utilizator, acesta va avea și atributele ContosoShoeSizeTaker și ContosoShoeSizesTakenByMe. Când creați un obiect utilizator pentru John, de exemplu, atributul ContosoShoeSizeTaker este populat cu numele distinctiv al persoanei care a măsurat mărimea pantofului, Frank. Dacă acum accesați proprietățile obiectului utilizator al lui Frank și interogați atributul ContosoShoeSizesTakenByMe, rezultatul va conține numele distinctiv al lui Frank și al celorlalți a căror mărime de pantof a măsurat Frank. Pentru a finaliza cazul nostru, conducerea îl poate recompensa pe 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 cu cerințele arhitecturale. Aceste verificări de securitate și coerență sunt utilizate de Active Directory pentru a se asigura că modificările nu cauzează inconsecvențe sau alte probleme la extinderea sau modificarea schemei Active Directory.

Î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ă. De asemenea, atributul objectClassCategory al tuturor claselor din listele systemPossSuperiors și possSuperiors trebuie definit ca clasa 88 sau o clasă structurală.

La definirea unor 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 să aibă sintaxa șirurilor Unicode.

Acestea sunt câteva dintre regulile referitoare la 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 unică. Apoi, dacă rangeLower și rangeUpper sunt prezente, valoarea rangeLower trebuie să fie mai mică decât valoarea rangeUpper. Valorile attributeSyntax și oMSyntax trebuie să se potrivească. Dacă sintaxa atributului este sintaxa obiect (oMSyntax =127), trebuie să aibă oMObjectClass corectă. LinkID-ul, dacă este prezent, trebuie să fie unic. În plus, o legătură înapoi trebuie să aibă o legătură directă corespunzătoare.

Dacă a fost o eroare?

Odată ce schema a fost extinsă și i-au fost adăugate noi obiecte (clase și atribute), acestea nu pot fi șterse. Cu toate acestea, clasele și atributele pot fi dezactivate prin setarea atributului isDefunct al unui obiect de schemă la TRUE. Nu puteți dezactiva obiectele de schemă care fac parte din schema implicită care vine cu Active Directory (obiecte de categoria 1). Numai obiectele adăugate la schema implicită pot fi dezactivate, 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 efective existente.

Când încercați să dezactivați orice atribut, Active Directory verifică dacă este utilizat în listele mustContain și mayContain ale oricărei clase valide existente. Obiectele dezactivate pot fi activate din nou prin setarea atributului 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 într-o 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ă verificări suplimentare că modificările nu provoacă inconsecvență și nu pot cauza probleme în circuit în viitor.

Deși modificarea schemei Active Directory nu este un proces complicat, 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 efectuate cu mare atenție. Este important să se definească cerințele afacerii și specificatii tehnice pentru obiecte noi și efectuați teste cuprinzătoare. Deoarece modificările pot avea un impact semnificativ, se recomandă extinderea schemei Active Directory numai atunci când este absolut necesar.