Introduktion till Active Directory. Active Directory Schema Version. Vad är ett schema

En katalogtjänst används för att identifiera användare och resurser på ett nätverk. Jämfört med tidigare versioner av Windows Microsoft Windows Under 2003 har Active Directory-funktionerna utökats avsevärt. Active Directory ger en enhetlig nätverkshanteringsupplevelse som gör det enkelt att lägga till, ta bort och flytta användare och resurser.

Vi presenterar Active Directory

Active Directory-verktyg låter dig designa katalogstrukturen så att den passar din organisation. I den här lektionen kommer du att bli bekant med användningen av Active Directory-objekt och syftet med dess komponenter.

Efter att ha studerat materialet i den här lektionen kommer du att kunna:

förklara syftet med objektattribut och Aktiva system Katalog;

Definiera och beskriv funktionerna för Active Directory-komponenter.

Active Directory-objekt

Liksom alla tjänster som gör information tillgänglig och användbar, lagrar Active Directory information om nätverksresurser. Dessa resurser, som användardata, beskrivningar av skrivare, servrar, databaser, grupper, datorer och säkerhetspolicyer, kallas objekt.

Ett objekt är en enda namngiven uppsättning attribut som representerar en nätverksresurs. Attributen för ett objekt är dess egenskaper i katalogen. Användarkontoattribut kan till exempel inkludera för- och efternamn, avdelning och e-postadress (Figur 2-1).

I Active Directory kan objekt organiseras i klasser, det vill säga i logiska grupper. Ett exempel på en klass är en samling objekt som representerar användarkonton, grupper, datorer, domäner eller organisationsenheter.

Obs Objekt som kan innehålla andra objekt kallas behållare. Till exempel är en domän ett containerobjekt som kan innehålla användare, datorer och andra objekt.

Vilka objekt som kan lagras i Active Directory bestäms av dess schema.

SchemaAktivaKatalog

Ett Active Directory-schema är en lista med definitioner som definierar de typer av objekt som kan lagras i Active Directory och typerna av information om dem. Dessa definitioner lagras också som objekt, så Active Directory hanterar dem med samma operationer som används för andra objekt i Active Directory.

Det finns två typer av definitioner i ett schema: attribut och klasser. De kallas också schemaobjekt eller metadata.

Attribut definieras separat från klasser. Varje attribut definieras endast en gång och kan användas i flera klasser. Till exempel används attributet Description i många klasser, men det definieras bara en gång i schemat, vilket säkerställer dess integritet.

Klasser, även kallade objektklasser, beskriver vilka Active Directory-objekt som kan skapas. Varje klass är en samling attribut. När ett objekt skapas lagrar attribut information som beskriver det. Till exempel inkluderar attribut för klassen User Network Address, Home Directory, etc. Varje objekt i Active Directory är en instans av en objektklass.

Windows 2000 Server har en inbyggd uppsättning av basklasser och attribut. Genom att definiera nya klasser och nya attribut för befintliga klasser kan erfarna utvecklare och nätverksadministratörer utöka schemat dynamiskt. Om du till exempel behöver lagra information om användare som inte är definierad i schemat, kan du utöka schemat för klassen Användare. En sådan utvidgning av systemet är dock en ganska komplex operation med möjliga allvarliga konsekvenser. Eftersom schemat inte kan tas bort, bara avaktiveras och replikeras automatiskt, måste du förbereda och planera för expansionen.

Det är svårt att underskatta betydelsen av "Active Directory Schema" för nätverk byggda på basis av en Active Directory-domänmiljö. Detta är grunden för AD-teknik och det är mycket viktigt att korrekt förstå principerna för dess funktion. De flesta systemadministratörer ägnar inte vederbörlig uppmärksamhet åt systemet på grund av att de sällan behöver hantera det. I den här artikeln kommer jag att berätta vad en schemaversion är, varför vi behöver veta den, och viktigast av allt, hur man ser den aktuella versionen.

Först av allt, några ord om själva schemat, varje objekt som skapas i Active Directory, vare sig det är en användare eller en dator, har vissa parametrar som kallas attribut. Mest enkelt exempel kan fungera som attributet "Efternamn" för användarobjektet. Schemat definierar vilka objekt vi kan skapa i Active Directory och vilka attribut de kommer att ha.

Active Directory tillåter användning inom en organisation av flera domänkontrollanter byggda på basen olika versioner Windows OS. Nämligen på grundval Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Eftersom dessa versioner släpptes under olika år, och varje ny version har mer funktionalitet än den tidigare, har varje operativsystem sin egen förståelse av schemat. Därför, när du lägger till en ny styrenhet till Windows baserad Server 2008 till en organisation där befintliga styrenheter byggd på Windows Server 2003, var du tvungen att köra " Adprep" Du har alltså uppdaterat din organisations diagram till den nivå som det fungerar med Windows Server 2008.

Schemauppdateringsprocessen utfördes före den första installationen Windows-kontroller Server 2008 och den faktiska proceduren för att installera en ny styrenhet kanske inte har utförts. Om du precis har börjat arbeta med en Active Directory-organisation och inte vet vilka aktiviteter som utfördes innan du anlände, för att förstå strukturens fullständighet, måste du veta på vilken nivå den nuvarande organisationens Schema fungerar.

Möjliga versioner av kretsen:

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

Även om alla kontroller i din organisation kör Windows Server 2003 R2, och den schematiska versionen visar "44", bör du inte bli förvånad, detta indikerar att schemat redan har uppdaterats till Windows nivå Server 2008 RTM, men av någon anledning installerade de inte själva styrenheten.

Det finns flera sätt att se schemaversionen, det enklaste sättet är att använda DSQuery-verktyget. För att göra detta i kommandorad du måste ange kommandot med följande parametrar:

"dsquery * cn=schema,cn=konfiguration,dc=domännamn,dc=local -scope base -attr objectVersion"

Naturligtvis i delen " dc=domännamn,dc=lokal" du måste byta ut ditt eget domännamn. (Exempel: dc=microsoft,dc=com )

Resultatet av att ange kommandot är att få attributet " ObjectVersion", som kommer att vara versionsnumret för schemat:

Ris. 1 Skaffa schemaversionen via DSQuery-verktyget.

Den andra metoden är längre och involverar användningen av " ADSIEdit.msc". För att se schemaversionen måste du ansluta till Active Directory-schemapartitionen.

"CN=Schema,CN=Konfiguration,DC=domän,DC=lokal"

Och hitta värdet på attributet " objectVersion".

Fig.2 Skaffa schemaversionen via snapin-modulen " ADSIEdit.msc».

Genom att känna till versionen av schemat kan du alltid med tillförsikt säga om schemat behöver uppdateras och, om nödvändigt, till vilken nivå.

Det bör noteras att schemauppdateringar kan utföras av programvara som är tätt integrerad med Active Directory. Den ljusaste Microsoft exempel Exchange Server. Och ofta i en organisationsplanering Utbytesimplementering Server, måste du ta reda på om schemat har förberetts? Och i så fall, vilken version av Exchange Server. På det här ögonblicket Det finns tre versioner av Exchange som fungerar med Active Directory, men det finns sex alternativ för att ändra schemat. Förstå om Active Directory-schemat har ändrats Exchange-server möjligt av attribut " rangeUpper", som har följande värden:

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

Som du kan se sker schemauppdateringen även när du installerar SP3-uppdateringsuppsättningen för Exchange Server 2000/2003 och SP1 för Exchange 2007.

Visa attributvärde " rangeUpper" Du kan använda DSQuery-verktyget:

"dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=konfiguration,dc=domännamn,dc=local -scope base -attr rangeUpper"

Ris. 3 Hämta attributet " rangeUpper" via DSQuery-verktyget.

Om efter att ha angett detta kommando ett svar returneras som indikerar frånvaron av attributet " rangeUpper" vi kan dra slutsatsen att systemet inte har ändrats.

Schemauppdateringsprocessen är mycket viktig poäng för varje Aktiva organisationer Directory, därför bör du undvika onödiga, omotiverade åtgärder. Förstå essensen av attribut " objectVersion" och« rangeUpper" ger en specialist en fördel när man arbetar med Active Directory i en obekant organisation, och är också ett hjälpverktyg vid problemlösning.

Material tillhandahålls av resurs

04/07/2011 Brian Desmond

Historiskt sett är Active Directory-administratörer (AD) och IT-chefer vanligtvis försiktiga med att utöka AD-schemat. Mycket av rädslan härrör från Microsoft-dokumentation från Windows 2000-eran, som skildrade schemaexpansion som en komplex operation som krävde extrem försiktighet. Men med rimlig planering är det helt riskfritt att utöka systemet

AD-schemat definierar strukturen för data som lagras i katalogen. AD stöder naturligt många typer av objekt (som användare) och attribut (som för- och efternamn). Om det grundläggande AD-schemat inte passar bra med den data du vill lagra i katalogen kan du utöka den med anpassade objekt och attribut.

Vanligtvis utökas AD-schemat av flera skäl, varav den vanligaste i många organisationer är implementeringen av en applikation som kräver att schemat utökas. Ett bra exempel - Microsoft Exchange. Ibland leverantörer programvara kräver att schemat utökas för att vara kompatibelt med deras applikationer. Ordningen utökas ofta för ansökningar egen utveckling eller för att underlätta lagring av företagsdata i AD.

Lagringsalternativ

När man planerar att utöka systemet, särskilt för interna applikationer, först och främst måste du ta reda på om uppgifterna är lämpliga för lagring i AD. Det är särskilt bekvämt att lagra i AD relativt statisk (föränderlig sällan) data som används i hela företaget (replikeras över domängränser) och inte är konfidentiell (det rekommenderas till exempel inte att lagra födelsedatum, personnummer, personnummer, etc. i AD).

Om data inte uppfyller dessa kriterier, men ändå måste placeras i en LDAP-katalog, är det andra alternativet optimalt. AD Lightweight Directory Services (AD LDS, tidigare ADAM) - fristående version AD, som kan fungera som en tjänst på en domänmedlemsserver (eller domänkontrollant - DC), och, liksom AD, hantera förfrågningar riktade till LDAP. Behovet av att vara värd för AD-domänkontrollanter för autentisering och programstöd är inte en irriterande begränsning, utan snarare en möjlighet att noggrant kontrollera vem som kan läsa data och riktningen för datareplikering genom att placera AD LDS-instanser på lämpliga platser.

Primitiver för datalagring

Två termer är nyckeln till att förstå AD-schema: klass och attribut. Alla delar av AD, inklusive schemat, är definierade i termer av klasser och attribut. Klasser är de typer av data som behöver lagras. Användare är till exempel en klass i AD, precis som dator. Attribut är egenskaper hos klasser. Användarklassen har ett förnamnsattribut (givenName) och ett efternamnsattribut (sn). Klassen "dator" har ett attribut " operativ system" AD-schemat definieras i termer av två klasser: classSchema för klasser och attributeSchema för attribut.

För att använda en analogi med en typisk databas kan du jämföra klasser med tabeller i en databas och attribut till kolumner i en tabell. Men kom ihåg att AD Directory Information Tree (DIT) databasstrukturen faktiskt är ganska annorlunda.

När du löser problemet med att lagra en ny typ av data i AD måste du tänka på att kartlägga data till klasser och attribut. I de flesta typiska fall Det räcker med att lägga till ett attribut till en befintlig klass (till exempel användare eller grupp). Om du bara vill spara nytt fragment objektdata befintlig typ(som en användare), försök först hitta lämpliga attribut bland de som finns tillgängliga i AD. Schemat innehåller tusentals attribut, varav de flesta inte används. Därför till exempel för att spara information om postadress användare kan du använda attributet physicalDeliveryOfficeName.

Att återanvända ett attribut för andra ändamål än dess ursprungliga användning är ett dåligt tillvägagångssätt. Föreställ dig att ett attribut har tilldelats om, och sedan förvärvas en applikation som använder det attributet för sitt ursprungliga syfte. Vi måste göra det dubbelarbete, eftersom det är nödvändigt att konfigurera om gammal applikation använda attributet och flytta sedan data. I allmänhet är det alltid säkrare att lägga till ett speciellt attribut.

Men ibland är bara ett klassbaserat tillvägagångssätt möjligt. I två fall är det bekvämare att lägga till en ny klass i schemat än att använda attribut. Den första: behovet av att spåra ny typ data i katalogen. Om du till exempel vill spåra tjänstebilar i AD kan du definiera en ny klass "bil" i schemat. Ett annat fall är en en-till-många-mappning.

Ett idealiskt exempel är Microsoft Exchange Server 2010. Varje mobil enhet som synkroniseras med Exchange med ActiveSync lagras som en instans av en speciell msExchActiveSyncDevice-objektklass i katalogen. Dessa Mobil enheter lagras som underordnade objekt till användaren, enhetens ägare. Denna struktur ger en jämförelse stort antal attribut (för varje enhet) till en användare.

Indata för kretsförlängning

För att förbereda en schematillägg måste du samla in ett antal ingångar. Först då kan det speciella attributet eller klassen implementeras i utvecklingsmiljön. Många insatser måste vara globalt unika, så det är viktigt att göra nödvändiga förberedelser. Försummelse i detta fall kan leda till farliga konsekvenser.

Först och främst väljer du namnet på klassen eller attributet. Den viktigaste delen av ett namn är prefixet. Attribut- och klassnamn i schemat (och i köparschemat tredje parts applikation) måste vara unik, så att lägga till ett prefix säkerställer att det inte finns några konflikter mellan attribut-ID:n.

Vanligtvis används det förkortade företagsnamnet som prefix. Till exempel använder jag bdcLLC som prefix för våra företagsattribut, Brian Desmond Consulting LLC. För ABC Corporation kan du använda prefixet abcCorp. Var noga med att ta hand om prefixets unika, eftersom allmänna register det finns inga prefix. Om ditt företag har ett generiskt eller förkortat namn, ta reda på hur du ger det en unik twist.

När ett namn väl har valts måste du tilldela en Object Identifier (OID) till attributet eller klassen. OIDs - ytterligare komponent, vilket måste vara globalt unikt. AD (mer generellt, LDAP) är inte det enda ramverket som använder OID som identifierare, så Internet Assigned Numbers Authority (IANA) tilldelar unika OID-träd baserat på företagsförfrågningar. En begäran om ett privat företagsnummer, som är en del av OID-trädet som är unikt för ett företag, behandlas kostnadsfritt på cirka 10 minuter. Du måste skaffa det innan du kan börja skapa anpassade schematillägg. Du kan begära ett privat företagsnummer på webbplatsen på www.iana.org/cgi-bin/assignments.pl.

När du väl har ett privat företagsnummer kan du skapa och organisera ett praktiskt taget obegränsat antal unika OID. Figuren visar strukturen för OID-trädet för vårt företags privata företagsnummer. OID byggs genom att lägga till grenar i ett träd, så många företag börjar med att skapa en AD Schema-gren (1.3.6.1.4.1.35686.1 i figuren) och bygger sedan en klassgren och en attributgren under den. Under var och en av dessa grenar tilldelas OID till varje nytt attribut eller klass. Figuren visar OID (1.3.6.1.4.1.35686.1.2.1) som tilldelats användarattributet myCorpImportantAttr. Det är mycket viktigt att förbereda en intern spårningsmekanism (t.ex. kalkylblad Excel- eller SharePoint-lista) vilket säkerställer unika OID.

Microsoft tillhandahåller ett skript som kan generera ett OID med ett slumpmässigt värde, men det finns ingen garanti för att det kommer att vara unikt. Det bästa sättet- Begär en unik filial i IANA-organisationen och använd den för schematillägg. Denna process är så enkel att du inte behöver använda Microsoft OID-genereringsskriptet.

De återstående två ingångsparameterär specifika för attribut och beror på deras typ. Extremt användbara länkattribut används för att lagra länkar mellan objekt i AD. De lagras som pekare i AD-databasen så att referenser uppdateras snabbt baserat på objektets plats i skogen. Två typiska exempel relaterade attribut - gruppmedlemskap (medlem och medlemAv) och chef/anställd relation (chef/direktrapporter). Begreppen framåtlänkar och bakåtlänkar gäller för länkade attribut. En framåtlänk är en redigerbar del av förhållandet mellan attribut. Till exempel, i fallet med gruppmedlemskap, är medlemsattributet för gruppen en framåtlänk; MemberOf-attributet för användaren är en bakåtlänk. När du redigerar ett gruppmedlemskap görs ändringar i medlemsattributet (framåtlänk) snarare än memberOf-attributet för medlemsobjektet (tillbaka länk).

För att definiera länkade attribut i AD måste du definiera två attribut (en framåtlänk och en bakåtlänk) och bifoga en länkidentifierare (länkID) till vart och ett av dessa attribut. Länk-ID:n måste vara unika inom skogen, och eftersom länk-ID:n också behövs av andra applikationer som kräver schemaförlängning, måste de göras globalt unika. Förr i tiden Microsoft företag publicerade länkidentifierare för tredjepartsorganisationer, men från och med Windows Server 2003 introducerade AD istället en speciell pekare som låter dig generera unika länkidentifierare när du lägger till ett schema länkat av ett par attribut.

AD antar att länk-ID:n är sekventiella nummer. Specifikt är framåtlänksattributet ett jämnt tal, och nästa nummer tilldelas baklänksattributet. Till exempel, för medlem och memberOf (gruppmedlemskap), är länk-ID för medlem 4 och länk-ID för memberOf är 5. Om det utökade schemat måste vara kompatibelt med Windows 2000-skogen måste du definiera statiska länk-ID på det sätt som beskrivs. I annat Du bör använda den automatiska länk-ID-genereringsprocessen implementerad i Windows Server 2003. För att använda den automatiska länk-ID-genereringsprocessen, följ dessa riktlinjer när du definierar en schematillägg. Under schematilläggsprocessen, som beskrivs senare i artikeln, är följande steg nödvändiga för att konstruera de associerade attributen (om de är en del av tillägget).

Förbered först en framåtlänk med länk-ID 1.2.840.113556.1.2.50. Observera att även om givet värde Link ID är ett OID, Microsoft reserverar helt enkelt detta OID-värde för att skapa Auto Link ID.

Ladda sedan om schemacachen. Efter detta skapar du ett bakåtlänksattribut med hjälp av länk-ID:t för vidarekopplingsattributnamnet och laddar om schemacachen.

Det andra unika (och även valfria) attributelementet är MAPI-identifieraren. MAPI-identifierare är en funktion i Exchange Server. Om du inte har Exchange eller behöver visa attributet i den globala adresslistan (GAL) kan du hoppa över det här avsnittet. MAPI-identifierare används för att visa attribut på en av egenskapssidorna i adressbok, till exempel mallen Allmänna användarinformation (se skärm). Om du till exempel vill visa anställds klassificering (heltidsanställd eller kontraktsanställd) i GAL, tilldela lämpligt attribut som MAPI-identifierare. Efter att ett MAPI-ID har tilldelats ett attribut kan du använda Exchange Details Templates Editor för att ange attributdata i en vy i GAL i Office Outlook.

MAPI-identifierare måste vara unika, precis som OID:er och referensidentifierare. Tidigare var det inte möjligt att generera unika MAPI-identifierare, så dessa identifierare var det alltid svag punkt när ordningen utökas. Lyckligtvis introducerade Windows Server 2008 ett sätt att automatiskt generera unika MAPI-ID:n i en katalog för att minska risken för dubbletter av MAPI-ID:n. För att använda den här funktionen, tilldela värdet 1.2.840.113556.1.2.49 till MAPI ID-attributet när du skapar attributet. AD genererar ett unikt MAPI ID för attributet efter att schemacachen har laddats om. Observera att även om detta värde är ett OID, är det reserverat i AD för att indikera automatisk generering av MAPI-ID:n, liknande den automatiska genereringen av länk-ID:n som beskrivs ovan.

Sammanfatta. När du planerar en kretsutbyggnad finns det tre kritiska ingångsparametrar att ta hänsyn till. Den första är namnet på klassen eller attributet; den andra är ett unikt prefix som tilldelas alla klasser och attribut; den tredje är OID. För att generera ett OID måste du begära en unik OID-gren från IANA-organisationen. Om ett länkat attributpar ska skapas krävs ett unikt länkidentifieringspar. Om du vill visa attributet i Exchange GAL-listan måste du använda en unik MAPI-identifierare. För både länk-ID:n och MAPI-ID:n är det att föredra att använda en automatisk genereringsprocess inom AD framför statiska värden.

Genomförandeplanering

Vid genomförandet anpassad tillägg schemat eller utöka schemat med leverantörsattribut och klasser, måste du ta preliminära planeringssteg för att skydda din AD-skogs integritet. Det första steget är att kontrollera schematillägget.

När du förbereder ett anpassat schematillägg, använd en tillfällig utvecklingsmiljö. AD Lightweight Directory Service (AD LDS) är tillgänglig som en gratis nedladdning för skrivbordet Windows-stationer XP och Windows 7. På arbetsstation du kan skapa en AD LDS-instans, bygga en schematillägg i isolerad miljö, och exportera sedan detta tillägg för senare import till test-AD-skogen. AD LDS-schemat är kompatibelt med AD, så du kan använda LDIFDE för export. Du kan importera ett färdigt schematillägg till en test-AD-skog och sedan verifiera att importen lyckades och att viktiga applikationer inte påverkades. För AD bör du planera att testa om importen lyckades och om replikeringen var korrekt i en testmiljö.

Om du testar en schematillägg i en test-AD-skog måste dess schema matcha produktionsskogen. I det här fallet kommer testningen att vara klar. Du kan använda verktyget AD Schema Analyzer (en del av AD LDS) för att upptäcka schemaskillnader mellan två AD-skogar. Artikeln "Exportera, jämför och synkronisera Active Directory Schemas" på TechNet (http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx) beskriver hur man importerar och exporterar schematillägg och hur man använder verktyget AD Schema Analyzer. Observera att det kan finnas vissa skillnader i schemajämförelser beroende på service pack och versioner av Windows, särskilt i attributindexering och raderingsflaggalagring.

För schematillägg som erhållits från andra källor (till exempel i samband med en kommersiell applikation) måste du se till att ändringarna som är kopplade till dem inte är riskabla. Tillsammans med alla indata som diskuterats ovan, var noga med att vara uppmärksam på ett antal andra omständigheter. Nedan är de viktigaste parametrarna att kontrollera:

• tillhandahålls i en LDIF-fil (flera LDIF-filer);
• korrektheten av attributprefix;
• registrerade OID;
• registrerade/autogenererade länkidentifierare;
• automatiskt genererade MAPI-identifierare.

LDIF-filer är en industristandard: alla schematillägg måste levereras i detta format. Applikationer tillåts använda en speciell importmekanism istället för LDIFDE för schematillägg. Men om tillägget levereras i ett annat format uppstår tvivel om dess riktighet och leverantörens tillförlitlighet. B visar ett exempel på LDIF för att skapa ett attribut i AD-schemat för att lagra information om en användares skostorlek. Följande egenskaper hos denna exempelkretsförlängning bör noteras.

• Attributet har prefix baserat på namnet på leverantörsföretaget (Brian Desmond Consulting, LLC: bdcllc).
• Det unika OID för attributet utfärdas med det privata företagsnumret som registrerats av leverantören.
• Attributet är indexerat (sökflaggor: 1) och tillgängligt i den globala katalogen (isMemberOfPartialAttributeSet: TRUE).

Du måste också verifiera att attributet är tillgängligt i den globala katalogen Partial Attribute Set (PAS) och att indexen som skapats för attributet är korrekta om attributet kommer att användas i LDAP-sökfilter. Det är också användbart att säkerställa att data som lagras i attributet är acceptabel för AD inom ramen för de begränsningar och riktlinjer som diskuterats ovan.

När schematillägget har testats och är redo för produktion, bör lämplig tidpunkt för denna operation väljas. Vanligtvis kan det slutföras under kontorstid. Det kommer att bli en märkbar ökning av CPU-belastningen när du kör Schema Wizard och en liten ökning av belastningen på domänkontrollanterna som replikerar ändringar. I stora företag Du kan uppleva en paus i replikeringen mellan domänkontrollanter under en period på fyra till sex timmar om du lägger till attribut till den partiella PAS-attributuppsättningen. Pauser kommer att åtföljas av felmeddelanden som indikerar problem med objekten, men kan vanligtvis ignoreras och kommer att försvinna av sig själva. Om domänkontrollanter har kopplats bort från replikering under en längre tid bör du börja felsöka.

Systematiskt tillvägagångssätt

Det finns ingen fara med att utöka AD-schemat om du vidtar grundläggande försiktighetsåtgärder. När du planerar nya schematillägg och när du validerar anpassade attribut och tredjepartsklasser, var uppmärksam på den identifierande informationen som är unik för varje klass eller attribut och se till att den är globalt unik.

Efter att ha kontrollerat dess integritet, porta den nya tillägget till en representativ testmiljö och verifiera att testmiljön fungerar korrekt och kritiska applikationer. Du kan sedan importera schematillägget till din produktionsmiljö.

Lista. Exempel på LDIF-poster

Dn: cn = bdcllcshoesize, cn = schema, cn = konfiguration, dc = x changeType: lägg till objektklass: topp objektklass: attributchema cn: sfsuliveserviceEntItLESTLEGEDID: 1.3.6.1.4.1.356866.100.1.1.2 attriButesyNEGEMENTS: 2.5.12 OmsElEgELEDELUEDEDUEDUEDEDEDUEDUEDEDEDUEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDEDELEDEUEDEDEDELE framme. showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Lagrar en användares skostorlek oMSyntax: 64 sökFlaggor: 1 lDAPDisplayName: bdcllcShoeSize-namn: bdcllcShoeSize schemaIDGUID:: JsAUhAzmlP hyllning et: SANT

Ingår i schemat formell beskrivning databasens innehåll och struktur Data aktiv Katalog. I synnerhet indikerar det alla egenskaper hos objekt och deras klasser. För varje objektklass definieras alla möjliga egenskaper, Extra tillval, samt vilken klass av objekt som är och kan vara en förfader till den aktuella klassen.

Installerar Active Directory skapas ett standardschema på den första domänkontrollanten som innehåller en beskrivning av de mest använda objekten och objektegenskaperna. Dessutom ger diagrammet en beskrivning av de interna objekten och egenskaperna för Active Directory.

Schemat är utökningsbart, så systemadministratören kan skapa nya typer av objekt och deras egenskaper, och lägga till nya egenskaper för de objekt som redan finns. Schemat implementeras och lagras med Active Directory i den globala katalogen. Den uppdateras automatiskt, så att en speciellt skapad applikation självständigt kan lägga till nya egenskaper och klasser till den.
Bygga ut standardschema inte lätt. Om du ändrar schemat felaktigt kan det störa både servern och hela katalogtjänsten. För att lösa detta problem behöver du nödvändig erfarenhet och kunskap. Så först och främst behöver du känna till namnreglerna.

Namnregler

Varje Aktivt objekt Katalog har ett specifikt namn. För att identifiera objekt i Active Directory används de olika upplägg namngivning, nämligen:

Sammansatta namn (DN);
-relativa sammansatta namn (RDN);
-Globalt unika identifierare (GUID);
-User Primary Names (UPN).

Varje Active Directory-objekt har sammansatt namn. Namnet är en objektidentifierare och innehåller tillräckligt med data för att lokalisera objektet i katalogen. Det kvalificerade namnet inkluderar namnet på domänen som innehåller objektet, och fullständig sökväg till honom. Till exempel kan användarnamnet Andrew Kushnir i server.com-domänen se ut så här:
DC=COM/DC=SERVER/CN=Användare/CK=Andrew Kushnir

Om det fullständiga kvalificerade namnet på ett objekt är okänt eller ändrat, kan du hitta objektet genom dess egenskaper, varav en är det relativa kvalificerade namnet (en del av det kvalificerade namnet). I det föregående exemplet skulle det relativa sammansatta namnet för Andrew Kushnir-objektet vara CN=Andrew Kushnir, och för det överordnade objektet skulle det vara CN=Usere.

Förutom det kvalificerade namnet, varje Active Directory-objekt har en globalt unik identifierare (GUID), vilket är ett 128-bitars nummer. ID:t ändras inte även efter att objektet har flyttats eller bytt namn. En globalt unik identifierare är unik för alla domäner, inklusive när ett objekt flyttas från en domän till en annan.
Det enklaste sättet att komma ihåg är det primära användarnamnet (UPN). Det primära namnet består av användarens förkortade namn plus DNS-namnet för domänen där objektet finns. Det primära användarnamnsformatet är följande:

Användarnamn, DNS-domäns suffixtecken

Till exempel är huvudanvändarnamnet Andrew Kushnir i serverdomänen. sojaböna skulle kunna se ut [e-postskyddad]. En användares primära namn är oberoende av deras efternamn, så användarobjektet kan flyttas eller byta namn utan att behöva ändras registreringsnamn användare i domänen.

Som ni vet varar ingenting för evigt, allt förändras, speciellt i en bransch som IT. När den väl har distribuerats utvecklas infrastrukturen ständigt, expanderar, förbättras, och det kommer en tid då du behöver lägga till en domänkontrollant som hanteras av mer än en person i din Active Directory. senare version operativ system.

Det verkar - vad är problemet? Men, som praxis visar, uppstår problem till stor del på grund av det faktum att systemadministratörer har lite kunskap om teori och är öppet förvirrad i denna fråga. Därför är det dags att ta reda på vad det är AD-schema och hur det förhåller sig till vårt fall.

AD-krets kallas en beskrivning av alla katalogobjekt och deras attribut. I huvudsak speglar diagrammet grundläggande struktur katalog och är av största vikt för att den ska fungera korrekt.

Nya versioner av operativsystemet innehåller nya objekt och attribut, så för att de ska fungera korrekt som domänkontrollanter måste vi uppdatera schemat.

Det verkar tydligt, men inte helt, så låt oss gå vidare till vanliga misstag och missuppfattningar.

• Att uppdatera schemat är nödvändigt för att inkludera datorer som kör nyare versioner av Windows i domänen. Detta är inte sant, inte ens de senaste Windows-versioner kan fungera ganska framgångsrikt i en domän på Windows 2000-nivå utan att uppdatera schemat. Men om du uppdaterar schemat kommer inget dåligt att hända.

• För att inkludera en kontroller som kör ett nyare operativsystem i en domän, måste du uppgradera domänen (skogen). Detta är inte heller sant, men till skillnad från det tidigare fallet kommer denna operation att göra omöjligt att använda domänkontrollanter som kör ett operativsystem som är lägre än dess driftsläge. Därför, i händelse av ett fel, måste du återställa din AD-struktur från en säkerhetskopia.

Vi kommer också att uppmärksamma er på driftsättet för skogen och domänen. Domäner som ingår i skogen kan ha olika lägen fungerar, till exempel kan en av domänerna fungera i Windows-läge 2008, och resten i Windows 2003-läge. Skogens driftschema kan inte vara högre än operativsystemet för den äldsta domänen. I vårt exempel kan skogsdriftläget inte vara högre än Windows 2003.

Samtidigt hindrar skogens lägre driftläge inte på något sätt användningen av ett högre driftläge i domänen det enda som krävs för detta är att uppdatera schemat.

Efter att ha bekantat oss med teorin, låt oss gå vidare till praktiskt exempel. Låt oss säga att vi har en domän på Windows 2000-nivå (blandat läge) - mest låg nivå AD - som har en styrenhet under Windows kontroll 2003, och vårt mål är att skapa ny styrenhet för att ersätta den som misslyckades.

Den nya servern kör Windows 2008 R2. Observera att vi inte hade några svårigheter med att aktivera av denna server till en befintlig domän.

I vårt fall ligger alla roller på samma controller, så vi kopierar mappen \support\adprep på HDD(i vårt fall till roten av C:-enheten) och fortsätt med att uppdatera skogsschemat. För att slutföra operationen måste ditt konto inkluderas i följande grupper:

• Schema administratörer
• Företagsadministratörer
• Administratörer för domänen där schemaägaren finns

För att uppdatera skogsschemat, kör kommandot:

C:\adprep\adprep /forestprep

Läs standardvarningen och fortsätt genom att klicka C, då Stiga på.

Schemauppdateringsprocessen börjar. Som du kan se kommer dess version att ändras från 30 (Windows 2003) till 47 (Windows 2008 R2).

Efter uppdatering av skogsschemat måste du uppdatera domänschemat. Innan du gör detta bör du se till att domänen körs åtminstone i Windows 2000-läge (native-läge). Som vi minns fungerar vår domän i blandat läge, så vi bör ändra domänens driftläge till primärt eller uppgradera det till Windows 2003. Eftersom vi på denna domän inte har kontroller som kör Windows 2000, skulle det vara mest rimligt att uppgradera domänen läge.

För att framgångsrikt uppdatera domänschemat bör denna operation utföras på Infrastrukturägare och har rättigheter Domänadministratör. Vi kör kommandot:

C:\adprep\adprep /domainprep

Och läs noga informationen som visas. När du uppgraderar ett domänschema från Windows 2000 eller Windows 2003 måste du ändra behörigheter filsystem För grupppolicyer. Denna operation utförs en gång och i framtiden, till exempel uppdatering av schemat från 2008 års nivå till 2008 R2, måste den utföras. För att uppdatera GPO-behörigheter anger du kommandot:

C:\adprep\adprep /domainprep /gpprep

AD-versioner sedan Windows 2008 har introducerat en ny typ av domänkontrollant: en skrivskyddad domänkontrollant (RODC), om du planerar att distribuera en sådan kontrollenhet måste du förbereda ett diagram. I allmänhet rekommenderar vi att du gör det denna operation oavsett om du ska installera RODC inom en snar framtid eller inte.

Denna operation kan utföras på vilken domänkontrollant som helst, men du måste vara medlem i Företagsadministratörer Och Mästare i namngivning Och Infrastrukturmästare måste finnas tillgänglig.

C:\adprep\adprep /rodcprep

Som du kan se orsakar uppdatering av domänschemat, om det är korrekt planerat, inga svårigheter, men i alla fall bör du komma ihåg att detta är en oåterkallelig operation och ha de nödvändiga säkerhetskopiorna till hands.