Extinderea Schemei Active Directory. Schema master - Schema master Active Directory

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 din cauza faptului că rareori este necesar să se ocupe de ea. Î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, trebuia 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.

Există mai multe moduri de a vizualiza versiunea schemei. Cea mai simplă este metoda care utilizează utilitarul 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= numele domeniului, 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 vedea 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.

Înțelegeți dacă a existat o schimbare
Schema Exchange Active Directory nu este aplicată de server prin atributul " rangeUpper, care acceptă următoarele 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.

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 a 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 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 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 creează comitete ad-hoc pentru a aproba sau a respinge astfel de modificări și pentru a stabili un proces pentru implementarea lor. 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. În plus, 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ă primiți un ID de obiect 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.840.113556.840.113556.80900.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 care sunt create ca obiecte ale clasei de utilizator, nu recomandăm modificarea definiției implicite 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ă creăm 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 cu atenție implementarea într-un mediu de laborator pilot, să validați domeniul de la capăt la capăt și replicarea pădurii ș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: ContoSoshoesizestakesenbyme Systemonly: FalseRype: Modificați: 1 - #Add ContososhoessiZetaker și ContosoShoesizestakesenbyme Atribut ca ContosouRcontain în #contoso: maysercn = SchemaCn = Schemacn = Schema = Configurare, DC =X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizeTaker mayContain: ContosoShoeSizesTakenByMe dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribute as MayContain in Top dn: CN=CNSchemap, =CN=Configuration,DC =X tipul de modificare: 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ă fie în sintaxa șirurilor 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 șterse. 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 existente 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.

Un serviciu de director este utilizat pentru a identifica utilizatorii și resursele din rețea. Comparativ cu versiunile anterioare de Windows, Microsoft Windows 2003 îmbunătățește foarte mult capacitățile Active Directory. Active Directory este un instrument unic de gestionare a rețelei care facilitează adăugarea, eliminarea și mutarea utilizatorilor și a resurselor.

Introducere în Active Directory

Instrumentele Active Directory vă permit să proiectați structura de directoare așa cum are nevoie organizația dumneavoastră. În această lecție, veți afla despre utilizarea obiectelor Active Directory și scopul componentelor sale.

După ce ați studiat materialul din această lecție, veți fi capabil să:

explicați scopul obiectului Active Directory și atributelor schemei;

definiți și descrieți funcțiile componentelor Active Directory.

Obiecte AD

La fel ca toate serviciile care fac informațiile accesibile și utile, Active Directory stochează informații despre resursele rețelei. Aceste resurse, cum ar fi datele utilizatorului, descrierile de imprimante, servere, baze de date, grupuri, computere și politici de securitate, sunt numite obiecte.

Un obiect este un singur set numit de atribute care reprezintă o resursă de rețea. Atributele unui obiect sunt caracteristicile acestuia din director. De exemplu, atributele contului de utilizator pot include numele și prenumele utilizatorului, departamentul și adresa de e-mail (Figura 2-1)

În Active Directory, obiectele pot fi organizate în clase, adică în grupuri logice. Un exemplu de clasă este o colecție de obiecte reprezentând conturi de utilizator, grupuri, computere, domenii sau unități organizaționale (OU).

Notă Obiectele care pot conține alte obiecte se numesc containere. De exemplu, un domeniu este un obiect container care poate conține utilizatori, computere și alte obiecte.

Ce obiecte pot fi stocate în Active Directory este determinat de schema acestuia.

SistemActivDirector

Schema Active Directory este o listă de definiții care definesc tipurile de obiecte care pot fi stocate în Active Directory și tipurile de informații despre acestea. Aceste definiții în sine sunt stocate ca obiecte, deci sunt gestionate de Active Directory în același mod în care sunt gestionate alte obiecte din Active Directory.

Există două tipuri de definiții într-o schemă: atribute și clase. Ele sunt numite și obiecte de schemă sau metadate.

Atributele sunt definite separat de clase. Fiecare atribut este definit o singură dată și poate fi folosit în mai multe clase. De exemplu, atributul Description este folosit în multe clase, dar este definit o singură dată în schemă, ceea ce asigură integritatea acestuia.

Clasele, numite și clase de obiecte, descriu obiectele Active Directory pe care le puteți crea. Fiecare clasă este o colecție de atribute. Când un obiect este creat, atributele stochează informații care îl descriu. De exemplu, atributele clasei User includ Adresa de rețea, Directorul principal și așa mai departe. Fiecare obiect din Active Directory este o instanță a unei clase de obiecte.

Windows 2000 Server vine cu un set de clase de bază și atribute. Prin definirea de noi clase și noi atribute pentru clasele existente, dezvoltatorii experimentați și administratorii de rețea pot extinde în mod dinamic schema. De exemplu, dacă trebuie să stocați informații despre utilizatori care nu sunt definite în schemă, puteți extinde schema pentru clasa Users. Cu toate acestea, o astfel de extindere a schemei este o operațiune destul de complexă, cu posibile consecințe grave. Deoarece schema nu poate fi ștearsă, ci doar dezactivată și se reproduce automat, trebuie să vă pregătiți și să planificați extinderea acesteia.

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 numire

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.