Innledning

The Lightweight Directory Service er nyttig i situasjoner der programmer trenger tilgang til en katalogtjeneste, men du ønsker ikke å risikere at det går Active katalog database. I denne artikkelen, vil du bli introdusert til Lightweight Directory Services, dets bruk, og evner.

Når Microsoft lanserte Active Directory i Windows 2000, tok det ikke lang tid før folk begynte å innse at Active katalogen var egentlig litt mer enn en sentralisert database, og at Active Directory kunne brukes til formål som det ble aldri ment.

For en stund virket det som om nesten alle programvareleverandør var å designe sine varer til være Active Directory integrert. Mange slike programmer lagret deres konfigurasjonsopplysningene i Active Directory, og noen enda skjerpe så langt som å faktisk behandler Active Directory som et alternativ til en SQL-database og lagre selve programdata i Active Directory databasen.

I dag de fleste av tredjeparts programvare utgivere ser ut til å ta mindre invasiv tilnærming til måten de grensesnitt med Active Directory. Mange programmer lese Active Directory data, men ikke på langt nær så mange programmer ser ut til å lagre data innenfor Active Directory som gjorde for noen år tilbake. Selv om jeg kan bare spekulere på årsakene til dette, jeg mistenker at det har noe å gjøre med det faktum at Active Directory er blitt en viktig del av nettverksinfrastruktur, og mange administratorer er motvillige til å utføre unødvendige skjema utvidelser (som er nesten alltid nødvendig å støtte applikasjoner som lagrer data i Active Directory).

Selv om programvaren utgivere ikke kan bruke Active Directory til ganske den grad at de en gang gjorde, tror jeg at det er trygt å si at Active katalogen kan være svært nyttig for å støtte ulike bruksområder. For å vise deg hva jeg mener, kan du vurdere det faktum at Microsoft design fortsatt mange av deres server-applikasjoner med en høy grad av Active Directory integrering. Exchange Server 2007 og Exchange Server 2010 for eksempel, er utformet på en slik måte at all informasjon server konfigurasjonen er lagret i Active Directory, i stedet for å bli lagret lokalt på serveren. Fordelen ved å gjøre dette er at det gjør det mulig å regenerere en mislykket server på fly.

Anta for eksempel at du hadde en katastrofal feil på harddisken på en Exchange 2010-server som var vertskap for den Hub Transport Server Role . På grunn av måten at Exchange lagrer konfigurasjonsinformasjon i Active Directory, ville du ikke engang å gjenopprette en sikkerhetskopi for å løse problemet. I stedet må du starte med å tilbakestille datamaskinen konto for den mislykkede server i Active Directory. Du vil deretter installere Windows og eventuelle oppdateringspakker på en ny server. Deretter vil du tilordne den serveren samme datamaskin navnet ditt som sviktet server hadde brukt, og bli med i den nye serveren til Active Directory. Fordi du tilbakestiller Active Directory datamaskinen betraktning, er den nye serveren i stand til å bruke den.

Derfra fikse problemet er så enkelt som kjører Exchange Server Setup-programmet med en spesiell bryter. Oppsett installerer de nødvendige binærfiler, og deretter konfigurerer serveren i henhold til informasjonen konfigurasjon funnet i Active Directory. Den nye serveren kan være oppe og går i mindre enn en time, og uten noen gang å gjenopprette en sikkerhetskopi.

Mitt poeng er at Active Directory kan være svært nyttig for applikasjonsstøtte, men at mange programvare utgivere er motvillige til å bruke det i den grad at Microsoft gjør det, på grunn av stigma som er knyttet til å lage Active Directory-skjemaet extensions.

En annen grunn til at du ikke ser flere programvareleverandører å lagre mye data i Active Directory må gjøre med Active Directory-replikering. Generelt sett må alle data som er lagret i Active Directory bli replikert til alle domenekontrollere i domenet (muligens også alle domenekontrollere i skogen). Som sådan, hvis en søknad var til å lagre store mengder data i Active Directory, som kan data påvirke hastigheten på normal replikering prosessen -. Særlig hvis disse dataene endres ofte

På tross av disse utfordringene, det er en måte å høste fordelene av Active Directory integrering, uten at det påvirker din Active Directory databasen i prosessen. Windows Server 2008 og Windows Server 2008 R2 inkluderer en tjeneste kalt Active Directory Lightweight Directory Service, eller AD LDS. En lignende tjeneste finnes også i Windows Server 2003, men går under navnet Active Directory Application Mode (eller ADAM).

I tilfelle du ikke er kjent med AD LDS, det gir deg et miljø som er svært lik til, men helt atskilt fra, Active Directory. AD LDS er en frittstående tjeneste som har ingen avhengighet av katalogtjenesten Active Directory. Faktisk er det vanlig å distribuere AD LDS i miljøer der ingen Active Directory-domener finnes.

Et perfekt eksempel på en slik situasjon er Microsoft Exchange Server. Tidligere sa jeg at Exchange Server 2007 og 2010 er begge utviklet for å lagre alle sine konfigurasjonsopplysningene i Active Directory databasen. Det er ett stort unntak til dette imidlertid.

Exchange Server definerer en rekke roller som dikterer hvordan en Exchange Server er konfigurert, og hvilke oppgaver serveren utfører. Alle bortsett fra ett av de serverroller er laget for å lagre konfigurasjonen i Active Directory-tjeneren.

Serveren rolle som ikke bruker Active Directory er kjent som Edge Transport Server Role. Edge Transport Server er laget for å ligge på nettverket omkretsen og holde de andre Exchange-servere fra å bli direkte utsatt for Internett.

Fordi Edge Transport Server er utsatt for ulike Internett-baserte trusler, noe som gjør det til et medlem av et Active Directory-domene kan være en potensiell sikkerhetsrisiko. Hvis noen var i stand til å inngå kompromisser kanten transport server, kan de være i stand til å bruke den til å få informasjon om Active Directory.

For å holde dette skjer, kan Edge Transport Server ikke være medlem av et domene, og det kan ikke vert noen andre Exchange Server roller. Selv så gjør Edge Transport Server krever tilgang til en minimal mengde av Active Directory informasjon slik at den kan gjøre jobben sin. Snarere enn å gi serveren med direkte tilgang til Active Directory, Microsoft har utviklet Edge Transport Server rollen å bruke AD LDS.

En av de backend Exchange-servere leser nødvendig informasjon fra Active Directory, og sender informasjon til AD LDS partisjon på Edge Transport Server. På den måten har Edge Transport Server tilgang til den informasjonen som den trenger, uten å være i stand til å få tilgang til Active Directory. Forresten, lagrer Edge Transport Server også sin egen konfigurasjonsopplysningene i AD LDS partisjon, akkurat som andre Exchange Server roller informasjon butikk konfigurasjonen i Active Directory.

Konklusjon

Nå som jeg har snakket om hva AD LDS er, og hva det brukes til, jeg ønsker å slå min oppmerksomhet til å bruke denne tjenesten i egen organisasjon. I del 2, vil jeg begynne å diskutere maskinvare og programvarekravene for å bruke AD LDS.