Elementer er en del av Active Directory-tjenesten. Introduksjon. Fremme en server til en domenekontroller

I våre tidligere artikler har vi diskutert vanlige problemer knyttet til katalogtjenester og Active Directory. Nå er det på tide å gå videre til trening. Men ikke skynd deg å løpe til serveren, før du distribuerer en domenestruktur i nettverket ditt, må du planlegge den og ha en klar ide om formålet med individuelle servere og prosessene for interaksjon mellom dem.

Før du oppretter din første domenekontroller, må du bestemme modusen for driften. Driftsmodusen bestemmer de tilgjengelige alternativene og avhenger av versjonen av operativsystemet som brukes. Vi vil ikke vurdere alle mulige moduser, bortsett fra de som er aktuelle for øyeblikket. Det er tre slike moduser: Windows Server 2003, 2008 og 2008 R2.

Windows Server 2003-modus bør kun velges når servere på dette operativsystemet allerede er distribuert i infrastrukturen din og du planlegger å bruke en eller flere av disse serverne som domenekontrollere. I andre tilfeller må du velge Windows Server 2008- eller 2008 R2-modus, avhengig av de kjøpte lisensene. Det bør huskes at domenedriftsmodusen alltid kan økes, men det vil ikke være mulig å senke den (bortsett fra ved å gjenopprette fra en sikkerhetskopi), så ta dette problemet nøye, ta hensyn til mulige utvidelser, lisenser i filialer, etc. . etc.

Vi vil ikke nå vurdere i detalj prosessen med å lage en domenekontroller, vi kommer tilbake til dette problemet senere, men nå vil vi gjøre oppmerksom på at det i den fullstendige Active Directory-strukturen til domenekontrollere bør være minst to. Ellers utsetter du deg selv for unødvendig risiko, fordi i tilfelle feil på en enkelt domenekontroller vil AD-strukturen din fullstendig ødelagt. Det er bra hvis det er en oppdatert sikkerhetskopi, og du kan gjenopprette fra den, i alle fall hele denne tiden vil nettverket ditt være fullstendig lammet.

Derfor, umiddelbart etter å ha opprettet den første domenekontrolleren, må du distribuere en andre, uavhengig av nettverksstørrelse og budsjett. Den andre kontrolleren bør leveres på planleggingsstadiet, og uten den er utplasseringen av AD ikke engang verdt å gjennomføre. Ikke kombiner rollen som en domenekontroller med noen andre serverroller, for å sikre påliteligheten til operasjoner med AD-databasen, er skrivebufring deaktivert på disken, noe som fører til et kraftig fall i diskundersystemytelse (dette forklarer også den lange lastingen av domenekontrollere).

Som et resultat bør nettverket vårt ha følgende form:

I motsetning til hva mange tror, ​​er alle kontroller i et domene like; hver kontroller inneholder fullstendig informasjon om alle domeneobjekter og kan betjene en klientforespørsel. Men dette betyr ikke at kontrollerene er utskiftbare, misforståelse av dette punktet fører ofte til AD-feil og nedetid i bedriftsnettverket. Hvorfor skjer dette? Det er på tide å huske på rollen til FSMO.

Når vi oppretter den første kontrolleren, inneholder den alle tilgjengelige roller, og er også en global katalog, med bruk av den andre kontrolleren, blir rollene som infrastrukturmester, RID-master og PDC-emulator overført til den. Hva skjer hvis administratoren bestemmer seg for å midlertidig deaktivere DC1-serveren, for eksempel for å rense den for støv? Ved første øyekast er det greit, vel, domenet vil bytte til "skrivebeskyttet"-modus, men det vil fungere. Men vi glemte den globale katalogen, og hvis applikasjoner som krever det, for eksempel Exchange, er distribuert på nettverket ditt, vil du vite om det før du fjerner dekselet fra serveren. Man lærer av misfornøyde brukere, og ledelsen blir neppe fornøyd.

Av dette følger konklusjonen: det bør være minst to globale kataloger i skogen, og best av alt, en i hvert domene. Siden vi har ett domene i skogen, må begge serverne være globale kataloger, dette vil tillate deg å ta hvilken som helst av serverne for vedlikehold uten problemer, det midlertidige fraværet av noen FSMO-roller fører ikke til AD-feil, men gjør det bare umulig å lage nye objekter.

Som domeneadministrator må du tydelig forstå hvordan FSMO-rollene er fordelt mellom serverne dine, og når du tar ned en server i en lengre periode, overføre disse rollene til andre servere. Og hva vil skje hvis serveren som inneholder FSMO-rollene mislykkes irreversibelt? Det er greit, som vi allerede skrev, enhver domenekontroller inneholder all nødvendig informasjon, og hvis en slik plage oppstår, må du fange de nødvendige rollene av en av kontrollerene, dette vil gjenopprette full drift av katalogtjenesten .

Tiden går, organisasjonen din vokser og den har en filial på den andre siden av byen, og det blir nødvendig å inkludere nettverket deres i den overordnede infrastrukturen til bedriften. Ved første øyekast, ingenting komplisert, setter du opp en kommunikasjonskanal mellom kontorer og plasserer en ekstra kontroller i den. Alt ville vært bra, men det er én ting. Du kan ikke kontrollere denne serveren, og derfor er uautorisert tilgang til den mulig, og den lokale administratoren får deg til å tvile på hans kvalifikasjoner. Hvordan være i en slik situasjon? For disse formålene er det en spesiell type kontroller: skrivebeskyttet domenekontroller (RODC), er denne funksjonen tilgjengelig i domenefunksjonsmoduser fra Windows Server 2008 og nyere.

En skrivebeskyttet domenekontroller inneholder en fullstendig kopi av alle domeneobjekter og kan være en global katalog, men lar deg ikke gjøre noen endringer i AD-strukturen, den lar deg også tilordne en hvilken som helst bruker som lokal administrator, som vil la ham betjene denne serveren fullt ut, men igjen uten tilgang til AD-tjenester. I vårt tilfelle var det dette legen bestilte.

Vi setter opp i RODC-filialen, alt fungerer, du er rolig, men brukere begynner å klage på lang pålogging og trafikkregninger i slutten av måneden viser et overskudd. Hva skjer? Det er på tide å huske igjen om ekvivalensen til domenekontrollere, klienten kan sende forespørselen sin til hvilken som helst domenekontroller, til og med lokalisert i en annen gren. Ta hensyn til den langsomme og mest sannsynlige travle kommunikasjonskanalen - dette er årsaken til påloggingsforsinkelsene.

Den neste faktoren som forgifter livene våre i denne situasjonen er replikering. Som du vet, spres alle endringer som gjøres på en av domenekontrollerne automatisk til andre, og denne prosessen kalles replikering, den lar deg ha en oppdatert og konsistent kopi av dataene på hver kontroller. Replikeringstjenesten kjenner ikke til vår filial og en treg kommunikasjonskanal, og derfor vil alle endringer på kontoret umiddelbart replikeres til filialen, laste kanalen og øke trafikkforbruket.

Her kommer vi nær begrepet AD-sider, som ikke må forveksles med internettsider. Active Directory-nettsteder representerer en måte å fysisk dele strukturen til en katalogtjeneste inn i områder atskilt fra andre områder med langsomme og/eller ustabile koblinger. Nettsteder opprettes på grunnlag av undernett og alle klientforespørsler sendes først til kontrollerene på nettstedet deres, det er også svært ønskelig å ha en global katalog på hvert nettsted. I vårt tilfelle må vi opprette to nettsteder: AD-side 1 for sentralkontoret og AD-side 2 for en gren, mer presist en, siden AD-strukturen som standard allerede inneholder et nettsted, som inkluderer alle tidligere opprettede objekter. La oss nå se på hvordan replikering skjer i et nettverk med flere nettsteder.

Vi vil anta at organisasjonen vår har vokst litt og hovedkontoret inneholder så mange som fire domenekontrollere, replikering mellom kontrollere på ett nettsted kalles intrasite og skjer umiddelbart. Replikeringstopologien bygges i henhold til ringskjemaet med betingelsen om at det ikke er mer enn tre replikeringstrinn mellom noen domenekontrollere. Ringskjemaet er lagret for opptil 7 kontroller inkludert, hver kontroller etablerer en forbindelse med to nærmeste naboer, med et større antall kontroller vises ytterligere forbindelser og den felles ringen blir så å si til en gruppe ringer lagt over hverandre.

Intersite replikering skjer forskjellig, i hvert domene velges en av serverne (brohodeserver) automatisk, noe som etablerer en forbindelse med en lignende server på et annet nettsted. Som standard skjer replikering en gang hver 3. time (180 minutter), men vi kan sette vår egen replikeringsplan og for å spare trafikk overføres alle data i komprimert form. Hvis det bare er en RODC på et sted, skjer replikering enveis.

Selvfølgelig er temaene vi berørte veldig dype, og i dette materialet har vi bare berørt dem litt, men dette er den nødvendige minimumskunnskapen du trenger å ha før den praktiske implementeringen av Active Directory i bedriftsinfrastrukturen. Dette vil unngå dumme feil under utplassering og nødsituasjoner under vedlikehold og utvidelse av strukturen, og hvert av temaene som tas opp vil bli diskutert mer detaljert.

I 2002, mens jeg gikk langs korridoren til informatikkavdelingen på mitt favorittuniversitet, så jeg en fersk plakat på døren til NT Systems-kontoret. Plakaten viste ikoner for brukerkontoer gruppert i grupper, hvorfra pilene igjen gikk til andre ikoner. Alt dette ble skjematisk kombinert til en bestemt struktur, noe ble skrevet om et enkelt inngangssystem, autorisasjon og lignende. Så vidt jeg forstår nå, viste plakaten arkitekturen til Windows NT 4.0-domener og Windows 2000 Active Directory-systemer. Fra det øyeblikket begynte mitt første bekjentskap med Active Directory og sluttet umiddelbart, for da var det en hard økt, en morsom ferie, hvorpå en venn delte FreeBSD 4 og Red Hat Linux-disker, og de neste årene kastet jeg meg ut i verden av Unix-lignende systemer , men jeg glemte aldri innholdet på plakaten.
Jeg måtte tilbake og bli mer kjent med Windows Server-systemer da jeg flyttet for å jobbe i et selskap der styringen av hele IT-infrastrukturen var basert på Active Directory. Jeg husker at sjefsadministratoren for det selskapet på hvert møte fortsatte å si noe om en slags Active Directory Best Practices. Nå, etter 8 år med periodisk kommunikasjon med Active Directory, forstår jeg ganske godt hvordan dette systemet fungerer og hva Active Directory Best Practices er.
Som du sikkert allerede har gjettet, vil vi snakke om Active Directory.
Alle som er interessert i dette emnet, velkommen til katt.

Disse anbefalingene er gyldige for klientsystemer som starter med Windows 7 og høyere, for domener og skoger på Windows Server 2008/R2-nivå og høyere.

Standardisering
Planlegging for Active Directory bør begynne med å utvikle dine egne standarder for navngivning av objekter og deres plassering i katalogen. Det er nødvendig å lage et dokument der alle nødvendige standarder skal defineres. Selvfølgelig er dette en ganske vanlig anbefaling for IT-fagfolk. Prinsippet «først skriver vi dokumentasjon, og så bygger vi et system basert på denne dokumentasjonen» er veldig bra, men det blir sjelden implementert i praksis av mange årsaker. Blant disse årsakene - enkel menneskelig latskap eller mangel på passende kompetanse, er resten av årsakene avledet fra de to første.
Jeg anbefaler - skriv først dokumentasjonen, tenk over det, og fortsett deretter med installasjonen av den første domenekontrolleren.
For eksempel vil jeg gi en del av dokumentet om standarder for navngivning av Active Directory-objekter.
Navngivning av objekter.

  • Navnet på brukergruppene må begynne med prefikset GRUS_ (GR - Group, US - Users)
  • Navnet på datamaskingrupper må ikke begynne med prefikset GRCP_ (GR - Gruppe, CP - Datamaskiner)
  • Navnet på delegasjonsgruppene må begynne med prefikset GRDL_ (GR - Group, DL - Delegation)
  • Navnet på ressurstilgangsgrupper må begynne med prefikset GRRS_ (GR - Gruppe, RS - ressurser)
  • Navnet på grupper for retningslinjer må begynne med prefiksene GPUS_, GPCP_ (GP - Gruppepolicy, USA - Brukere, CP - Datamaskiner)
  • Navnet på klientdatamaskiner bør bestå av to eller tre bokstaver fra navnet på organisasjonen, etterfulgt av et tall gjennom en bindestrek, for eksempel nnt-01.
  • Servernavn må begynne med bare to bokstaver, etterfulgt av en bindestrek etterfulgt av serverrollen og servernummeret, for eksempel nn-dc01.
Jeg anbefaler å navngi Active Directory-objektene på en slik måte at du ikke trenger å fylle ut "Beskrivelse"-feltet. For eksempel, fra navnet på gruppen GPCP_Restricted_Groups, er det klart at dette er en gruppe for en policy som brukes på datamaskiner og utfører arbeidet med mekanismen for begrensede grupper.
Din tilnærming til å skrive dokumentasjon bør være veldig grundig, dette vil spare mye tid senere.

Forenkle alt mulig, prøv å oppnå balanse
Når du bygger en Active Directory, må du følge prinsippet om å oppnå en balanse, velge enkle og forståelige mekanismer.
Balanseprinsippet er å oppnå nødvendig funksjonalitet og sikkerhet med maksimal enkelhet i løsningen.
Det er nødvendig å prøve å bygge systemet slik at strukturen er tydelig for den mest uerfarne administratoren eller til og med brukeren. For eksempel var det en gang en anbefaling om å lage en skogstruktur fra flere domener. Dessuten ble det anbefalt å distribuere ikke bare flerdomenestrukturer, men også strukturer fra flere skoger. Kanskje eksisterte en slik anbefaling på grunn av prinsippet om «del og hersk», eller fordi Microsoft fortalte alle at domenet er en sikkerhetsgrense og ved å dele organisasjonen inn i domener vil vi få separate strukturer som er lettere å kontrollere individuelt. Men som praksis har vist, er det lettere å vedlikeholde og kontrollere enkeltdomenesystemer, der sikkerhetsgrensene er organisatoriske enheter (OU), ikke domener. Unngå derfor å lage komplekse flerdomenestrukturer, det er bedre å gruppere objekter etter OU.
Selvfølgelig bør du handle uten fanatisme - hvis du ikke kan klare deg uten flere domener, må du opprette flere domener, også med skoger. Hovedsaken er at du forstår hva du gjør og hva det kan føre til.
Det er viktig å forstå at en enkel Active Directory-infrastruktur er enklere å administrere og kontrollere. Jeg vil til og med si at jo enklere, jo tryggere.
Bruk prinsippet om forenkling. Prøv å oppnå balanse.

Følg prinsippet - "objekt - gruppe"
Begynn å lage Active Directory-objekter ved å opprette en gruppe for dette objektet, og tilordne allerede nødvendige rettigheter til gruppen. La oss se på et eksempel. Du må opprette en hovedadministratorkonto. Opprett først Head Admins-gruppen og først deretter oppretter du selve kontoen og legger den til i denne gruppen. Tildel Head Admins-gruppen rettighetene til hovedadministratoren, for eksempel ved å legge den til Domain Admins-gruppen. Nesten alltid viser det seg at etter en stund kommer en annen ansatt på jobb som trenger lignende rettigheter, og i stedet for å delegere rettigheter til forskjellige deler av Active Directory, vil det være mulig å ganske enkelt legge ham til den nødvendige gruppen, som systemet allerede har definerte rollen og delegerte nødvendig myndighet.
Et eksempel til. Du må delegere rettigheter til OU med brukere til systemadministratorgruppen. Ikke deleger rettigheter direkte til administratorgruppen, men opprett en spesiell gruppe som GRDL_OUName_Operator_Accounts som du tildeler rettigheter til. Så er det bare å legge til den ansvarlige administratorgruppen i GRDL_OUName_Operator_Accounts-gruppen. Det vil definitivt vise seg at du i nær fremtid må delegere rettigheter til denne OU til en annen gruppe administratorer. Og i dette tilfellet vil du ganske enkelt legge til administratordatagruppen til delegeringsgruppen GRDL_OUName_Operator_Accounts.
Jeg foreslår følgende gruppestruktur.

  • Brukergrupper (GRUS_)
  • Administratorgrupper (GRAD_)
  • Delegasjonsgrupper (GRDL_)
  • Policygrupper (GRGP_)
Datagrupper
  • Servergrupper (GRSR_)
  • Klientdatamaskingrupper (GRCP_)
Ressurstilgangsgrupper
  • Delte ressurstilgangsgrupper (GRRS_)
  • Skrivertilgangsgrupper (GRPR_)
I et system bygget rundt disse retningslinjene vil nesten all administrasjon legge til grupper i grupper.
Hold balansen, begrens antall roller for grupper, og husk at navnet på gruppen ideelt sett fullt ut skal beskrive dens rolle.

OU arkitektur.
Arkitekturen til en OU bør først og fremst tenkes gjennom fra et sikkerhetssynspunkt og delegering av rettigheter til denne OU til systemadministratorer. Jeg anbefaler ikke å planlegge OU-arkitekturen når det gjelder å knytte gruppepolicyer til dem (selv om dette oftest gjøres). For noen vil anbefalingen min virke litt merkelig, men jeg anbefaler ikke å koble gruppepolicyer til en OU i det hele tatt. Les mer i avsnittet Gruppepolicyer.
OU-administratorer
Jeg anbefaler å tildele en egen OU for administrative kontoer og grupper, hvor du skal plassere kontoene og gruppene til alle administratorer og teknisk støtteingeniører. Tilgang til denne OU bør begrenses til vanlige brukere, og administrasjon av objekter fra denne OU bør kun delegeres til hovedadministratorene.
OU datamaskiner
Data-OU-er er best planlagt når det gjelder datageografi og datatyper. Distribuer datamaskiner fra forskjellige geografiske steder i forskjellige OU-er, og del dem i sin tur inn i klientdatamaskiner og servere. Servere kan videre deles inn i Exchange, SQL og andre.

Brukere, rettigheter i Active Directory
Active Directory-brukerkontoer bør vies spesiell oppmerksomhet. Som nevnt i avsnittet om OUer bør brukerkontoer grupperes ut fra prinsippet om delegering av myndighet til disse kontoene. Det er også viktig å følge prinsippet om minste privilegium – jo mindre rettigheter en bruker har i systemet, jo bedre. Jeg anbefaler at du umiddelbart legger brukerens rettighetsnivå i navnet på kontoen hans. En konto for daglig arbeid bør bestå av brukerens etternavn og initialer på latin (for eksempel IvanovIV eller IVIvanov). De obligatoriske feltene er: Fornavn, Initialer, Etternavn, Visningsnavn (på russisk), e-post, mobil, stillingstittel, leder.
Administratorkontoer må være av følgende typer:

  • Med administratorrettigheter til brukerdatamaskiner, men ikke servere. Må bestå av eierens initialer etterfulgt av prefikset lokal (f.eks. iivlocal)
  • Med rettigheter til å administrere servere og Active Directory. Må kun bestå av initialer (for eksempel iiv).
Etternavnsfeltet for begge typer administrative kontoer skal begynne med bokstaven I (for eksempel iPetrov P Vasily)
La meg forklare hvorfor du bør skille administrative kontoer inn i serveradministratorer og klientdatamaskinadministratorer. Dette er nødvendig av sikkerhetsmessige årsaker. Administratorer av klientdatamaskiner vil ha rett til å installere programvare på klientdatamaskiner. Hva og hvorfor programvaren skal installeres, kan du aldri si sikkert. Derfor er det ikke trygt å kjøre installasjonen av programmet med domeneadministratorrettigheter; du kan kompromittere hele domenet. Du må bare administrere klientdatamaskiner med lokale administratorrettigheter for den datamaskinen. Dette vil gjøre det umulig for en rekke angrep på kontoer til domeneadministratorer, for eksempel "Pass The Hash". I tillegg må administratorer av klientdatamaskiner lukke Terminal Services-tilkoblingen og nettverkstilkoblingen til datamaskinen. Datamaskiner for teknisk støtte og administratorer bør plasseres i et eget VLAN for å begrense tilgangen til dem fra nettverket av klientdatamaskiner.
Tildeling av administratorrettigheter til brukere
Hvis du trenger å gi administratorrettigheter til en bruker, må du ikke legge den daglige kontoen i datamaskinens lokale administratorgruppe under noen omstendigheter. En konto for daglig arbeid bør alltid være begrenset i rettigheter. Opprett en separat administrativ konto av typen namelocal for den og legg til denne kontoen til den lokale administratorgruppen ved å bruke policyen, og begrense bruken kun på brukerens datamaskin ved å bruke målretting på elementnivå. Brukeren vil kunne bruke denne kontoen ved å bruke Kjør AS-mekanismen.
Passordpolicyer
Lag separate passordpolicyer for brukere og administratorer ved å bruke finmasket passordpolicy. Det er ønskelig at brukerpassordet er minst 8 tegn langt og endres minst kvartalsvis. Det er ønskelig for administratorer å endre passordet annenhver måned, og det bør være minst 10-15 tegn langt og oppfylle kravene til kompleksitet.

Sammensetning av domene og lokale grupper. Mekanisme for begrensede grupper
Sammensetningen av domene og lokale grupper på domenedatamaskiner bør kun kontrolleres i automatisk modus, ved å bruke mekanismen for begrensede grupper. Hvorfor det er nødvendig å gjøre dette bare på denne måten, vil jeg forklare med følgende eksempel. Vanligvis, etter at Active Directory-domenet er ødelagt, legger administratorer seg selv til domenegrupper som domeneadministratorer, bedriftsadministratorer, legger til tekniske støtteingeniører til de nødvendige gruppene, og distribuerer også andre brukere i grupper. I prosessen med å administrere dette domenet, gjentas prosessen med å utstede rettigheter mange ganger, og det vil være ekstremt vanskelig å huske at du i går midlertidig la til regnskapsfører Nina Petrovna til 1C-administratorgruppen og at du i dag må fjerne henne fra denne gruppen. Situasjonen vil forverres dersom selskapet har flere administratorer og hver fra tid til annen gir rettigheter til brukere i lignende stil. Om et år vil det være nesten umulig å finne ut hvilke rettigheter som tildeles hvem. Derfor bør sammensetningen av grupper kun kontrolleres av gruppepolicyer, som vil sette alt i orden med hver applikasjon.
Sammensetning av innebygde grupper
Det er verdt å si at de innebygde gruppene som kontooperatører, sikkerhetskopieringsoperatører, krypteringsoperatører, gjester, utskriftsoperatører, serveroperatører må være tomme, både i domenet og på klientdatamaskiner. Disse gruppene er først og fremst nødvendige for bakoverkompatibilitet med eldre systemer, og brukere av disse gruppene gis for mange rettigheter i systemet, og privilegieeskaleringsangrep blir mulig.

Lokale administratorkontoer
Ved å bruke mekanismen for begrensede grupper, må du låse ute lokale administratorkontoer på lokale datamaskiner, låse ute gjestekontoer og tømme den lokale administratorgruppen på lokale datamaskiner. Bruk aldri gruppepolicyer til å angi passord for lokale administratorkontoer. Denne mekanismen er ikke sikker, passordet kan hentes direkte fra policyen. Men hvis du bestemmer deg for ikke å blokkere lokale administratorkontoer, bruk LAPS-mekanismen til å angi passord og rotere dem riktig. Dessverre er ikke LAPS-konfigurasjonen fullstendig automatisert, og derfor vil det være nødvendig å manuelt legge til attributter til Active Directory-skjemaet, gi rettigheter til dem, tilordne grupper og så videre. Derfor er det lettere å blokkere lokale administratorkontoer.
Tjenestekontoer.
For å starte tjenester, bruk tjenestekontoer og gMSA-mekanismen (tilgjengelig på Windows 2012 og høyere systemer)

Gruppepolicyer
Dokumenter retningslinjer før du oppretter/endrer.
Når du oppretter en policy, bruk "Policy - group"-prinsippet. Det vil si at før du oppretter en policy, må du først opprette en gruppe for denne policyen, fjerne gruppen Autentiserte brukere fra policyomfanget og legge til den opprettede gruppen. Bind policyen ikke til en OU, men til roten av domenet og reguler omfanget av dens anvendelse ved å legge til objekter i policygruppen. Jeg anser en slik mekanisme for å være mer fleksibel og forståelig enn å knytte en policy til en OU. (Det er det jeg skrev om i OU Architecture-delen).
Juster alltid omfanget av politikken. Hvis du har opprettet en policy kun for brukere, deaktiver datamaskinstrukturen og omvendt, deaktiver brukerstrukturen hvis du har opprettet en policy for bare datamaskiner. Takket være disse innstillingene vil retningslinjer bli brukt raskere.
Sett opp daglige sikkerhetskopier av policyer ved hjelp av Power Shell slik at du i tilfelle konfigurasjonsfeil alltid kan tilbakestille innstillingene til de opprinnelige.
Central Store-maler (Central Store)
Fra og med Windows 2008 ble det mulig å lagre Group Policy ADMX-maler i en sentral butikk, i SYSVOL. Før dette ble alle policymaler som standard lagret lokalt på klienter. For å plassere ADMX-malene i sentrallageret, kopier innholdet i mappen %SystemDrive%\Windows\PolicyDefinitions sammen med undermapper fra klientsystemer (Windows 7/8/8.1) til domenekontrollerens %SystemDrive%\Windows\SYSVOL\domene \Policies\PolicyDefinitions-katalogen med innholdssammenslåing, men ingen erstatning. Deretter bør du lage den samme kopien fra serversystemene, og starter med den eldste. Til slutt, når du kopierer mapper og filer fra den nyeste versjonen av serveren, gjør du en Merge and REPLACE-kopi.

Kopiere ADMX-maler

I tillegg kan ADMX-maler for alle programvareprodukter, for eksempel Microsoft Office, Adobe-produkter, Google-produkter og andre, plasseres i sentrallageret. Gå til programvareleverandørens nettsted, last ned ADMX-malen for gruppepolicy, og pakk den ut til mappen %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions på en av domenekontrollerne. Nå kan du administrere programvareproduktet du trenger gjennom gruppepolicyer.
WMI-filtre
WMI-filtre er ikke veldig raske, så målretting på varenivå er å foretrekke. Men hvis målretting på varenivå ikke kan brukes, og du bestemmer deg for å bruke WMI, anbefaler jeg at du umiddelbart oppretter flere av de vanligste filtrene for deg selv: filteret "Bare klientoperativsystemer", "Bare serveroperativsystemer", filtre "Windows 7", filtrerer "Windows 8", "Windows 8.1", "Windows 10". Hvis du har ferdige sett med WMI-filtre, vil det være lettere å bruke ønsket filter på ønsket policy senere.

Revisjon av Active Directory-hendelser
Sørg for å aktivere hendelsesrevisjon på domenekontrollere og andre servere. Jeg anbefaler at du aktiverer revisjon av følgende objekter:

  • Revisjon av datamaskinkontoadministrasjon – suksess, fiasko
  • Revidere andre kontoadministrasjonshendelser – suksess, fiasko
  • Revisjonssikkerhetsgruppeledelse - suksess, fiasko
  • Revisjon av brukerkontoadministrasjon – suksess, fiasko
  • Revisjon av Kerberos-autentiseringstjeneste – feil
  • Revidere andre kontopåloggingshendelser - feil
  • Endring av revisjonsrevisjonspolicy – ​​suksess, fiasko
Revisjon må konfigureres i seksjon Avansert revisjonspolicykonfigurasjon og husk å inkludere innstillingen i delen Lokale retningslinjer/sikkerhetsalternativer - Tving innstillinger for underkategori for revisjonspolicy (Windows Vista eller nyere) for å overstyre kategoriinnstillinger for revisjonspolicyer, som vil overstyre innstillingene på øverste nivå og bruke de avanserte.

Avanserte revisjonsinnstillinger

Jeg vil ikke dvele på revisjonsinnstillingene i detalj, siden det er et tilstrekkelig antall artikler på nettet viet til dette emnet. Jeg vil bare legge til at i tillegg til å aktivere revisjon, bør du konfigurere e-postvarsler om kritiske sikkerhetshendelser. Det er også verdt å vurdere at i systemer med et rikelig antall hendelser, er det verdt å dedikere separate servere for å samle og analysere loggfiler.

Administrasjons- og renseskript
Alle handlinger av samme type og ofte gjentatte må utføres ved hjelp av administrasjonsskript. Blant disse handlingene: opprette brukerkontoer, opprette administratorkontoer, opprette grupper, opprette OUer, og så videre. Skriptobjekter lar deg respektere Active Directory-objektets navnelogikk ved å bygge syntakssjekker rett inn i skriptene dine.
Det er også verdt å skrive renseskript som automatisk kontrollerer sammensetningen av grupper, identifiserer brukere og datamaskiner som ikke har koblet til domenet på lenge, oppdager brudd på de andre standardene dine, og så videre.
Jeg har ikke sett på som en eksplisitt offisiell anbefaling bruk av administrasjonsskript for å overvåke samsvar med standarder og utføre bakgrunnsoperasjoner. Men selv foretrekker jeg kontroller og prosedyrer i automatisk modus ved bruk av skript, da dette sparer mye tid og eliminerer mange feil, og selvfølgelig påvirker min litt Unix-tilnærming til administrasjon her, når det er lettere å skrive et par kommandoer enn å klikke på windows.

Manuell administrasjon
En del av administrasjonen må du og dine kolleger gjøre manuelt. For disse formålene anbefaler jeg å bruke mmc-konsollen med snap-ins lagt til.
Som det vil bli diskutert senere, må domenekontrollerne fungere i Server Core-modus, det vil si at administrasjon av hele AD-miljøet kun skal utføres fra datamaskinen ved hjelp av konsoller. For å administrere Active Directory, må du installere Remote Server Administration Tools på datamaskinen. Konsoller bør kjøres på datamaskinen din som en bruker med Active Directory-administratorrettigheter som kontroll er delegert til.
Kunsten å administrere Active Directory ved hjelp av konsoller krever en egen artikkel, og kanskje til og med en egen treningsvideo, så her snakker jeg bare om selve prinsippet.

Domenekontrollere
I ethvert domene må det være minst to kontrollere. Domenekontrollere bør ha så få tjenester som mulig. Du bør ikke lage en filserver av en domenekontroller eller, gud forby, heve rollen til en terminalserver på den. Kjør Server Core-operativsystemer på domenekontrollere ved å fjerne WoW64-støtten fullstendig, dette vil redusere antallet oppdateringer som kreves betydelig og øke sikkerheten deres.
Microsoft frarådet tidligere virtualisering av domenekontrollere på grunn av det faktum at replikeringskonflikter var vanskelige å løse ved gjenoppretting fra øyeblikksbilder. Det kan ha vært andre årsaker, jeg kan ikke si noe sikkert. Nå har hypervisorer lært å fortelle kontrollerne om å gjenopprette dem fra øyeblikksbilder, og dette problemet har forsvunnet. Jeg virtualiserte kontrollere hele tiden, uten å ta noen øyeblikksbilder, fordi jeg ikke forstår hvorfor det kan være nødvendig å gjøre det på domenekontrollere i det hele tatt. Etter min mening er det lettere å sikkerhetskopiere en domenekontroller ved å bruke standardverktøy. Derfor anbefaler jeg å virtualisere alle domenekontrollere som er mulig. Denne konfigurasjonen vil være mer fleksibel. Når du virtualiserer domenekontrollere, plasser dem på forskjellige fysiske verter.
Hvis du trenger å plassere en domenekontroller i et usikret fysisk miljø eller i en gren av organisasjonen din, bruk en RODC til dette formålet.

FSMO-roller, primære og sekundære kontrollere
Domenekontroller FSMO-roller fortsetter å skape frykt i hodet til nybegynnere administratorer. Nybegynnere studerer ofte Active Directory ved å bruke utdatert dokumentasjon eller lytter til historier fra andre administratorer som har lest noe et sted.
For alle fem + 1 roller skal følgende kort sies. Fra og med Windows Server 2008 er det ikke lenger primære og sekundære domenekontrollere. Alle fem domenekontrollerrollene er bærbare, men kan ikke hostes på mer enn én domenekontroller samtidig. Hvis vi tar en av kontrollerene, som for eksempel var eier av 4 roller, og sletter den, så kan vi enkelt overføre alle disse rollene til andre kontrollere, og ingenting forferdelig vil skje i domenet, ingenting vil gå i stykker. Dette er mulig fordi all informasjon om arbeidet knyttet til en bestemt rolle lagres av eieren direkte i Active Directory. Og hvis vi overfører rollen til en annen kontroller, ber den først og fremst om den lagrede informasjonen i Active Directory og begynner å tjene. Et domene kan eksistere ganske lenge uten rolleeiere. Den eneste "rollen" som alltid bør være i Active Directory, og uten hvilken alt vil være veldig dårlig, er rollen til den globale katalogen (GC), den kan bæres av alle kontrollere i domenet. Jeg anbefaler å tildele GC-rollen til hver kontroller i domenet, jo flere, jo bedre. Selvfølgelig kan du finne tilfeller der du ikke bør installere GC-rollen på en domenekontroller. Vel, hvis du ikke må, så trenger du ikke. Følg anbefalingene uten fanatisme.

DNS-tjeneste
DNS-tjenesten er avgjørende for driften av Active Directory og bør kjøre problemfritt. DNS-tjenesten plasseres best på hver domenekontroller og lagrer DNS-soner i selve Active Directory. Hvis du skal bruke Active Directory til å lagre DNS-soner, bør du konfigurere egenskapene til TCP/IP-tilkoblingen på domenekontrollerne slik at hver kontroller har en hvilken som helst annen DNS-server som primær DNS-server, og du kan angi den sekundære DNS-serveren adresse 127.0.0.1. Denne konfigurasjonen er nødvendig fordi for normal start av Active Directory-tjenesten kreves en fungerende DNS, og for at DNS skal starte, må Active Directory-tjenesten kjøres, siden den inneholder selve DNS-sonen.
Sørg for å sette opp omvendt oppslagssoner for alle nettverkene dine og aktiver automatisk sikker oppdatering av PTR-poster.
Jeg anbefaler at du i tillegg aktiverer automatisk rengjøring av sonen fra foreldede DNS-poster (dns-oppfanging).
Jeg anbefaler å spesifisere sikre Yandex-servere som DNS-videresendinger hvis det ikke finnes andre raskere i din geografiske plassering.

Nettsteder og replikering
Mange administratorer har en tendens til å tenke på nettsteder som en geografisk gruppering av datamaskiner. For eksempel Moskva-området, St. Petersburg-området. Dette synet dukket opp på grunn av det faktum at den opprinnelige inndelingen av Active Directory i nettsteder ble gjort for å balansere og skille replikeringsnettverkstrafikken. Domenekontrollere i Moskva trenger ikke vite at det nå er opprettet ti datakontoer i St. Petersburg. Og derfor kan slik informasjon om endringer overføres en gang i timen i henhold til en tidsplan. Eller repliker endringer én gang om dagen og bare om natten, for å spare båndbredde.
Om nettsteder vil jeg si dette: nettsteder er logiske grupper av datamaskiner. Datamaskiner som er sammenkoblet med en god nettverkstilkobling. Og selve nettstedene er forbundet med en forbindelse med lav båndbredde, noe som er en sjeldenhet i vår tid. Derfor deler jeg Active Directory inn i nettsteder, ikke for å balansere replikeringstrafikk, men for å balansere nettverksbelastning generelt og for raskere behandling av klientforespørsler fra nettstedsdatamaskiner. La meg forklare med et eksempel. Det er et 100-megabit lokalt nettverk av organisasjonen, som betjenes av to domenekontrollere, og det er en sky hvor applikasjonsserverne til denne organisasjonen er plassert med to andre skykontrollere. Jeg vil dele et slikt nettverk i to steder slik at kontrollerene i det lokale nettverket behandler klientforespørsler fra det lokale nettverket, og kontrollerene i skyen behandler forespørsler fra applikasjonsservere. I tillegg vil dette skille forespørsler til DFS- og Exchange-tjenester. Og siden jeg nå sjelden ser en Internett-kanal på mindre enn 10 megabit per sekund, vil jeg aktivere Notify Based Replication, dette er når data replikeres så snart det er noen endringer i Active Directory.

Konklusjon
I morges tenkte jeg på hvorfor menneskelig egoisme ikke er velkommen i samfunnet og et sted på et dypt nivå av oppfatning forårsaker ekstremt negative følelser. Og det eneste svaret som kom til meg er at menneskeslekten ikke ville ha overlevd på denne planeten hvis den ikke hadde lært å dele fysiske og intellektuelle ressurser. Det er derfor jeg deler denne artikkelen med deg, og jeg håper at anbefalingene mine vil hjelpe deg med å forbedre systemene dine og at du vil bruke mye mindre tid på feilsøking. Alt dette vil føre til frigjøring av mer tid og energi til kreativitet. Det er mye mer behagelig å leve i en verden av kreative og frie mennesker.
Det er bra hvis du deler din kunnskap og praksis for å bygge en Active Directory i kommentarfeltet hvis det er mulig.
Fred og godhet til alle!

Du kan hjelpe og overføre noen midler til utviklingen av nettstedet

Merknad: Denne forelesningen beskriver de grunnleggende konseptene for Active Directory-katalogtjenester. Praktiske eksempler på styring av nettverkssikkerhet er gitt. Mekanismen for gruppepolicyer er beskrevet. Gir innsikt i oppgavene til en nettverksadministrator ved administrasjon av en katalogtjenesteinfrastruktur

Moderne nettverk består ofte av mange forskjellige programvareplattformer, et bredt utvalg av maskinvare og programvare. Brukere blir ofte tvunget til å huske et stort antall passord for å få tilgang til ulike nettverksressurser. Tilgangsrettigheter kan være forskjellig for samme ansatt avhengig av ressursene han jobber med. Alt dette settet med sammenhenger krever mye tid fra administratoren og brukeren for analyse, memorering og læring.

Løsningen på problemet med å administrere et slikt heterogent nettverk ble funnet med utviklingen av katalogtjenesten. Directory Services gir muligheten til å administrere enhver ressurs eller tjeneste fra hvor som helst, uavhengig av nettverksstørrelse, operativsystemer eller maskinvarekompleksitet. Informasjon om brukeren legges inn én gang i katalogtjenesten, og etter det blir den tilgjengelig i hele nettverket. E-postadresser, gruppemedlemskap, nødvendige tilgangsrettigheter og kontoer for å jobbe med ulike operativsystemer – alt dette opprettes og holdes oppdatert automatisk. Eventuelle endringer i katalogtjenesten av en administrator oppdateres umiddelbart i hele nettverket. Administratorer trenger ikke lenger å bekymre seg for oppsagte ansatte - ved ganske enkelt å slette en brukerkonto fra katalogtjenesten, kan de sikre at alle tilgangsrettigheter til nettverksressurser som tidligere er gitt til den ansatte, blir automatisk fjernet.

For tiden er de fleste katalogtjenestene til forskjellige selskaper basert på standarden X.500. For å få tilgang til informasjon som er lagret i katalogtjenester, brukes vanligvis en protokoll. (LDAP). Med den raske utviklingen av TCP/IP-nettverk er LDAP i ferd med å bli standarden for katalogtjenester og katalogorienterte applikasjoner.

Katalogtjeneste Active Directory er grunnlaget for den logiske strukturen til bedriftsnettverk basert på Windows-systemet. Begrepet " Katalog"i vid forstand betyr" Katalog", a katalogtjeneste bedriftsnettverk er en sentralisert bedriftskatalog. Bedriftskatalogen kan inneholde informasjon om objekter av ulike typer. Katalogtjeneste Active Directory inneholder først og fremst objektene som Windows-nettverkssikkerhetssystemet er basert på - bruker-, gruppe- og datamaskinkontoer. Kontoer er organisert i logiske strukturer: domene, tre, skog, organisasjonsenheter.

Fra synspunktet om å studere materialet til kurset "Nettverk administrasjon"Det er fullt mulig å gå gjennom opplæringen som følger: studer først den første delen av denne delen (fra grunnleggende konsepter til installasjon av domenekontrollere), gå deretter til "Fil- og utskriftstjeneste", og etter å ha studert "Fil- og utskriftstjeneste" gå tilbake til "Active Directory Service Directory" for å lære mer avanserte konsepter for katalogtjenester.

6.1 Grunnleggende termer og begreper (skog, tre, domene, organisasjonsenhet). Planlegger et AD-navneområde. Installere domenekontrollere

Sikkerhetsstyringsmodeller: Arbeidsgruppemodell og sentralisert domenemodell

Som nevnt ovenfor er hovedformålet med katalogtjenester å administrere nettverkssikkerhet. Grunnlaget for nettverkssikkerhet er en database med kontoer (kontoer) til brukere, brukergrupper og datamaskiner, ved hjelp av hvilke tilgang til nettverksressurser kontrolleres. Før vi snakker om Active Directory-katalogtjenesten, la oss sammenligne de to modellene for å bygge en katalogtjenestedatabase og administrere tilgang til ressurser.

Modell "Arbeidsgruppe"

Denne styringsmodellen for bedriftsnettverkssikkerhet er den mest primitive. Den er designet for bruk i små peer-to-peer-nettverk(3–10 datamaskiner) og er basert på det faktum at hver datamaskin på nettverket med Windows NT/2000/XP/2003 operativsystemer har sin egen lokale database med kontoer, og denne lokale databasen kontrollerer tilgangen til ressursene til denne datamaskinen. Den lokale databasen med kontoer kalles databasen SAM (Sikkerhetskontoadministrator) og er lagret i registret til operativsystemet. Databasene til individuelle datamaskiner er fullstendig isolert fra hverandre og er ikke koblet sammen på noen måte.

Et eksempel på tilgangskontroll ved bruk av en slik modell er vist i fig. 6.1.


Ris. 6.1.

Dette eksemplet viser to servere (SRV-1 og SRV-2) og to arbeidsstasjoner (WS-1 og WS-2). SAM-databasene deres er merket henholdsvis SAM-1, SAM-2, SAM-3 og SAM-4 (SAM-databasene er vist som en oval i figuren). Hver database har brukerkontoer Bruker1 og Bruker2. Det fulle brukernavnet til User1 på SRV-1-serveren vil se ut som "SRV-1\User1", og det fulle navnet til User1 på WS-1-arbeidsstasjonen vil se ut som "WS-1\User1". La oss forestille oss at det opprettes en mappemappe på SRV-1-serveren, som tilgang gis over nettverket til brukere Bruker1 - for lesing (R), Bruker2 - for lesing og skriving (RW). Hovedpoenget i denne modellen er at SRV-1 datamaskinen "ikke vet" noe om kontoene til SRV-2, WS-1, WS-2 datamaskiner, samt alle andre datamaskiner på nettverket. Hvis en bruker ved navn Bruker1 logger inn lokalt på en datamaskin, for eksempel WS-2 (eller, som de sier, "logger inn med det lokale navnet Bruker1 på datamaskinen WS-2"), så når du prøver å få tilgang fra denne datamaskinen over nettverket, mappe på SRV-1-serveren, vil serveren be brukeren om et brukernavn og passord (bortsett fra hvis brukere med samme brukernavn har samme passord).

"Workgroup"-modellen er lettere å lære, det er ikke nødvendig å lære de komplekse konseptene til Active Directory. Men når det brukes på et nettverk med et stort antall datamaskiner og nettverksressurser, blir det svært vanskelig å administrere brukernavn og passord - du må manuelt opprette de samme kontoene med de samme passordene på hver datamaskin (som gir ressursene for deling på nettverket), som er svært arbeidskrevende, eller å opprette én konto for alle brukere med ett passord for alle (eller ikke noe passord i det hele tatt), noe som i stor grad reduserer nivået av informasjonsbeskyttelse. Derfor anbefales "Workgroup"-modellen bare for nettverk med 3 til 10 datamaskiner (og enda bedre - ikke mer enn 5), forutsatt at det ikke er en med et Windows Server-system blant alle datamaskinene.

domenemodell

I domenemodellen er det en enkelt katalogtjenester-database som er tilgjengelig for alle datamaskiner på nettverket. For å gjøre dette, er spesialiserte servere installert på nettverket, kalt domenekontrollere som lagrer denne databasen på harddiskene sine. På fig. 6.2. diagrammet for domenemodellen vises. Servere DC-1 og DC-2 er domenekontrollere, de lagrer domenedatabasen med kontoer (hver kontroller beholder sin egen kopi av databasen, men alle endringer som gjøres i databasen på en av serverne blir replikert til andre kontrollere).


Ris. 6.2.

I denne modellen, hvis for eksempel på SRV-1-serveren, som er medlem av domenet, delt tilgang gis til mappemappen, kan tilgangsrettigheter til denne ressursen ikke bare tildeles kontoene til den lokale SAM-databasen til denne serveren, men viktigst av alt, til kontoene som er lagret i domenedatabasen. I figuren, for å få tilgang til mappen, gis tilgangsrettigheter til én lokal konto til SRV-1-datamaskinen og flere domenekontoer (bruker- og brukergrupper). I administrasjonsmodellen for domenesikkerhet logger en bruker på en datamaskin ("logger på") med sin egen domenekonto og, uavhengig av datamaskinen som registreringen ble utført på, får tilgang til de nødvendige nettverksressursene. Og det er ikke nødvendig å opprette et stort antall lokale kontoer på hver datamaskin, alle oppføringer er opprettet én gang i domenedatabasen. Og ved hjelp av en domenedatabase er utført sentralisert tilgangskontroll til nettverksressurser uavhengig av antall datamaskiner på nettverket.

Formålet med Active Directory-katalogtjenesten

En katalog (katalog) kan lagre forskjellig informasjon relatert til brukere, grupper, datamaskiner, nettverksskrivere, fildelinger og så videre - vi vil kalle alle disse objektene. Katalogen lagrer også informasjon om selve objektet, eller dets egenskaper, kalt attributter. Attributtene som er lagret i katalogen om en bruker kan for eksempel være navnet på lederen, telefonnummer, adresse, påloggingsnavn, passord, grupper de tilhører og mer. For å gjøre kataloglagring nyttig for brukere, må det være tjenester som samhandler med katalogen. Du kan for eksempel bruke en katalog som et oppbevaringssted for informasjon for å autentisere en bruker, eller som et sted å sende en spørring for å finne informasjon om et objekt.

Active Directory er ikke bare ansvarlig for å lage og organisere disse små objektene, men også for store objekter som domener, OU-er (organisasjonsenheter) og nettsteder.

Les nedenfor for grunnleggende termer som brukes i sammenheng med Active Directory-katalogtjenesten.

Katalogtjeneste Active Directory (forkortet AD ) muliggjør effektiv drift av et komplekst bedriftsmiljø ved å tilby følgende funksjoner:

  • Single sign-on online; Brukere kan logge på nettverket med ett enkelt brukernavn og passord og fortsatt ha tilgang til alle nettverksressurser og tjenester (nettverksinfrastrukturtjenester, fil- og utskriftstjenester, applikasjons- og databaseservere, etc.);
  • Informasjonssikkerhet. Autentisering og ressurstilgangskontroller innebygd i Active Directory gir sentralisert nettverkssikkerhet;
  • Sentralisert ledelse. Administratorer kan sentralt administrere alle bedriftsressurser;
  • Administrasjon ved hjelp av gruppepolicy. Når en datamaskin starter opp eller en bruker logger på systemet, oppfylles kravene til gruppepolicyer; innstillingene deres er lagret i gruppepolicyobjekter(GPO) og gjelder for alle bruker- og datamaskinkontoer på nettsteder, domener eller organisasjonsenheter;
  • DNS-integrasjon. Funksjonen til katalogtjenester er helt avhengig av driften av DNS-tjenesten. På sin side kan DNS-servere lagre informasjon om soner i Active Directory-databasen;
  • Katalogutvidbarhet. Administratorer kan legge til nye objektklasser til katalogskjemaet eller legge til nye attributter til eksisterende klasser;
  • Skalerbarhet. Active Directory-tjenesten kan dekke både ett domene og mange domener kombinert til et tre av domener, og en skog kan bygges fra flere domenetrær;
  • Informasjonsreplikering. Active Directory bruker overhead-replikering i et multi-master-skjema ( multi-master), som lar deg endre Active Directory-databasen på en hvilken som helst domenekontroller. Tilstedeværelsen av flere kontrollere i domenet gir feiltoleranse og muligheten til å distribuere nettverksbelastning;
  • Fleksibilitet for katalogspørringer. En Active Directory-database kan brukes til raskt å slå opp et hvilket som helst AD-objekt ved å bruke dets egenskaper (for eksempel brukernavn eller e-postadresse, skrivertype eller plassering osv.);
  • Standard programmeringsgrensesnitt. For programvareutviklere gir katalogtjenesten tilgang til alle funksjonene (verktøyene) i katalogen og støtter aksepterte standarder og programmeringsgrensesnitt (API).

Et bredt spekter av forskjellige objekter kan opprettes i Active Directory. Et objekt er en unik enhet i en katalog og har vanligvis mange attributter som hjelper til med å beskrive og gjenkjenne den. En brukerkonto er et eksempel på et objekt. Denne objekttypen kan ha mange attributter som fornavn, etternavn, passord, telefonnummer, adresse og mange flere. På samme måte kan en delt skriver også være et objekt i Active Directory og dens attributter er navnet, plasseringen og så videre. Objektattributter hjelper ikke bare med å identifisere et objekt, men lar deg også søke etter objekter i katalogen.

Terminologi

Katalogtjeneste Windows Server er bygget på generelt aksepterte teknologistandarder. Den opprinnelige standarden for katalogtjenester var X.500, som var ment å bygge hierarkiske trelignende skalerbare kataloger med muligheten til å utvide både objektklasser og sett med attributter (egenskaper) for hver enkelt klasse. Den praktiske implementeringen av denne standarden har imidlertid vist seg å være ineffektiv når det gjelder ytelse. Deretter ble det, på grunnlag av X.500-standarden, utviklet en forenklet (lett) versjon av katalogbyggestandarden, kalt LDAP (Lightweight Directory Access Protocol). LDAP-protokollen beholder alle de grunnleggende egenskapene til X.500 (hierarkisk katalogbyggesystem, skalerbarhet, utvidbarhet ), men lar deg samtidig implementere denne standarden effektivt i praksis. Begrepet " lett " (" lett") i navnet til LDAP reflekterer hovedmålet med å utvikle protokollen: å lage et verktøysett for å bygge en katalogtjeneste som har tilstrekkelig funksjonell kraft til å løse grunnleggende oppgaver, men som ikke er overbelastet med komplekse teknologier som gjør implementeringen av katalogtjenester ineffektiv For øyeblikket er LDAP standardmetoden for å få tilgang til informasjon på nettkataloger og spiller en grunnleggende rolle i en rekke produkter som f.eks. autentiseringssystemer, e-postprogrammer og e-handelsapplikasjoner. Det er over 60 kommersielle LDAP-servere på markedet i dag, med omtrent 90 % av dem er frittstående LDAP-katalogservere, mens resten tilbys som komponenter av andre applikasjoner.

LDAP-protokollen definerer klart rekkevidden av katalogoperasjoner som en klientapplikasjon kan utføre. Disse operasjonene deles inn i fem grupper:

  • etablere en forbindelse med katalogen;
  • søk etter informasjon i den;
  • endring av innholdet;
  • legge til et objekt;
  • slette et objekt.

Annet enn LDAP katalogtjeneste Active Directory bruker også en autentiseringsprotokoll Kerberos og en DNS-tjeneste for nettverksoppslag av katalogtjenestekomponenter (domenekontrollere, globale katalogservere, Kerberos-tjeneste osv.).

Domene

Grunnenheten i Active Directory-sikkerhetssystemet er domene. Domenet utgjør det administrative ansvarsområdet. Domenedatabasen inneholder kontoer brukere, grupper og datamaskiner. De fleste av kfungerer på domenenivå (brukerautentisering, ressurstilgangskontroll, tjenestekontroll, replikeringskontroll, sikkerhetspolicyer).

Active Directory-domenenavn følger samme mønster som navn i DNS-navneområdet. Og dette er ingen tilfeldighet. DNS-tjenesten er et middel for å finne domenekomponenter – først og fremst domenekontrollere.

Domenekontrollere- spesielle servere som lagrer den delen av Active Directory-databasen som tilsvarer dette domenet. Hovedfunksjonene til domenekontrollere:

  • lagring av Active Directory-databasen(organisering av tilgang til informasjonen i katalogen, inkludert håndtering av denne informasjonen og endring av den);
  • synkronisering av endringer i AD(endringer i AD-databasen kan gjøres på hvilken som helst av domenekontrollerne, alle endringer som gjøres på en av kontrollerene vil bli synkronisert med kopier som er lagret på andre kontrollere);
  • bruker autentisering(enhver av domenekontrollerne sjekker legitimasjonen til brukere som logger på klientsystemer).

Det anbefales sterkt å installere minst to domenekontrollere i hvert domene - for det første for å beskytte mot tap av Active Directory-databasen i tilfelle en kontrollerfeil, og for det andre for å fordele belastningen mellom controllers.it.company.ru har et underdomene dev.it.company.ru , opprettet for programvareutviklingsavdelingen til IT-tjenesten.

  • å desentralisere administrasjonen av katalogtjenester (for eksempel når et selskap har filialer som er geografisk fjernt fra hverandre, og sentralisert styring er vanskelig av tekniske årsaker);
  • for å forbedre ytelsen (for selskaper med et stort antall brukere og servere er spørsmålet om å øke ytelsen til domenekontrollere relevant);
  • å administrere replikering mer effektivt (hvis domenekontrollere er langt fra hverandre, kan replikering i en ta lengre tid og skape problemer ved å bruke usynkroniserte data);
    • skogsrotdomene ( skogrotdomene), kan ikke dette domenet slettes (det lagrer informasjon om konfigurasjonen av skogen og domenetrærne som utgjør den).

Organisatoriske enheter (OD).

Organisatoriske enheter (Organisasjonsenheter, ou) - beholdere i AD som er opprettet for å gruppere objekter sammen med det formål delegering av administrative rettigheter og bruke gruppepolicyer i domenet. OP eksisterer bare innenfor domener og kan kombineres kun objekter fra eget domene. OP-er kan nestes i hverandre, noe som gjør det mulig å bygge et komplekst trelignende hierarki av beholdere innenfor et domene og utøve mer fleksibel administrativ kontroll. I tillegg kan OP-er opprettes for å gjenspeile det administrative hierarkiet og organisasjonsstrukturen til et selskap.

Global katalog

Global katalog er en liste alle gjenstander som finnes i Active Directory-skogen. Som standard inneholder domenekontrollere bare informasjon om objekter i domenet. Global katalogserver er en domenekontroller som holder informasjon om hvert objekt (men ikke alle attributtene til disse objektene) i skogen.

Active Directory

Active Directory("Active Directory", AD) - LDAP-kompatibel implementering av et selskaps katalogtjeneste Microsoft for operativsystemer i familien Windows NT. Active Directory lar administratorer bruke gruppepolicyer for å sikre en konsistent brukeropplevelsesinnstilling, distribuere programvare til flere datamaskiner gjennom gruppepolicyer eller gjennom System Center Configuration Manager(tidligere Microsoft Systems Management Server), installer operativsystem-, applikasjons- og serverprogramvareoppdateringer på alle datamaskiner i nettverket ved å bruke oppdateringstjenesten Windows Server . Active Directory lagrer miljødata og innstillinger i en sentralisert database. nettverk Active Directory kan være av forskjellige størrelser: fra flere titalls til flere millioner objekter.

Opptreden Active Directory fant sted i 1999, ble produktet først utgitt med Windows 2000 Server, og ble deretter modifisert og forbedret ved utgivelse Windows Server 2003. I ettertid Active Directory har blitt forbedret i Windows Server 2003 R2, Windows Server 2008 og Windows Server 2008 R2 og omdøpt til Active Directory-domenetjenester. Katalogtjenesten het tidligere NT-katalogtjeneste (NTDS), kan dette navnet fortsatt finnes i noen kjørbare filer.

I motsetning til versjonene Windows før Windows 2000 som hovedsakelig brukte protokollen NetBIOS for nettverk, service Active Directory integrert med DNS og TCP/IP. Standard autentiseringsprotokoll er Kerberos. Hvis klienten eller applikasjonen ikke støtter autentisering Kerberos, brukes protokollen NTLM .

Enhet

Objekter

Active Directory har en hierarkisk struktur bestående av objekter. Objekter faller inn i tre hovedkategorier: ressurser (som skrivere), tjenester (som e-post) og bruker- og datamaskinkontoer. Active Directory gir informasjon om objekter, lar deg organisere objekter, kontrollere tilgang til dem og etablerer sikkerhetsregler.

Objekter kan være beholdere for andre objekter (sikkerhets- og distribusjonsgrupper). Et objekt er unikt identifisert med navnet og har et sett med attributter - egenskaper og data som det kan inneholde; sistnevnte på sin side avhenger av typen objekt. Attributter er den konstituerende basen av et objekts struktur og er definert i skjemaet. Skjemaet definerer hvilke typer objekter som kan eksistere.

Selve skjemaet består av to typer objekter: skjemaklasseobjekter og skjemaattributtobjekter. Ett skjemaklasseobjekt definerer én objekttype Active Directory(for eksempel et brukerobjekt), og ett skjemaattributtobjekt definerer et attributt som et objekt kan ha.

Hvert attributtobjekt kan brukes i flere forskjellige skjemaklasseobjekter. Disse objektene kalles skjemaobjekter (eller metadata) og lar deg endre og legge til skjemaet etter behov. Hvert skjemaobjekt er imidlertid en del av objektdefinisjonene Active Directory, så deaktivering eller endring av disse objektene kan ha alvorlige konsekvenser, siden som et resultat av disse handlingene vil strukturen bli endret Active Directory. Endringen til skjemaobjektet overføres automatisk til Active Directory. Når et skjemaobjekt er opprettet, kan det ikke slettes, det kan bare deaktiveres. Vanligvis er alle skjemaendringer nøye planlagt.

Container lignende gjenstand i den forstand at den også har attributter og tilhører navneområdet , men i motsetning til et objekt, står ikke en beholder for noe spesifikt: den kan inneholde en gruppe objekter eller andre beholdere.

Struktur

Det øverste nivået i strukturen er skogen - samlingen av alle objekter, attributter og regler (attributtsyntaks) i Active Directory. Skogen inneholder ett eller flere trær forbundet med transitiv tillitsforhold . Treet inneholder ett eller flere domener, også forbundet i et hierarki av transitive tillitsforhold. Domener identifiseres ved deres DNS-navnestrukturer - navneområder.

Objekter i et domene kan grupperes i containere - OUer. Organisasjonsenheter lar deg lage et hierarki innenfor et domene, forenkle administrasjonen og lar deg modellere den organisatoriske og/eller geografiske strukturen til et selskap i Active Directory. Divisjoner kan inneholde andre divisjoner. Selskap Microsoft anbefaler å bruke så få domener som mulig i Active Directory, og bruke inndelinger for strukturering og politikk. Gruppepolicyer brukes ofte spesifikt på organisasjonsenheter. Gruppepolicyer er i seg selv objekter. En avdeling er det laveste nivået der forvaltningsmyndighet kan delegeres.

En annen måte å dele på Active Directory er nettsteder , som er en måte å fysisk (i stedet for logisk) gruppering basert på nettverkssegmenter. Nettsteder er delt inn i de med tilkoblinger via lavhastighetskanaler (for eksempel via globale nettverk, ved bruk av virtuelle private nettverk) og via høyhastighetskanaler (for eksempel via et lokalnettverk). Et nettsted kan inneholde ett eller flere domener, og et domene kan inneholde ett eller flere nettsteder. Ved utforming Active Directory det er viktig å vurdere nettverkstrafikken som genereres når data synkroniseres mellom nettsteder.

Nøkkel designbeslutning Active Directory er beslutningen om å dele informasjonsinfrastrukturen inn i hierarkiske domener og toppnivådivisjoner. Typiske modeller som brukes for denne divisjonen er inndelinger etter funksjonelle inndelinger av selskapet, etter geografisk plassering og etter roller i selskapets informasjonsinfrastruktur. Kombinasjoner av disse modellene brukes ofte.

Fysisk struktur og replikering

Fysisk lagres informasjon på en eller flere tilsvarende domenekontrollere som har erstattet de som brukes i Windows NT primære og backup domenekontrollere, selv om en såkalt "single-master operations" server, som kan emulere en primær domenekontroller, beholdes for noen operasjoner. Hver domenekontroller beholder en lese-/skrivekopi av dataene. Endringer som gjøres på én kontroller synkroniseres med alle domenekontrollere under replikering. Servere hvor tjenesten selv Active Directory ikke installert, men som er inkludert i domenet Active Directory, kalles medlemsservere.

replikering Active Directory utført på forespørsel. Service Kunnskapskonsistenssjekker oppretter en replikeringstopologi som bruker nettstedene som er definert i systemet for å administrere trafikk. Intrasite replikering utføres ofte og automatisk av en konsistenskontroller (ved å varsle replikeringspartnere om endringer). Replikering mellom nettsteder kan konfigureres for hver kanal på et nettsted (avhengig av kvaliteten på kanalen) - en annen "rate" (eller "kostnad") kan tildeles hver kanal (for eksempel DS3, , ISDN etc.) og replikeringstrafikk vil være begrenset, planlagt og rutet i henhold til det tilordnede koblingsestimatet. Replikeringsdata kan transitivt reise på tvers av flere nettsteder via nettstedkoblingsbroer hvis "poengsummen" er lav, selv om AD automatisk tildeler en lavere poengsum for nettsted-til-sted-koblinger enn for transitive linker. Sted-til-sted-replikering utføres av brohodeservere på hvert nettsted, som deretter replikerer endringene til hver domenekontroller på nettstedet deres. Intradomene replikering skjer i henhold til protokollen RPC protokoll IP, på tvers av domener - kan også bruke protokollen SMTP.

Hvis strukturen Active Directory inneholder flere domener, for å løse problemet med å finne objekter, brukes det global katalog: En domenekontroller som inneholder alle objektene i skogen, men med et begrenset sett med attributter (en delvis replika). Katalogen lagres på spesifiserte globale katalogservere og betjener forespørsler på tvers av domener.

Enkeltvertsfunksjonen gjør at forespørsler kan håndteres når flervertsreplikering ikke er tillatt. Det er fem typer slike operasjoner: Domain Controller Emulation (PDC Emulator), Relative Identifier Host (Relative Identifier Master eller RID Master), Infrastructure Host (Infrastructure Master), Schema Host (Schema Master) og Domain Naming Host (domenenavning master) ). De tre første rollene er unike innenfor domenet, de to siste er unike innenfor hele skogen.

utgangspunkt Active Directory kan deles inn i tre logiske lagre eller "partisjoner". Skjemaet er en mal for Active Directory og definerer alle objekttyper, deres klasser og attributter, attributtsyntaks (alle trær er i samme skog fordi de har samme skjema). Konfigurasjonen er strukturen til skogen og trærne Active Directory. Et domene lagrer all informasjon om objekter som er opprettet i det domenet. De to første lagrene er replikert til alle domenekontrollere i skogen, den tredje partisjonen er fullstendig replikert mellom replikakontrollere innenfor hvert domene og delvis replikert til globale katalogservere.

navngi

Active Directory støtter følgende objektnavneformater: generiske typenavn UNC, URL og LDAP URL. Versjon LDAP X.500 navneformat brukes internt Active Directory.

Hvert objekt har fornemt navn (Engelsk) fornemt navn, DN). For eksempel et skriverobjekt med navn HPLaser3 i Marketing OU og i foo.org-domenet vil ha følgende DN: CN=HPLaser3,OU=Marketing,DC=foo,DC=org , der CN er det vanlige navnet, OU er seksjonen og DC er domenet objektklasse. Fornemme navn kan ha mange flere deler enn de fire delene i dette eksemplet. Objekter har også kanoniske navn. Dette er de utmerkede navnene skrevet i omvendt rekkefølge, uten identifikatorer og med skråstreker som skilletegn: foo.org/Marketing/HPLaser3 . For å definere et objekt i beholderen, bruk relativt fornemt navn : CN=HPLaser3 . Hvert objekt har også en globalt unik identifikator ( GUID) er en unik og uforanderlig 128-bits streng som brukes i Active Directory for søk og replikering. Enkelte objekter har også et brukernavn ( UPN, i samsvar med RFC 822) i formatet objekt@domene.

Integrasjon med UNIX

Ulike nivåer av interaksjon med Active Directory kan implementeres i de fleste UNIX-lignende operativsystemer gjennom standard-kompatible LDAP klienter, men slike systemer forstår vanligvis ikke de fleste attributtene knyttet til komponenter Windows slik som gruppepolicyer og støtte for enveisstiftelser.

Tredjepartsleverandører tilbyr integrasjon Active Directory på plattformer UNIX, gjelder også UNIX, linux, MacOS X og en rekke applikasjoner basert Java, med produktpakke:

Skjematiske tillegg følger med Windows Server 2003 R2 inkludere attributter som er nært nok relatert til RFC 2307 til å være til generell bruk. RFC 2307 basisimplementeringer, nss_ldap og pam_ldap, foreslått PADL.com, støtter disse attributtene direkte. Standardordningen for gruppemedlemskap følger RFC 2307bis (forslag). Windows Server 2003 R2 inkluderer Microsoft Management Console for å lage og redigere attributter.

Et alternativ er å bruke en annen katalogtjeneste som 389 Katalogserver(tidligere Fedora Directory Server, FDS), eB2Bcom ViewDS v7.1 XML-aktivert katalog eller Sun Java System Directory Server fra Sun Microsystems, som utfører toveis synkronisering med Active Directory, og implementerer dermed "reflektert" integrasjon når klienter UNIX og linux er autentisert FDS, og klienter Windows er autentisert Active Directory. Et annet alternativ er å bruke Åpne LDAP med mulighet for gjennomskinnelig overlegg som utvider elementene til den eksterne serveren LDAP tilleggsattributter lagret i den lokale databasen.

Active Directory automatisert bruk Kraftskall .

Litteratur

  • Rand Morimoto, Kenton Gardiner, Michael Noel, Joe Koka Microsoft Exchange Server 2003. Komplett guide = Microsoft Exchange Server 2003 sluppet løs. - M .: "Williams", 2006. - S. 1024. - ISBN 0-672-32581-0

se også

Linker

Notater

Hva vil hjelpe Active Directory spesialister?

Jeg vil gi en liten liste over "godbiter" som kan fås ved å distribuere Active Directory:

  • en enkelt brukerregistreringsdatabase, som er lagret sentralt på en eller flere servere; Når en ny ansatt dukker opp på kontoret, trenger du derfor bare å opprette en konto for ham på serveren og spesifisere hvilke arbeidsstasjoner han skal ha tilgang til;
  • siden alle domeneressurser er indeksert, muliggjør dette enkelt og raskt søk for brukere; for eksempel hvis du trenger å finne en fargeskriver i en avdeling;
  • kombinasjonen av å bruke NTFS-tillatelser, gruppepolicyer og delegering av kontroll vil tillate deg å finjustere og distribuere rettigheter mellom domenemedlemmer;
  • roaming-brukerprofiler lar deg lagre viktig informasjon og konfigurasjonsinnstillinger på serveren; faktisk, hvis en bruker med en roaming-profil i domenet setter seg ned for å jobbe på en annen datamaskin og skriver inn brukernavn og passord, vil han se skrivebordet med sine vanlige innstillinger;
  • ved hjelp av gruppepolicyer kan du endre innstillingene for brukeroperativsystemer, fra å la brukeren sette bakgrunnsbilde på skrivebordet til sikkerhetsinnstillinger, samt distribuere programvare over nettverket, for eksempel Volume Shadow Copy-klient, etc.;
  • mange programmer (proxy-servere, databaseservere, etc.) ikke bare produsert av Microsoft i dag har lært å bruke domeneautentisering, så du trenger ikke opprette en annen brukerdatabase, men du kan bruke en eksisterende;
  • bruken av Remote Installation Services letter installasjonen av systemer på arbeidsstasjonene, men fungerer i sin tur bare med den innebygde katalogtjenesten.

Og dette er ikke en komplett liste over funksjoner, men mer om det senere. Nå skal jeg prøve å fortelle selve logikken i konstruksjonen Active Directory, men igjen er det verdt å finne ut hva guttene våre er laget av det guttene våre er bygget av Active Directory er domener, trær, skoger, organisasjonsenheter, bruker- og datamaskingrupper.

Domener - Dette er den grunnleggende logiske bygningsenheten. Sammenlignet med arbeidsgrupper AD-domener er sikkerhetsgrupper som har én enkelt registreringsbase, mens arbeidsgrupper bare er en logisk gruppering av maskiner. AD bruker DNS (Domain Name Server) for navne- og oppslagstjenester, ikke WINS (Windows Internet Name Service), slik tilfellet var i tidligere versjoner av NT. Dermed er datamaskinnavn i et domene for eksempel buh.work.com, der buh er navnet på en datamaskin i work.com-domenet (selv om dette ikke alltid er tilfelle).

Arbeidsgrupper bruker NetBIOS-navn. For å være vert for en domenestruktur AD du kan bruke en ikke-Microsoft DNS-server. Men den må være kompatibel med BIND 8.1.2 eller høyere og støtte SRV()-poster så vel som Dynamic Registration Protocol (RFC 2136). Hvert domene har minst én domenekontroller som er vert for den sentrale databasen.

Trær - Dette er strukturer med flere domene. Roten til denne strukturen er hoveddomenet du oppretter underordnede domener for. Faktisk bruker Active Directory et hierarkisk konstruksjonssystem som ligner på strukturen til domener i DNS.

Hvis vi har et work.com-domene (førstenivådomene) og oppretter to underordnede domener for det, first.work.com og second.work.com (her er første og andre andrenivådomener, ikke en datamaskin i domene, som i tilfellet beskrevet ovenfor), så får vi som et resultat et tre med domener.

Trær som en logisk struktur brukes når du trenger å skille grenene til et selskap, for eksempel etter geografiske trekk, eller av andre organisatoriske årsaker.

AD bidrar til automatisk å skape tillitsforhold mellom hvert domene og dets underdomener.

Dermed fører opprettelsen av domenet first.work.com til automatisk organisering av et toveis tillitsforhold mellom overordnet work.com og barnet first.work.com (tilsvarende for second.work.com). Derfor kan tillatelser brukes fra det overordnede domenet til det underordnede domenet, og omvendt. Det er ikke vanskelig å anta at det vil eksistere tillitsforhold for barnedomener også.

En annen egenskap ved tillitsforhold er transitivitet. Vi får – et tillitsforhold til work.com-domenet opprettes for net.first.work.com-domenet.

Skog - Akkurat som trær er de flerdomenestrukturer. Men skog er en forening av trær som har forskjellige rotdomener.

Anta at du bestemmer deg for å ha flere domener kalt work.com og home.net og opprette underordnede domener for dem, men fordi tld (toppnivådomene) ikke er under din kontroll, kan du i dette tilfellet organisere en skog ved å velge en av de første nivådomener er roten. Det fine med å lage en skog i dette tilfellet er det toveis tillitsforholdet mellom disse to domenene og deres underordnede domener.

Men når du arbeider med skog og trær, husk følgende:

  • du kan ikke legge til et eksisterende domene i treet
  • du kan ikke inkludere et allerede eksisterende tre i skogen
  • hvis domener er plassert i en skog, kan de ikke flyttes til en annen skog
  • du kan ikke slette et domene som har underordnede domener

Organisasjonsenheter - i prinsippet kan kalles underdomener. lar deg gruppere brukerkontoer, brukergrupper, datamaskiner, delte ressurser, skrivere og andre OUer (organisasjonsenheter) i et domene. Den praktiske fordelen med å bruke dem er muligheten til å delegere rettigheter til å administrere disse enhetene.

Enkelt sagt er det mulig å utpeke en administrator i et domene som kan administrere OU, men som ikke har rettigheter til å administrere hele domenet.

En viktig funksjon ved OU-er, i motsetning til grupper, er muligheten til å bruke gruppepolicyer på dem. "Hvorfor kan ikke det opprinnelige domenet deles opp i flere domener i stedet for å bruke en OU?" - du spør.

Mange eksperter anbefaler å ha ett domene når det er mulig. Årsaken til dette er desentraliseringen av administrasjonen når du oppretter et ekstra domene, siden administratorene for hvert slikt domene får ubegrenset kontroll (la meg minne deg på at når du delegerer rettigheter til OU-administratorer, kan du begrense funksjonaliteten deres).

I tillegg til dette, for å opprette et nytt domene (til og med et underordnet domene), trenger du en annen kontroller. Hvis du har to separate divisjoner koblet sammen med en langsom kommunikasjonskanal, kan det oppstå replikeringsproblemer. I dette tilfellet vil det være mer hensiktsmessig å ha to domener.

Det er også en annen nyanse ved bruk av gruppepolicyer: retningslinjer som definerer passordinnstillinger og kontosperringer kan bare brukes på domener. For organisasjonsenheter ignoreres disse policyinnstillingene.

Nettsteder - Dette er en måte å fysisk skille katalogtjenesten. Per definisjon er et nettsted en gruppe datamaskiner koblet sammen med raske datakoblinger.

Hvis du har flere filialer i forskjellige deler av landet, koblet sammen medr, kan du lage din egen nettside for hver filial. Dette gjøres for å forbedre påliteligheten til katalogreplikering.

En slik partisjon av AD påvirker ikke prinsippene for logisk konstruksjon, derfor, akkurat som et nettsted kan inneholde flere domener, og omvendt, kan et domene inneholde flere nettsteder. Men denne katalogtjenestetopologien er full av en hake. Som regel brukes Internett til å kommunisere med filialer - et veldig usikkert miljø. Mange bedrifter bruker sikkerhetstiltak som brannmurer. Katalogtjenesten bruker i sitt arbeid omtrent ett og et halvt dusin porter og tjenester, hvis åpning for AD-trafikk å passere gjennom brannmuren faktisk vil avsløre den "utenfor". Løsningen på problemet er å bruke tunnelteknologi, samt tilstedeværelsen av en domenekontroller på hvert nettsted for å fremskynde behandlingen av forespørsler fra AD-klienter.

Logikken til neste katalogtjenestekomponenter presenteres. Det kan sees at skogen inneholder to domenetrær, der rotdomenet til treet på sin side kan inneholde OUer og grupper av objekter, samt ha underordnede domener (i dette tilfellet ett for hver). Underdomener kan også inneholde objektgrupper og OUer og ha underordnede domener (de er ikke vist i figuren). Og så videre. La meg minne deg på at organisasjonsenheter kan inneholde organisasjonsenheter, objekter og grupper av objekter, og grupper kan inneholde andre grupper.

Bruker- og datamaskingrupper - brukes til administrative formål og har samme betydning som når de brukes på lokale maskiner i et nettverk. I motsetning til organisasjonsenheter kan ikke gruppepolicyer brukes på grupper, men de kan delegeres kontroll. Innenfor rammen av Active Directory-skjemaet er det to typer grupper: sikkerhetsgrupper (brukes til å differensiere tilgangsrettigheter til nettverksobjekter) og distribusjonsgrupper (brukes hovedsakelig for å sende e-postmeldinger, for eksempel i Microsoft Exchange Server).

De er klassifisert i henhold til deres omfang:

  • universelle grupper kan inkludere brukere i skogen så vel som andre universelle grupper eller globale grupper fra et hvilket som helst domene i skogen
  • domene globale grupper kan inkludere domenebrukere og andre globale grupper av samme domene
  • domene lokale grupper brukes til å differensiere tilgangsrettigheter, kan inkludere domenebrukere, så vel som universelle grupper og globale grupper av alle domene i skogen
  • lokale datamaskingrupper– grupper som SAM (sikkerhetskontoadministrator) til den lokale maskinen inneholder. Omfanget deres er bare begrenset til denne maskinen, men de kan inkludere lokale grupper av domenet der datamaskinen er plassert, så vel som universelle og globale grupper av deres eget domene eller et annet som de stoler på. Du kan for eksempel inkludere en bruker fra den lokale domenegruppen Brukere i Administratorgruppen på den lokale maskinen, og dermed gi ham administrative rettigheter, men bare for denne datamaskinen
Artikkelvurdering:
1 stjerne2 stjerner3 stjerner4 stjerner5 stjerner(Ingen vurderinger ennå)
Laster inn...
Slik deler du med venner:
Relaterte artikler
Lukk
Finn på stedet
For eksempel: typer gips