De la lansarea serviciului Director activ 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. ÎN Microsoft Exchange 2000, de exemplu, Active Directory a fost folosit pentru implementarea sistemelor 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. Mai mult, deoarece multe aplicații depind de definițiile subiacente 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 ar trebui să afecteze alte aplicații.

Ce este o schemă?

Pentru multi Schema activă Directorul este un pic o cutie neagră, iar ideea de a schimba schema în sine poate fi descurajantă pentru ei. Desigur, extinderea schemei Active Directory nu este ceva pe care trebuie să-l faci în fiecare zi, dar unele aplicații sau companii o necesită. 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) pentru 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 de extinderea schemei Active Directory.

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 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 este situată î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, 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 (clasa pe scurt) și attributeSchema (atribut pe scurt). De obicei, o extensie de schemă Active Directory este luată în considerare dacă organizația 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, puteți defini un număr mare de proprietăți pentru obiectele attributeSchema, 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. Ca 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. Când este interogată o valoare a atributului 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 mai trebuie 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, asigurate 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. 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 primeau 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 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 numărul unic al organizației, iar y și z sunt numere atribuite anumitor 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 in caz contrar Când creați un link înapoi, attributeId sau ldapDisplayName nu vor fi găsite. 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ă rulați Windows 2000 Active Directory, 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.” (Mesaje de e-mail trimise către [email protected], vor fi procesate numai dacă se referă la înregistrarea linkID-urilor pentru medii vechi.) Pentru a face acest lucru, trebuie să includeți următoarele informații în e-mailul dvs.: Nume companie, Nume de contact, Adresă de e-mail, Număr de telefon, Prefix înregistrat (dacă este necesar), ID site î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ă; în acest caz toate valorile cerute(cum ar fi cn, ldapDisplayName etc.) indicând 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, iar importanța menținerii acesteia după efectuarea modificărilor nu poate fi exagerată.

Odată ce o organizație decide să continue cu un proiect, trebuie definite planuri de testare și implementare a proiectului. Puteți extinde schema prin adăugarea de noi obiecte utilizând snap-in-ul de schemă Microsoft Management Console (MMC) Active Directory sau utilizând metode programatice sau semi-programatice (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 pe care o alegeți, 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 necesită drepturi administrative suficiente pentru a efectua actualizarea, deci 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.199506. x: 2,5,5 12 isSingleValued: TRUE adminDisplayName: contosoEmpShoe adminDescription: contosoEmpShoe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: contosoEmpShoe systemOnly: FALSE dn: changetype: modify add: schemaUpdate #NowClass: schemaUpdateNow: schemaUpdateNow: schemaUpdateNow: schemaUpdateNow: =Schema,CN=Config uration,DC =X changetype: ntdsschemaadd objectClass: top objectClass: classSchema cn: contosoUser guvernsID: 1.2.840.113556.1.8000.9999.1.1 mayContain: contosoEmpShoe rDNAttID: cn admin admin:UsoryNaserCadmin: contosoEmpShoeClassAdmin:contoadmin:contolasserC 3 l DAPDisplayName: contosoNume utilizator: contosoUser systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=Utilizator,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: auxiliaryClass auxiliaryClass: contosoUser - dn: changetype: modifyw: schemaUpdate 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 #Definiție atribut pentru atributul de legătură directă dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizeTaker attributeID:901.12.3.806. 99,2. 2 LinkID: 1.2.840.113556.1.2.50 attributeSyntax: 2.5.5.1 isSingleValued: TRUE adminDisplayName: ContosoShoeSizeTaker adminDescription: ContosoShoeSizeTaker oMSyntax: 64 searchNameShoeSizeTaker ContosoShoeSizeTaker nly: FALSE dn: 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: ContosoShoeSizesTakenByMe, CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attributeSchema cn: ContosoShoeSizesTakenByMe,CN=Schema 1,8000,9 999.2 .3 LinkID: 1.2.840.113556.8000.9999.2.2 attributeSyntax: 2.5.5.1 isSingleValued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe adminDescription: Conizes4ShoeSizesSingleDescription:FALSE : 1 lDAPDDisplay Name: ContosoShoeSizesTakenByMe systemOnly: FALSE dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - # Adăugați atributul ContosoShoeSizeTaker și ContosoShoeSizesTakenByMe ca MayContain în clasa #contosoUser dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify adăugați: mayContain mayContain: ContosoShoeShokenSizeSize:Metosotype dn:ContosoShoeSizeSize:Taken modifică adaugă: 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 ar putea să-l recompenseze 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, 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 setând atributul 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 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 de 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 schimbarea 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ă definiți cerințele de afaceri și specificațiile tehnice pentru noile facilități și implementate testare cuprinzătoare. Deoarece modificările pot avea un impact semnificativ, se recomandă extinderea schemei Active Directory numai atunci când este absolut necesar.

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, apar probleme, î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 despre ce este vorba 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 controlere 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 în domeniu computerele care rulează versiuni mai noi de Windows. 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 în pădure pot avea diverse moduri lucru, de exemplu, unul dintre domenii poate lucra 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 utilizarea unui mod de funcționare superior în domeniu; tot ceea 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 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.

Î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ția, contul dvs. trebuie 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 politici de grup. Această operațiune se efectuează 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ă 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 copiile de rezervă necesare la îndemână.

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 despre ce este vorba 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 controlere 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 în domeniu computerele care rulează versiuni mai noi de Windows. Acest lucru nu este adevărat; chiar și cele mai recente versiuni de Windows pot funcționa cu succes într-un domeniu de nivel 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 într-o pădure pot avea diferite moduri de operare, 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 ceea 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 de 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.

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

Pentru a activa cu succes un controler care rulează o versiune mai nouă a sistemului de operare, va trebui să actualizăm schema pădurii și schema domeniului. Excepția este Windows Server 2012, care va actualiza schema de la sine atunci când adaugă un nou controler de domeniu.

Pentru a actualiza schema, utilizați utilitarul Adprep, care se află în folder \support\adprep la instalare 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ă o 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 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ția, contul dvs. trebuie 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 se efectuează 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 copiile de rezervă necesare la îndemână.
Sursa http://interface31.ru/tech_it/2013/05/obnovlenie-shemy-active-directory.html

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. Majoritate administratorii de sistem nu acordă atenția cuvenită schemei din cauza faptului că trebuie să se ocupe de ea destul de rar. Î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 anumiti parametri, numite 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 diferite versiuni ale sistemului de operare Windows. Anume pe Bazat pe Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Deoarece aceste versiuni au fost lansate în ani diferiti, și fiecare o nouă versiune are mai multe funcționalități decât precedentul; fiecare sistem de operare are propria înțelegere a schemei. Prin urmare, atunci când adăugați un nou controler bazat pe Windows Server 2008 la o organizație în care controlere existente construit pe Windows Server 2003, trebuia să rulați " Adprep" Astfel, ați actualizat diagrama organizației dumneavoastră 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 efectivă de instalare a unui nou controler 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 ajunge, pentru a înțelege completitatea structurii, va trebui să știi la ce nivel funcționează Schema organizației actuale.

Versiuni posibile ale circuitului:

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ă pe Windows Server 2003 R2, iar versiunea circuitului arată „44”, nu ar trebui să fiți surprins, acest lucru indică faptul că circuitul a fost deja actualizat la nivelul Windows Server 2008 RTM, dar controlerul în sine, dintr-un motiv oarecare, nu a existat niciun motiv pentru a-l instala.

Există mai multe moduri de a vizualiza versiunea schemei; cea mai ușoară modalitate este utilizarea utilitarului DSQuery. În acest scop în Linie de comanda trebuie să introduceți comanda cu următorii parametri:

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

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

Rezultatul introducerii comenzii este obținerea atributului " ObjectVersion", care va fi numărul versiunii schemei:

Orez. 1 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 schemei prin snap-in " ADSIEdit.msc».

Cunoscând versiunea schemei, puteți spune întotdeauna cu încredere dacă schema trebuie actualizată și, dacă este necesar, la ce nivel.

Trebuie remarcat faptul că actualizările de schemă pot fi efectuate prin software 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, este necesar să se afle dacă schema a fost pregătită? Și dacă da, 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ă Schema Active Directory a fost modificată Server de schimb posibil prin atribut " 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, actualizarea schemei are loc și la instalarea setului de actualizare 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" putem concluziona că schema nu a fost schimbată.

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

Material furnizat de resursă

04.07.2011 Brian Desmond

Din punct de vedere istoric, administratorii Active Directory (AD) și managerii IT sunt de obicei atenți la extinderea schemei AD. O mare parte a fricii vine din documentația Microsoft. ori Windows 2000, care prezintă extinderea circuitului ca o operațiune complexă care necesită precauț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ă diagrama de baza AD nu se potrivește bine cu datele pe care doriți să le stocați într-un director, dar poate fi extins 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 exemplu bun- Microsoft Exchange. Uneori, furnizorii de software solicită ca schema să fie extinsă pentru a fi compatibilă 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 plănuiți să extindeți schema, în special pentru aplicatii interne, în primul rând, trebuie să aflați dacă datele sunt potrivite pentru stocare în AD. Este deosebit de convenabil să stocați în AD date relativ statice (care se schimbă rar) 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 cardurilor 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 rula ca serviciu pe un server membru al domeniului (sau controler de domeniu - DC) și, ca și AD, poate gestiona cererile direcționate către LDAP. Necesitatea de a găzdui controlere de domeniu AD pentru autentificare și suport pentru aplicații nu este o limitare enervantă, ci mai degrabă o oportunitate 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 a datelor

Doi termeni sunt cheia pentru înțelegerea schemei AD: clasă și atribut. Toate elementele AD, inclusiv schema, sunt definite în termeni de clase și atribute. Clasele sunt tipurile de date care trebuie stocate. De exemplu, utilizatorul este o clasă în AD, la fel ca computerul. 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.

Pentru a utiliza o analogie cu o bază de date tipică, 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 majoritatea cazurilor tipice, este suficient să adăugați un atribut la o clasă existentă (de exemplu, utilizator sau grup). Dacă doriți doar să salvați o nouă bucată de date despre un obiect tip existent(cum ar fi un utilizator), încercați mai întâi să găsiți atribute potrivite printre cele disponibile în AD. Schema conține mii de atribute, dintre care majoritatea nu sunt utilizate. Prin urmare, de exemplu, pentru a stoca informații despre adresa poștală a unui utilizator, puteți utiliza atributul physicalDeliveryOfficeName.

Reutilizarea unui atribut în alte scopuri decât utilizarea sa inițială este o abordare proastă. Imaginați-vă că un atribut a fost reatribuit și apoi este achiziționată o aplicație care utilizează acel atribut în scopul său inițial. Va trebui să faceți lucrul dublu, deoarece va trebui să reconfigurați aplicația moștenită care folosește atributul și apoi să mutați datele. În general, este întotdeauna mai sigur să adăugați un atribut special.

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 dintre acestea este necesitatea de a urmări noul tip de date din catalog. Dacă, de exemplu, doriți să urmăriți mașinile companiei în AD, puteți defini o nouă clasă „mașină” în schemă. Un alt caz este o mapare 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 unei clase speciale de obiecte 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 (pentru fiecare dispozitiv) să fie mapat la un utilizator.

Date de intrare pentru extensia schemei

Pentru a pregăti o extensie de schemă, trebuie să colectați un număr de intrări. Numai atunci atributul sau clasa specială 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 poate duce la consecințe periculoase.

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

De obicei, numele prescurtat al companiei este folosit ca prefix. De exemplu, folosesc bdcLLC ca prefix pentru atributele companiei noastre, Brian Desmond Consulting LLC. Pentru ABC Corporation, puteți utiliza prefixul abcCorp. Asigurați-vă că aveți grijă de unicitatea prefixului, deoarece registrul general nu există prefixe. Dacă compania dvs. are un nume generic sau prescurtat, aflați cum să îi oferiți o întorsătură unică.

Odată ce un nume este ales, trebuie să atribuiți un identificator de obiect (OID) atributului sau clasei. OID-urile sunt o componentă opțională care trebuie să fie unică la nivel global. AD (mai general, LDAP) nu este singurul cadru care folosește OID ca identificator, astfel încât Autoritatea pentru Numerele Alocate pe Internet (IANA) atribuie arbori OID unici pe baza solicitărilor companiei. O solicitare pentru un număr de întreprindere privată, care este o parte a arborelui OID care este unică pentru o companie, este procesată 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 la www.iana.org/cgi-bin/assignments.pl.

Odată ce aveți un număr de întreprindere privată, puteți crea și organiza un număr practic nelimitat de OID-uri unice. 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 construiesc o ramură de clasă și o ramură de atribut sub aceasta. Sub fiecare dintre aceste ramuri, OID-urile sunt atribuite fiecărui atribut sau clasă nouă. Figura prezintă OID-ul (1.3.6.1.4.1.35686.1.2.1) alocat atributului utilizator myCorpImportantAttr. Este foarte important să se pregătească un mecanism intern de urmărire (de ex. foaie de calcul Lista Excel sau SharePoint) asigurând OID-uri 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ă în 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 Microsoft OID.

Cei doi parametri de intrare rămași sunt specifici atributelor și depind de tipul acestora. Atributele linkurilor 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 referințele să fie actualizate prompt în funcție de locația obiectului în pădure. Două exemplu tipic atribute conexe - apartenența la grup (member și memberOf) și relația manager/angajat (manager/directReports). Conceptele de link-uri directe și link-uri înapoi se aplică atributelor legate. O legătură directă este o parte editabilă a relației 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 un backlink. Atunci când editați apartenența la un grup, se fac modificări atributului membru (link direct) și nu atributului memberOf al obiectului membru (link înapoi).

Pentru a defini atributele legate în AD, trebuie să definiți două atribute (un link direct și un backlink) și să atașați un identificator de link (linkID) la fiecare dintre aceste atribute. ID-urile de legături trebuie să fie unice în pădure și, deoarece ID-urile de legături sunt necesare și pentru alte aplicații care necesită extensie de schemă, acestea trebuie să fie unice la nivel global. În trecut Compania Microsoft identificatori de legături publicati pentru organizații terțe, dar începând cu Windows Server 2003, AD a introdus în schimb un pointer special care vă permite să generați identificatori unici de legături atunci când adăugați o schemă asociată cu o pereche de atribute.

AD presupune că ID-urile linkurilor sunt numere secvențiale. Mai exact, atributul de legătură directă este un număr par, iar numărul care îl urmează este atribuit atributului backlink. De exemplu, pentru member și memberOf (apartenența la grup), ID-ul link-ului pentru membru este 4 și 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 felul descris. În caz contrar, ar trebui să utilizați procesul automat de generare a ID-ului de legătură implementat în Windows Server 2003. Pentru a utiliza proces automat Când creați ID-uri de link, 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, următorii pași sunt necesari pentru a construi atributele asociate (dacă acestea fac parte din extensie).

Mai întâi pregătiți o legătură directă folosind ID-ul link-ului 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 ID-ul de legătură automată.

Apoi reîncărcați memoria cache a schemei. După aceasta, creați un atribut de backlink folosind ID-ul link-ului al numelui atributului de link forward ș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 trebuie să afișați atributul în Lista globală de adrese (GAL), puteți sări peste această secțiune. ID-urile MAPI sunt folosite pentru a afișa atribute pe una dintre paginile de proprietate dintr-o agendă de adrese, cum ar fi un șablon detalii generale utilizator (vezi ecran). De exemplu, dacă doriți să afișați clasificarea angajaților (angajat cu normă întreagă sau angajat cu contract) în GAL, atribuiți atributul corespunzător ca identificator MAPI. După ce un ID MAPI este atribuit unui atribut, puteți utiliza Editorul de șabloane de detalii Exchange pentru a introduce datele despre atribut într-o vizualizare în GAL din cadrul Office Outlook.

Identificatorii MAPI trebuie să fie unici, la fel ca OID-urile și identificatorii de referință. În trecut, nu era posibil să se genereze identificatori MAPI unici, astfel încât acești identificatori au fost î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ă, atribuiți valoarea 1.2.840.113556.1.2.49 atributului MAPI ID atunci când creați atributul. AD generează un ID MAPI unic pentru atribut după ce memoria cache a schemei este reîncărcată. 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. Când planificați o extindere a circuitului, trebuie să luați în considerare trei parametri critici de intrare. 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ă OID de la organizația IANA. Dacă urmează să fie creată o pereche de atribute legate, este necesară o pereche unică de identificare a legăturii. Dacă doriți să afișați atributul în lista Exchange GAL, trebuie să utilizați un identificator MAPI unic. Atât pentru ID-urile link-urilor, cât și pentru ID-urile MAPI, utilizarea unui proces de generare automată în cadrul AD este de preferat decât utilizarea valorilor statice.

Planificarea implementării

Când implementați o extensie de schemă personalizată sau extindeți o 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 să verificați extensia 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ă pentru stațiile de lucru Windows XP și Windows 7. stație de lucru Puteți crea o instanță AD LDS, puteți construi o extensie de schemă într-un mediu izolat și apoi exportați extensia pentru importarea ulterioară într-o pădure AD de testare. Schema AD LDS este compatibilă cu AD, așa că puteți utiliza LDIFDE pentru export. Puteți importa o extensie de schemă finalizată într-o pădure 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ă testați o extensie de schemă într-o pădure AD de testare, 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 (parte din AD LDS) pentru a detecta diferențele de schemă între două păduri AD. Articolul „Exportați, comparați și sincronizați schemele Active Directory” de pe TechNet (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. Vă rugăm să rețineți că pot exista unele diferențe în comparațiile de schemă, în funcție de pachetele de servicii și versiunile de Windows, în special în ceea ce privește indexarea atributelor și stocarea steagurilor de ștergere.

Pentru extensiile de schemă obținute din alte surse (de exemplu, împreună cu aplicație comercială), este necesar să se asigure că modificările implicate nu implică riscuri. Împreună cu toate datele de intrare 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, apar îndoieli cu privire la corectitudinea acesteia și la fiabilitatea furnizorului. B arată un exemplu LDIF pentru crearea unui atribut în schema AD pentru a stoca informații despre mărimea pantofilor unui utilizator. Trebuie remarcate următoarele caracteristici ale acestei extensii de circuit eșantion.

• Atributul este prefixat pe baza numelui companiei furnizor (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 catalogul global de set parțial de atribute (PAS) și că indecșii creați pentru atribut sunt corecti dacă atributul va fi 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 pentru producție, ar trebui să fie aleasă momentul potrivit pentru această operație. De obicei, poate fi finalizat în timpul programului de lucru. Va exista o creștere vizibilă a încărcării CPU atunci când rulează Schema Wizard și o ușoară creștere a încărcării controlerelor de domeniu care reproduc modificările. Companiile mari pot experimenta pauze de replicare între controlerele de domeniu timp de patru până la șase ore dacă se adaugă atribute la setul parțial de atribute PAS. Pauzele vor fi însoțite de mesaje de eroare care indică probleme cu obiectele, dar de obicei pot fi ignorate și vor dispărea de la sine. Dacă controlerele de domeniu au fost deconectate de la replicare pentru o perioadă lungă de timp, ar trebui să începeți depanarea.

Abordare sistematica

Nu există niciun pericol în extinderea schemei AD dacă luați măsuri de precauție de bază. Când planificați noi extensii de schemă și când validați atribute personalizate și clase terțe, acordați atenție informațiilor de identificare unice pentru fiecare clasă sau atribut și asigurați-vă că este unică la nivel global.

După verificarea integrității, portați noua extensie la 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: add objectClass: top objectClass: attributeSchema cn: sfsuLiveServiceEntitlements attributeID: 1.3.6.1.4.1.35686.100.1.1.1.2.2.5.25686.100.1.1.2.2.2.2.2.2.2. ALSE showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Stochează mărimea încălțămintei unui utilizator oMSyntax: 64 searchFlags: 1 lDAPDisplayName: bdcllcShoeSize nume: bdcllcShoeSizeSize: schemasIDGUID:MerlE JPG=WMaz6: mberOfPartialAttribute Set: TRUE