En katalogtjeneste brukes til å identifisere brukere og ressurser på nettverket. Sammenlignet med tidligere versjoner av Windows, Microsoft Windows I 2003 ble funksjonene til Active Directory utvidet betydelig. Active Directory gir et enhetlig nettverksadministrasjonsverktøy som gjør det enkelt å legge til, fjerne og flytte brukere og ressurser.
Vi introduserer Active Directory
Active Directory-verktøy lar deg designe katalogstrukturen slik organisasjonen din trenger. I denne leksjonen vil du lære om bruk av Active Directory-objekter og formålet med komponentene.
Etter å ha studert materialet i denne leksjonen, vil du kunne:
forklare formålet med objektets attributter, og Aktive skjemaer Katalog;
definere og beskrive funksjonaliteten til Active Directory-komponenter.
Active Directory-objekter
Som alle tjenester som gjør informasjon tilgjengelig og nyttig, lagrer Active Directory informasjon om nettverksressurser... Disse ressursene, som brukerdata, beskrivelser av skrivere, servere, databaser, grupper, datamaskiner og sikkerhetspolicyer, kalles objekter.
Et objekt er et separat navngitt sett med attributter som representerer en nettverksressurs. Attributter til et objekt er dets egenskaper i katalogen. For eksempel kan brukerkontoattributter inkludere for- og etternavn, avdeling og e-postadresse (Figur 2-1)
I Active Directory kan objekter organiseres i klasser, det vil si i logiske grupper. Et eksempel på en klasse er en gruppering av objekter som representerer brukerkontoer, grupper, datamaskiner, domener eller organisasjonsenheter.
Merk Objekter som er i stand til å inneholde andre objekter kalles beholdere. Et domene er for eksempel et beholderobjekt som kan inneholde brukere, datamaskiner og andre objekter.
Nøyaktig hvilke objekter som kan lagres i Active Directory bestemmes av skjemaet.
OppleggAktivKatalog
Et Active Directory-skjema er en liste over definisjoner som definerer typene objekter som kan lagres i Active Directory og typen informasjon om dem. Disse definisjonene i seg selv lagres også som objekter, slik at Active Directory administrerer dem gjennom de samme operasjonene som brukes for andre objekter i Active Directory.
Det er to typer definisjoner i et skjema: attributter og klasser. De kalles også skjemaobjekter eller metadata.
Attributter er definert separat fra klasser. Hvert attributt defineres bare én gang og kan brukes på tvers av flere klasser. Beskrivelse-attributtet brukes for eksempel i mange klasser, men det defineres bare én gang i skjemaet for å sikre integriteten.
Klasser, også kalt objektklasser, beskriver hvilke Active Directory-objekter som kan opprettes. Hver klasse er en samling av attributter. Når et objekt opprettes, lagrer attributter informasjonen som beskriver det. For eksempel inkluderer attributtene til User-klassen Nettverksadresse, Hjemmekatalog osv. Hvert objekt i Active Directory er en forekomst av en objektklasse.
Windows 2000 Server inkluderer et sett med basisklasser og attributter. Ved å definere nye klasser og nye attributter for eksisterende klasser, kan erfarne utviklere og nettverksadministratorer utvide skjemaet dynamisk. Hvis du for eksempel trenger å lagre informasjon om brukere som ikke er definert i skjemaet, kan du utvide skjemaet for klassen Users. En slik utvidelse av ordningen er imidlertid en ganske komplisert operasjon med mulige alvorlige konsekvenser. Siden skjemaet ikke kan slettes, men bare deaktiveres, og det replikeres automatisk, må du forberede og planlegge utvidelsen.
Det er vanskelig å undervurdere viktigheten av "Active Directory Schema" for nettverk bygget på toppen av et Active Directory-domenemiljø. Dette er grunnlaget for AD-teknologien, og det er veldig viktig å forstå prinsippene for driften. De fleste systemadministratorer tar ikke nok hensyn til ordningen på grunn av at de sjelden må forholde seg til den. I denne artikkelen vil jeg fortelle deg hva en skjemaversjon er, hvorfor vi trenger å vite den og, viktigst av alt, hvordan du kan se den gjeldende versjonen.
Først av alt, noen få ord om selve skjemaet, hvert objekt opprettet i Active Directory, det være seg en bruker eller en datamaskin, har visse parametere kalt attributter. Det meste enkelt eksempel«Etternavn»-attributtet til brukerobjektet kan brukes. Skjemaet definerer hvilke objekter vi kan lage i Active Directory og hvilke attributter de skal ha.
Active Directory lar flere domenekontrollere brukes innenfor samme organisasjon basert på forskjellige versjoner Windows OS. Nemlig basert på Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Siden disse versjonene ble utgitt i forskjellige år, og hver nye versjon har mer funksjonalitet enn den forrige, er forståelsen av ordningen forskjellig for hvert operativsystem. Derfor, når du legger til en ny kontroller til Windows basert Server 2008 til en organisasjon hvor eksisterende kontrollere er bygget på Windows Server 2003, måtte du kjøre verktøyet " Adprep". Ved å gjøre dette har du oppdatert organisasjonskartet til det nivået det fungerer med. Windows Server 2008.
Skjemaoppdateringsprosessen ble utført før installasjonen av den første Windows-kontroller Server 2008 og selve prosedyren for å installere en ny kontroller er kanskje ikke utført. Hvis du akkurat har begynt å jobbe med en slags Active Directory-organisasjon og ikke vet hvilke handlinger som ble utført før du ble med, for å forstå fullstendigheten av strukturen, må du vite på hvilket nivå ordningen til gjeldende organisasjonen fungerer.
Mulige skjemaversjoner:
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
Selv om alle kontrollerene i organisasjonen din kjører Windows Server 2003 R2, og skjemaversjonen viser "44", bør du ikke bli overrasket, dette indikerer at skjemaet allerede er oppgradert til Windows-nivå Server 2008 RTM, men selve kontrolleren ble ikke installert av en eller annen grunn.
Du kan se versjonen av skjemaet på flere måter, den enkleste er måten å bruke "DSQuery"-verktøyet. For dette i kommandolinje du må skrive inn en kommando med følgende parametere:
"Dsquery * cn = skjema, cn = konfigurasjon, dc = domenenavn, dc = local -scope base -attr objectVersion"
Naturligvis i delen " dc = domenenavn, dc = lokal " du må erstatte ditt eget domenenavn. (Eksempel: dc = microsoft, dc = com )
Resultatet av å skrive inn kommandoen er å få attributtet " Objektversjon", Som vil være skjemaets versjonsnummer:
Ris. 1 Få skjemaversjonen gjennom "DSQuery"-verktøyet.
Den andre metoden er lengre og involverer bruk av en snap " ADSIEdit.msc "... For å se versjonen av skjemaet, må du koble til Active Directory-delen av skjemaet.
"CN = Skjema, CN = Konfigurasjon, DC = domene, DC = lokal"
Og finn verdien av attributtet " objektversjon".
Fig. 2 Få versjonen av skjemaet gjennom snap-in " ADSIEdit.msc».
Når du kjenner til versjonen av skjemaet, kan du alltid si med sikkerhet om skjemaet må oppdateres og om nødvendig til hvilket nivå.
Det skal bemerkes at skjemaoppdateringer kan utføres av programvare som er tett integrert med Active Directory. Den lyseste Microsoft eksempel Exchange Server... Og ofte i en organisasjonsplanlegging Utvekslingsimplementering Server, er det nødvendig å finne ut om skjemautarbeidelsen er utført? Og i så fall, hvilken versjon av Exchange Server. På dette øyeblikket Det er tre versjoner av Exchange som fungerer med Active Directory, men det er seks alternativer for å endre skjemaet. Forstå om Active Directory-skjemaet har endret seg Exchange-server du kan bruke attributtet " rangeUpper ", som tar følgende verdier:
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, skjer skjemaoppdateringen også når du installerer et sett med oppdateringer SP3 for Exchange Server 2000/2003 og SP1 for Exchange 2007.
Se verdien av attributtet " rangeUpper " du kan bruke DSQuery-verktøyet:
"dsquery * CN = ms-Exch-Schema-Version-Pt, cn = skjema, cn = konfigurasjon, dc = domenenavn, dc = lokal -scope base -attr rangeUpper"
Ris. 3 Får attributtet " rangeUpper " via DSQuery-verktøyet.
Hvis etter å ha skrevet inn denne kommandoen, returneres et svar som indikerer fraværet av attributtet " rangeUpper " det kan konkluderes med at ordningen ikke er endret.
Oppdateringsprosessen for skjema er veldig viktig poeng for hver organisasjoner Aktiv Directory, så du bør unngå unødvendige, uberettigede handlinger. Forstå essensen av attributtene " objectVersion "og« rangeUpper " gir teknikeren en fordel når han jobber med Active Directory i en ukjent organisasjon, og er også et hjelpeverktøy for å løse problemer.
Materiale levert av ressursen
04/07/2011 Brian Desmond
Det tilfeldigvis er at Active Directory (AD)-administratorer og IT-ledere vanligvis er forsiktige med å utvide AD-skjemaet. Mye av frykten stammer fra Microsofts Windows 2000-dokumentasjon, som fremstiller skjemautvidelse som en kompleks operasjon som krever ekstrem forsiktighet. Men med rimelig planlegging er skjemautvidelse helt risikofri.
AD-skjemaet definerer strukturen til dataene som er lagret i katalogen. AD støtter naturlig mange typer objekter (for eksempel brukere) og attributter (for eksempel for- og etternavn). Hvis det underliggende AD-skjemaet ikke passer godt med dataene du vil lagre i katalogen, kan du supplere det med egendefinerte objekter og attributter.
Vanligvis utvides AD-skjemaet av flere grunner, hvorav den vanligste i mange organisasjoner er implementeringen av en applikasjon som krever skjemautvidelse. Illustrerende eksempel - Microsoft Exchange... Noen ganger leverandører programvare trenger å utvide skjemaet for å være kompatibelt med applikasjonene deres. Ofte utvides skjemaet for applikasjoner selvutviklet eller for å gjøre det enklere å lagre bedriftsdata i AD.
Oppbevaringsalternativer
Når du planlegger en skjemautvidelse, spesielt for interne applikasjoner, først og fremst må du finne ut om dataene er egnet for lagring i AD. Det er spesielt praktisk å lagre relativt statiske (sjeldent skiftende) data i AD som brukes over hele selskapet (replisert på tvers av domenegrenser) og som ikke er konfidensielle (det anbefales for eksempel ikke å lagre fødselsdato, personkortnummer, osv. i AD).
Hvis dataene ikke oppfyller disse kriteriene, men fortsatt må være plassert i LDAP-katalogen, er det andre alternativet optimalt. AD Lightweight Directory Services (AD LDS, tidligere ADAM) - frittstående versjon AD, som kan fungere som en tjeneste på en server, et domenemedlem (eller domenekontroller - DC), og, som AD, håndtere forespørsler rettet til LDAP. Behovet for å være vert for AD-domenekontrollere for autentisering og applikasjonsstøtte er ikke en irriterende begrensning, men muligheten til å strengt kontrollere hvem som kan lese dataene og retningen for datareplikering ved å plassere AD LDS-forekomster på passende steder.
Primitiver for datalagring
To termer spiller en nøkkelrolle for å forstå AD-skjemaet: klasse og attributt. Alle AD-elementer, inkludert skjema, er definert i form av klasser og attributter. Klasser er typene data du vil lagre. For eksempel er bruker en klasse i AD, akkurat som datamaskin. Attributter er egenskaper til klasser. Brukerklassen har et fornavn (gitt navn) attributt og et etternavn (sn) attributt. Klassen "datamaskin" har attributtet " operativsystem". Et AD-skjema er definert i form av to klasser: classSchema for classes og attributeSchema for attributes.
I analogi med en typisk database kan du sammenligne klasser med tabeller i en database, og attributter til kolonner i en tabell. Men husk at strukturen til AD Directory Information Tree (DIT)-databasen faktisk er ganske annerledes.
Når du løser problemet med å lagre data av en ny type i AD, må du tenke på hvordan dataene er kartlagt til klasser og attributter. I det meste typiske tilfeller det er nok å legge til et attributt til en eksisterende klasse (for eksempel en bruker eller en gruppe). Hvis du bare vil spare ny kodebit objektdata eksisterende type(som en bruker), prøv først å finne de riktige attributtene blant de som er tilgjengelige i AD. Skjemaet inneholder tusenvis av attributter, hvorav de fleste ikke er involvert. Derfor for eksempel for å lagre informasjon om postadresse bruker, kan du bruke fysiskDeliveryOfficeName-attributtet.
Å tildele et attributt på nytt for andre formål enn den opprinnelige bruken er en dårlig tilnærming. Tenk deg at et attributt har blitt tildelt på nytt, og så kjøpes en applikasjon som bruker den attributten til sitt opprinnelige formål. Skal oppfylle dobbelt arbeid, siden det er nødvendig å rekonfigurere gammel applikasjon ved å bruke attributtet, og flytt deretter dataene. Generelt er det alltid tryggere å legge til et tilpasset attributt.
Men noen ganger er bare en klassebasert tilnærming mulig. I to tilfeller er det mer praktisk å legge til en ny klasse i skjemaet enn å bruke attributter. Den første er behovet for å spore ny type data i katalogen. Hvis du for eksempel ønsker å spore bilene til en bedrift i AD, kan du definere en ny bilklasse i skjemaet. Et annet tilfelle er en-til-mange-kartlegging.
Et perfekt eksempel er Microsoft Exchange Server 2010. Hver mobilenhet du synkroniserer med Exchange ved hjelp av ActiveSync lagres som en forekomst av en spesiell msExchActiveSyncDevice-objektklasse i katalogen. Disse mobile enheter lagret som underordnede objekter til brukeren, eieren av enheten. Denne strukturen gir en kartlegging et stort antall attributter (for hver enhet) til én bruker.
Inndata for skjemautvidelse
For å forberede en skjemautvidelse må du samle inn en rekke inndata. Først da kan en spesiell egenskap eller klasse implementeres i utviklingsmiljøet. Mange innspill må være globalt unike, så det er viktig å gjøre det nødvendige forarbeidet. Samtidig truer uaktsomhet med farlige konsekvenser.
Velg først navnet på klassen eller attributtet. Den viktigste delen av navnet er prefikset. Navnene på attributter og klasser i skjemaet (og i kundeskjemaet tredjepartsapplikasjon) må være unik, så å legge til et prefiks vil sikre at det ikke er konflikter mellom attributt-ID-er.
Vanligvis brukes det forkortede firmanavnet som et prefiks. For eksempel bruker jeg bdcLLC som et prefiks for attributtene til selskapet vårt Brian Desmond Consulting LLC. For ABC-selskap kan prefikset abcCorp brukes. Pass på å ta vare på det unike med prefikset, siden generelt register det er ingen prefikser. Hvis selskapet har et typisk eller forkortet navn, finn ut hvordan du gjør det unikt.
Når du har valgt navnet, må du tilordne en objektidentifikator (OID) til attributtet eller klassen. OID-er - tilleggskomponent som må være globalt unikt. AD (mer generelt, LDAP) er ikke det eneste rammeverket som bruker OID-er som en identifikator, så Internet Assigned Numbers Authority (IANA) tildeler unike OID-trær etter forespørsel fra selskaper. En forespørsel om et privat foretaksnummer, som er en del av OID-treet som er unikt for et selskap, betjenes gratis på ca. 10 minutter. Du må få det før du begynner å lage tilpassede skjemautvidelser. Du kan be om et privat bedriftsnummer på www.iana.org/cgi-bin/assignments.pl.
Med et privat bedriftsnummer kan du opprette og organisere et praktisk talt ubegrenset antall unike OID-er. Figuren viser OID-trestrukturen for vårt selskaps Private Enterprise Number. OID-er bygges ved å legge til grener i treet, så mange selskaper starter med å lage en AD Schema-gren (1.3.6.1.4.1.35686.1 i figuren) og deretter en klassegren og en attributtgren under den. Under hver av disse grenene tildeles OIDer til hver nye attributt eller klasse. Figuren viser OID (1.3.6.1.4.1.35686.1.2.1) som er tildelt det tilpassede attributtet myCorpImportantAttr. Det er svært viktig å utarbeide en intern sporingsmekanisme (f.eks. regneark Excel- eller SharePoint-liste) for å sikre at OID-er er unike.
| Tegning. OID hierarki |
Microsoft leverer et skript som kan generere en OID med en tilfeldig verdi, men det er ingen garanti for at det vil være unikt. Den beste måten- be om en unik filial i IANA-organisasjonen og bruk den til skjemautvidelser. Prosessen er så enkel at du ikke trenger å bruke Microsoft OID-genereringsskriptet.
De resterende to inndataparametere er spesifikke for attributter og avhenger av deres type. Bundne attributter er ekstremt nyttige for å lagre koblinger mellom objekter i AD. De lagres som pekere i AD-databasen, slik at lenkene oppdateres i tide for å gjenspeile objektets plassering i skogen. To typiske eksempler relaterte attributter er gruppemedlemskap (medlem og medlemAv) og leder/medarbeiderforhold (leder/directReports). Konseptene viderekoblinger og tilbakekoblinger gjelder for koblede attributter. Foroverlenken er den redigerbare delen av forholdet mellom attributter. For eksempel, når det gjelder gruppemedlemskap, er medlemsattributtet for gruppen en viderekobling; memberOf-attributtet for brukeren er tilbakekoblingen. Når du redigerer gruppemedlemskap, gjøres endringene i member-attributtet (forward link), ikke memberOf-attributtet til medlemsobjektet (back link).
For å definere lenkede attributter i AD, må du definere to attributter (forward link og backlink) og knytte en lenkeidentifikator (linkID) til hver av disse attributtene. Link-ID-er må være unike i skogen, og siden lenke-ID-er kreves av andre applikasjoner som krever skjemautvidelser, må de være globalt unike. I fortid Microsoft publiserte lenkeidentifikatorer for utenforstående organisasjoner, men fra og med Windows Server 2003, i stedet dukket det opp en spesiell peker i AD som lar deg generere unike identifikatorer for koblinger når du supplerer et skjema knyttet til et par attributter.
AD antar koblings-ID-er er sekvensnumre. Spesielt er forward link-attributtet et partall, og følgende nummer er tilordnet tilbakelink-attributtet. For eksempel, for medlem og memberOf (gruppemedlemskap), er lenkeidentifikatoren for medlem 4, og lenkeidentifikatoren for memberOf er 5. Hvis det utvidede skjemaet ditt skal være kompatibelt med Windows 2000-skogen, må du definere statiske lenkeidentifikatorer i den samme veien. V ellers du bør bruke den automatiske lenke-ID-genereringsprosessen i Windows Server 2003. For å bruke den automatiske lenke-ID-genereringsprosessen, følg retningslinjene nedenfor når du definerer en skjemautvidelse. I prosessen med å utvide skjemaet, som beskrevet senere i artikkelen, er trinnene som er gitt nødvendige for å konstruere de tilknyttede attributtene (hvis de er en del av utvidelsen).
Forbered først lenken på forhånd ved å bruke lenke-ID 1.2.840.113556.1.2.50. Merk at selv om gitt verdi koblingsidentifikator er en OID, Microsoft reserverer ganske enkelt denne OID-verdien for å generere den automatiske koblingsidentifikatoren.
Last deretter skjemabufferen på nytt. Deretter oppretter du et tilbakekoblingsattributt ved å bruke lenke-ID-en til fremkoblingsattributtnavnet og laster inn skjemabufferen på nytt.
Det andre unike (og også valgfrie) attributtelementet er MAPI-identifikatoren. MAPI-ID-er er en funksjon i Exchange Server. Hvis du ikke har Exchange eller ønsker å vise attributtet i den globale adresselisten (GAL), kan du hoppe over denne delen. MAPI-ID-er brukes til å vise attributter på en av egenskapssidene i adressebok for eksempel malen for generelle brukerdetaljer (se skjermbildet). Hvis du for eksempel ønsker å vise klassifiseringen av ansatte (ansatte eller kontraktsmessige) i GAL-listen, tilordne det riktige attributtet som en MAPI-identifikator. Etter at MAPI-IDen er tilordnet attributtet, kan du bruke Exchange Details Templates Editor til å legge inn attributtdataene i en GAL-visning i Office Outlook.
MAPI-ID-er må være unike, så vel som OID-er og koblings-IDer. Tidligere var det ikke mulig å generere unike MAPI-identifikatorer, så disse identifikatorene endte alltid opp svakt punkt når du utvider skjemaet. Heldigvis introduserer Windows Server 2008 en måte å automatisk generere unike MAPI-IDer i en katalog for å redusere risikoen for dupliserte MAPI-IDer. For å bruke denne funksjonen, sett verdien 1.2.840.113556.1.2.49 til MAPI ID-attributtet når du oppretter attributtet. AD genererer en unik MAPI-identifikator for attributtet etter å ha lastet skjemabufferen på nytt. Merk at selv om denne verdien er en OID, er den reservert av AD for å indikere automatisk generering av MAPI-ID-er, lik den automatiske genereringen av link-IDer beskrevet ovenfor.
Oppsummer. Det er tre kritiske inngangsparametere å vurdere når du planlegger skjemautvidelsen. Den første er navnet på klassen eller attributtet; den andre er et unikt prefiks tildelt alle klasser og attributter; den tredje er OID. For å generere en OID må en unik OID-gren bes om fra IANA-organisasjonen. Hvis du skal lage et koblet attributtpar, kreves et unikt par med lenkeidentifikatorer. Hvis du vil vise attributtet i Exchange GAL, må du bruke en unik MAPI identifikator. For både koblings-IDer og MAPI-IDer er bruk av en automatisk genereringsprosess i AD å foretrekke fremfor statiske verdier.
Gjennomføringsplanlegging
Ved introduksjon tilpasset utvidelse skjema, eller utvide et skjema med leverandørattributter og klasser, må du ta foreløpige planleggingstrinn for å beskytte integriteten til AD-skogen din. Det første trinnet er å teste skjemautvidelsen.
Når du forbereder en tilpasset skjemautvidelse, bruk et midlertidig utviklingsmiljø. AD Lightweight Directory Service (AD LDS) er en gratis nedlasting for jobb Windows-stasjoner XP og Windows 7. På arbeidsstasjon du kan opprette en AD LDS-forekomst, bygge en skjemautvidelse i isolert miljø og eksporter deretter denne utvidelsen for import til AD-testskogen. AD LDS-skjemaet er AD-kompatibelt, så du kan bruke LDIFDE for eksport. Du kan importere den ferdige skjemautvidelsen til en AD-testskog og deretter bekrefte at importen var vellykket og at kritiske applikasjoner ikke ble skadet. For AD bør du planlegge å teste at importen var vellykket og at replikering var riktig i et testmiljø.
Hvis du skal teste skjemautvidelsen i en test AD-skog, må skjemaet samsvare med produksjonsskogen. I dette tilfellet vil testingen være fullført. Du kan bruke AD Schema Analyzer-verktøyet (inkludert med AD LDS) for å finne skjemaforskjeller mellom to AD-skoger. TechNet-artikkelen "Export, Compare, and Synchronize Active Directory Schemas" (http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx) beskriver hvordan du importerer og eksporterer skjemautvidelser, og hvordan du bruker AD Schema Analyzer-verktøyet. Vær oppmerksom på at det kan være noen forskjeller når du sammenligner skjemaer, avhengig av oppdateringspakker og Windows-versjoner, spesielt når det gjelder indeksering av attributter og lagring av slettemerker.
For skjemautvidelser hentet fra andre kilder (for eksempel sammen med en kommersiell applikasjon), må du sørge for at de tilknyttede endringene ikke er risikable. Sammen med alle innspillene som er diskutert ovenfor, sørg for å ta hensyn til en rekke andre forhold. Nedenfor er de viktigste parameterne for å sjekke:
- leveres i en LDIF-fil (flere LDIF-filer);
- riktigheten av attributtprefikser;
- registrerte OIDer;
- registrerte / automatisk genererte lenkeidentifikatorer;
- automatisk genererte MAPI-identifikatorer.
LDIF-filer er en industristandard: alle skjemautvidelser må leveres i dette formatet. Det er tillatt for applikasjoner å bruke en spesiell importmekanisme i stedet for LDIFDE for skjemautvidelser. Men hvis utvidelsen leveres i et annet format, oppstår det tvil om dens korrekthet og påliteligheten til leverandøren. C viser et LDIF-eksempel for å lage et attributt i et AD-skjema for å lagre informasjon om en brukers skostørrelse. Legg merke til følgende funksjoner i denne eksempelskjemautvidelsen.
- Attributtet er prefikset med leverandørnavnet (Brian Desmond Consulting, LLC: bdcllc).
- Den unike OID-en for attributtet utstedes ved å bruke det private bedriftsnummeret som er registrert av leverandøren.
- Attributtet er indeksert (søk flagg: 1) og tilgjengelig i den globale katalogen (isMemberOfPartialAttributeSet: TRUE).
Du må også bekrefte at attributtet er tilgjengelig i den globale katalogen for partielt attributtsett (PAS) og at indeksene som er opprettet for attributtet er korrekte hvis attributtet skal brukes i LDAP-søkefiltre. Det er også nyttig å sikre at dataene som er lagret i attributtet er akseptable for AD i sammenheng med begrensningene og beste praksis diskutert ovenfor.
Når skjemautvidelsen er testet og klargjort for produksjonsimplementering, bør timingen være passende for denne operasjonen. Dette kan vanligvis gjøres i arbeidstiden. Prosessorbelastningen vil øke merkbart når du kjører skjemaveiviseren, og litt - på domenekontrollerne som replikerer endringene. V store selskaper replikering mellom domenekontrollere kan settes på pause i fire til seks timer hvis du legger til attributter til PAS-delattributtsettet. Suspensjoner vil bli ledsaget av feilmeldinger som indikerer problemer med objektene, men vanligvis kan de ignoreres og de vil forsvinne av seg selv. Hvis domenekontrollere har vært tatt ut av replikering i lang tid, bør du starte feilsøking.
Planlagt tilnærming
Det er trygt å utvide AD-skjemaet hvis du tar noen grunnleggende forholdsregler. Når du planlegger nye skjemautvidelser, og når du validerer tilpassede attributter og klasser fra tredjepartsleverandører, bør du vurdere å identifisere informasjon som er unik for hver klasse eller attributt og sikre at den er globalt unik.
Etter å ha kontrollert integriteten, porter den nye utvidelsen til et representativt testmiljø og sørg for at testmiljøet fungerer korrekt og kritiske applikasjoner... Du kan deretter importere skjemautvidelsen til produksjonsmiljøet ditt.
Oppføring. Eksempel på LDIF-poster
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.Synt.Syntal attribute1.Synt.S. showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Lagrer en brukers skostørrelse oMSyntaks: 64 søkFlagg: 1 lDAPDisplayName: bdcllcShoeSize navn: bdcllcShoeSize schemaIDGUID :: Js + e
Ordningen inkluderer formell beskrivelse innhold og struktur i basen Data aktive Katalog. Spesielt viser den alle egenskapene til objekter og deres klasser. For hver klasse av objekter er alle mulige egenskaper definert, Ekstra alternativer, samt hvilken klasse av objekter som er og kan være stamfaren til den gjeldende klassen.
Installerer Active Directory, opprettes et standardskjema på den første domenekontrolleren som inneholder en beskrivelse av de mest brukte objektene og objektegenskapene. I tillegg gir diagrammet en beskrivelse av de interne objektene og egenskapene til Active Directory.
Skjemaet er utvidbart, slik at systemadministratoren kan opprette nye typer objekter og deres egenskaper, legge til nye egenskaper for de objektene som allerede eksisterer. Skjemaet er innebygd og lagret sammen med Active Directory i den globale katalogen. Den oppdateres automatisk, slik at en spesiallaget applikasjon uavhengig kan legge til nye egenskaper og klasser til den.
Utvide standard ordning ikke lett. Feil endring av skjemaet kan forstyrre både serveren og hele katalogtjenesten. For å løse dette problemet bør man ha nødvendig erfaring og kunnskap. Så først av alt må du kjenne navneglene.
Navneregler
Hver Aktivt objekt Katalog har et spesifikt navn. For å identifisere objekter i Active Directory brukes ulike ordninger navnekonvensjoner, nemlig:
Fornemme navn (DN)
Relative distinguished Names (RDN)
-globale unike identifikatorer (GUIDs);
- Primære brukernavn (UPN).
Hvert Active Directory-objekt har sammensatt navn... Navnet er en identifikator for objektet og inneholder nok data til å finne objektet i katalogen. Det særegne navnet inkluderer navnet på domenet som inneholder objektet, og full vei til ham. For eksempel kan det sammensatte brukernavnet Andrew Kushnir på server.com-domenet se slik ut:
DC = COM / DC = SERVER / CN = Brukere / CK = Andrew Kushnir
Hvis det fullstendige navnet på et objekt er ukjent eller endret, kan du finne objektet ved dets egenskaper, hvorav en er det relative særnavnet (en del av det særegne navnet). I det forrige eksemplet vil det relative særegne navnet for Andrew Kushnir-objektet være CK = Andrew Kushnir, og for det overordnede objektet, CN = Usere.
I tillegg til det utmerkede navnet, hvert Active Directory-objekt har en globalt unik identifikator (GUID), som er et 128-biters tall. Identifikatoren endres ikke selv etter at objektet har blitt flyttet eller omdøpt. En globalt unik identifikator er unik på tvers av alle domener, inkludert når et objekt flyttes fra ett domene til et annet.
Den enkleste måten å huske på er brukerens primærnavn (UPN). Basenavnet består av det forkortede brukernavnet pluss DNS-navnet til domenet hvor objektet befinner seg. Formatet på brukerens primære navn er som følger:
Brukernavn, DNS-domene-suffikstegn
For eksempel er det primære brukernavnet Andrew Kushnir på serveren. soyabønner kan se ut [e-postbeskyttet] Brukerens hovednavn er uavhengig av brukerens navn, så brukerobjektet kan flyttes eller gi nytt navn uten å måtte endres registreringsnavn bruker i domenet.
Som du vet er ingenting evig, alt forandrer seg, spesielt i en industri som IT. Når den er distribuert, utvikles, utvides, forbedres infrastrukturen hele tiden, og det kommer en tid når du trenger å legge inn en domenekontroller i Active Directory med mer enn senere versjon operativsystem.
Det ser ut til - hva er problemet? Men som praksis viser, oppstår det problemer, hovedsakelig på grunn av det systemadministratorer har lite kunnskap om teori og er ærlig talt forvirret i dette problemet... Derfor er det på tide å finne ut hva det er AD-skjema og hvordan det forholder seg til vår sak.
AD-skjema er en beskrivelse av alle katalogobjekter og deres attributter. I hovedsak reflekterer diagrammet grunnleggende struktur katalog og er av største betydning for at den skal fungere.
Nyere OS-versjoner inneholder nye objekter og attributter, så vi må oppdatere skjemaet for at de skal fungere som domenekontrollere.
Det ser ut til å være forståelig, men ikke helt, så la oss gå videre til vanlige feil og misoppfatninger.
- En skjemaoppdatering er nødvendig for å inkludere PC-er som kjører nyere versjoner av Windows i domenet. Ikke engang den nyeste Windows-versjoner kan kjøre ganske bra i et Windows 2000-nivådomene uten å oppdatere skjemaet. Selv om du oppdaterer skjemaet, vil ingenting forferdelig skje.
- For å bli med i en domenekontroller som kjører et nyere OS, må du heve funksjonsnivået for domene (skog). Dette er heller ikke tilfelle, men i motsetning til forrige tilfelle, vil denne operasjonen gjøre umulig å bruke domenekontrollere som kjører et OS lavere enn driftsmodusen. Derfor, i tilfelle en feil, må du gjenopprette AD-strukturen fra en sikkerhetskopi.
Vi vil også fokusere din oppmerksomhet på skog- og domenefunksjonsnivå. Domener som inngår i skogen kan ha forskjellige moduser arbeid, for eksempel kan ett av domenene fungere i Windows-modus 2008, og resten er i Windows 2003-modus. Skogfunksjonsdiagrammet kan ikke være høyere enn det eldste domenets funksjonsdiagram. I vårt eksempel kan ikke skogens funksjonsnivå være høyere enn Windows 2003.
Det lavere funksjonsnivået for skog forhindrer deg imidlertid ikke i å bruke det høyere funksjonsnivået for domene på noen måte; alt som kreves for dette er å oppdatere skjemaet.
Etter å ha gjort oss kjent med teorien, la oss gå videre til praktisk eksempel... La oss si at vi har et Windows 2000-nivådomene (blandet modus) - det meste lavt nivå AD - som det er en kontroller for Windows-kontroll 2003, og vårt mål er å skape ny kontroller i stedet for den mislykkede.
Den nye serveren kjører Windows 2008 R2. Merk at vi ikke hadde noen problemer med å aktivere denne serveren til et eksisterende domene.
I vårt tilfelle er alle roller på samme kontroller, så kopier mappen \ støtte \ adprep på HDD(i vårt tilfelle, til roten av C :)-stasjonen og fortsett for å oppdatere skogskjemaet. For å fullføre operasjonen må kontoen din være medlem av gruppene:
- Skjemaadministratorer
- Bedriftsadministratorer
- Administratorer for domenet der skjemamasteren ligger
For å oppdatere skogskjemaet, kjør kommandoen:
C: \ adprep \ adprep / forestprep
Les standardadvarselen og fortsett ved å klikke C, deretter Tast inn.
Oppdateringsprosessen for skjema begynner. Som du kan se, vil versjonen endres fra 30 (Windows 2003) til 47 (Windows 2008 R2).
Etter å ha oppgradert skogskjemaet, bør du oppgradere domeneskjemaet. Før du gjør dette, bør du sørge for at domenet kjører minst i Windows 2000-modus (native-modus). Som du husker, fungerer domenet vårt i blandet modus, så vi bør endre domenets funksjonsnivå til hovednivået eller heve det til Windows 2003. Siden vi ikke har kontrollere som kjører Windows 2000 i dette domenet, vil det være rimeligst å heve domenemodusen.
For å kunne oppdatere domeneskjemaet, bør denne operasjonen utføres på Infrastruktureier og har rettighetene Domeneadministrator... Vi utfører kommandoen:
C: \ adprep \ adprep / domainprep
Og vi leser nøye den viste informasjonen. Når du oppgraderer domeneskjemaet fra et Windows 2000- eller Windows 2003-nivå, må du utføre en tillatelsesendring filsystem til gruppepolicyer... Denne operasjonen utføres en gang og i fremtiden, for eksempel når du oppdaterer skjemaet fra 2008 til 2008 R2, må den utføres. For å oppdatere tillatelsene til GPOer, skriv inn kommandoen:
C: \ adprep \ adprep / domainprep / gpprep
I versjoner av AD, fra og med Windows 2008, er det en ny type domenekontroller: skrivebeskyttet domenekontroller (RODC), hvis du planlegger å distribuere en slik kontroller, må du forberede skjemaet. Generelt anbefaler vi å gjøre denne operasjonen uavhengig av om du skal installere en RODC i nær fremtid eller ikke.
Denne operasjonen kan utføres på hvilken som helst domenekontroller, men du må være medlem av gruppen Bedriftsadministratorer og Navngivning av mester og Infrastrukturmester bør være tilgjengelig.
C: \ adprep \ adprep / rodcprep
Som du kan se, forårsaker oppdatering av domeneskjemaet, hvis det planlegges riktig, ingen vanskeligheter, men i alle fall bør du huske at dette er en irreversibel operasjon og ha de nødvendige sikkerhetskopiene for hånden.
