Det har lenge vært inkludert i kategorien konservative prinsipper for logisk konstruksjon av nettverksinfrastruktur. Men mange administratorer fortsetter å bruke Windows NT-arbeidsgrupper og domener i arbeidet sitt. Implementering av en katalogtjeneste vil være interessant og nyttig for både nybegynnere og erfarne administratorer for å sentralisere nettverksadministrasjon og sikre et tilstrekkelig sikkerhetsnivå.
Active Directory, en teknologi som dukket opp i Win2K-serien for seks år siden, kan beskrives som revolusjonerende. Den utkonkurrerer NT 4-domener i størrelsesordener i fleksibilitet og skalerbarhet, for ikke å nevne arbeidsgruppenettverk.
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.
- globale domenegrupper kan inkludere domenebrukere og andre globale grupper i samme domene;
- Lokale domenegrupper brukes til å differensiere tilgangsrettigheter, de kan inkludere domenebrukere, så vel som universelle grupper og globale grupper for alle domene i skogen;
- lokale datamaskingrupper - grupper som SAM (security account manager) inneholder lokal maskin... De er begrenset til bare en gitt maskin, men de kan inkludere lokale grupper for domenet der datamaskinen er plassert, samt universelle og globale grupper for domenet deres eller et annet som de stoler på. Du kan for eksempel legge til en bruker fra den lokale domenegruppen Brukere til Administratorgruppen på den lokale maskinen, og dermed gi ham administratorrettigheter, men bare for denne datamaskinen.
Nettsteder
Dette er en måte å fysisk skille katalogtjenesten på. Per definisjon er et nettsted en gruppe datamaskiner som er koblet sammen raske kanaler Data overføring.
For eksempel, hvis du har flere filialer i forskjellige deler av landet forbundet medr, kan du for hver filial lage din egen nettside. Dette gjøres for å forbedre påliteligheten til katalogreplikering.
Denne inndelingen av AD påvirker ikke prinsippene for logisk konstruksjon, derfor, siden et nettsted kan inneholde flere domener, og omvendt, kan et domene inneholde flere nettsteder. Men denne katalogtjenestetopologien er full av en hake. Vanligvis brukes Internett til å kommunisere med avdelingskontorer - et veldig usikkert miljø. Mange selskaper bruker sikkerhetsfunksjoner som brannmurer. Katalogtjenesten i sitt arbeid bruker omtrent halvannet dusin porter og tjenester, og åpner som for AD-trafikk å passere gjennom brannmuren faktisk vil avsløre den "ute". Løsningen er å bruke tunnelteknologi og ha en domenekontroller på hver side for å fremskynde behandlingen av AD-klientforespørsler.
Katalogtjenesteenhet
For å gi et visst sikkerhetsnivå, må ethvert operativsystem ha filer som inneholder en brukerdatabase. V tidlige versjoner Windows NT brukte SAM-filen (Security Accounts Manager) for dette. Den inneholdt brukerlegitimasjon og var kryptert. SAM brukes også i dag i NT 5-familien av operativsystemer (Windows 2000 og nyere).
Når du promoterer en medlemsserver til en domenekontroller ved å bruke DCPROMO-kommandoen (som faktisk starter installasjonsveiviseren for Directory Service), vil undersystemet Windows-sikkerhet Server 2000/2003 begynner å bruke en sentralisert AD-database. Du kan enkelt sjekke dette - etter å ha opprettet et domene, prøv å åpne Computer Management snap-in på kontrolleren og finn der " Lokale brukere og grupper". Prøv dessuten å logge på denne serveren med en lokal konto. Det er usannsynlig at du vil lykkes.
De fleste brukerdata er lagret i filen NTDS.DIT (Directory Information Tree). NTDS.DIT er en modifisert database. Den ble opprettet ved hjelp av samme teknologi som Microsoft Access-databasen. Driftsalgoritmer for domenekontrollere inneholder en variant av basens JET-motor Få tilgang til data, som fikk navnet ESE (Extensible Storage Engine). NTDS.DIT og tjenestene som samhandler med denne filen er faktisk en katalogtjeneste.
Strukturen for interaksjon mellom AD-klienter og hoveddatalageret, lik navneområdet til katalogtjenesten, presenteres i artikkelen. For fullstendighetens skyld bør det nevnes bruken av globale identifikatorer. Global Unique Identifier (GUID) er et 128-bits nummer som tildeles hvert objekt når det opprettes for å sikre unikhet. AD-objektnavnet kan endres, men GUID-en forblir uendret.
Global katalog
Du har sikkert allerede lagt merke til at strukturen til AD kan være svært kompleks og inneholde et stort antall objekter. Ta det faktum at et AD-domene kan inneholde opptil 1,5 millioner objekter. Dette kan imidlertid forårsake ytelsesproblemer når du utfører operasjoner. Dette problemet løses ved å bruke den globale katalogen (,). Den inneholder en nedskalert versjon av hele AD-skogen for å øke hastigheten på objektsøk. En global katalog kan eies av spesialutpekte domenekontrollere.
Roller
I AD er det en viss liste over operasjoner, hvis utførelse kan tilordnes bare én kontroller. De kalles roller FSMO (Flexible Single-Master Operations)... Det er 5 FSMO-roller i AD. La oss vurdere dem mer detaljert.
Innenfor skogen skal det være en garanti for det unike ved domenenavn ved å legge til et nytt domene til skogen av domener. En slik garanti gis av utøveren av rollen som eieren av domenenavnoperasjonen ( Domenenavnmester) Aktør i rollen som skjemaeier ( Schema Master ) gjør alle endringer i katalogskjemaet. Domenenavneier- og skjemaeierrollene må være unike innenfor domeneskogen.
Som jeg sa før, når et objekt opprettes, tildeles det en global identifikator, som garanterer dets unikhet. Det er derfor kontrolløren som er ansvarlig for å generere GUID-er og opptrer som eier av relative identifikatorer ( Pårørende ID-mester) må være den eneste innenfor domenet.
I motsetning til NT-domener har AD ikke noe konsept for PDC og BDC (primære og backup-domenekontrollere). En av rollene til FSMO er PDC-emulator(PDC-emulator). Server under Windows-kontroll NT Server kan fungere som en backup domenekontroller i AD. Det er imidlertid kjent at kun én primærkontroller kan brukes i NT-domener. Det er derfor Microsoft har gjort det slik at vi innenfor ett AD-domene kan utpeke en enkelt server - bæreren av PDC-emulatorrollen. Derfor, med avvik fra terminologien, kan vi snakke om tilstedeværelsen av hoved- og backup-domenekontrollerne, som betyr eieren av FSMO-rollen.
Når du sletter og flytter objekter, må en av kontrollerene opprettholde en referanse til det objektet til replikeringen er fullført. Denne rollen spilles av eieren av kataloginfrastrukturen ( Infrastrukturmester).
De tre siste rollene krever unikheten til utøveren innenfor domenet. Alle roller er tildelt den første kontrolleren som er opprettet i skogen. Når du oppretter en forked AD-infrastruktur, kan du delegere disse rollene til andre kontrollere. Det kan også oppstå situasjoner når eieren av en av rollene er utilgjengelig (serveren er nede). I dette tilfellet må du utføre operasjonen med å gripe FSMO-rollen ved å bruke verktøyet NTDSUTIL(vi vil snakke om bruken i de følgende artiklene). Vær imidlertid forsiktig fordi katalogtjenesten antar at den tidligere eieren ikke eksisterer og ikke refererer til den i det hele tatt når den tar en rolle. Returen til nettverket til den forrige utøveren av rollen kan føre til forstyrrelse av funksjonen. Dette er spesielt viktig for skjemaeieren, domenenavneieren og identifikatoren.
Når det gjelder ytelse: rollen til den primære domenekontroller-emulatoren er den mest krevende ressursen til datamaskinens ressurser, så den kan tildeles en annen kontroller. Resten av rollene er ikke så krevende, så når du tildeler dem, kan du bli veiledet av nyansene i den logiske konstruksjonen av AD-skjemaet ditt.
Teoretikerens siste trinn
Å lese artikkelen bør slett ikke overføre deg fra teoretikere til praksis. For før du har tatt i betraktning alle faktorene fra den fysiske plasseringen av verter til den logiske konstruksjonen av hele katalogen, bør du ikke sette deg i gang og bygge et domene med enkle svar på spørsmålene til AD-oppsettveiviseren. Tenk på hvordan domenet ditt vil bli kalt og, hvis du skal opprette underordnede domener for det, hvordan de vil bli navngitt. Hvis du har flere segmenter på nettverket som er koblet sammen med upålitelige lenker, bør du vurdere å bruke nettsteder.
Som en veiledning for installasjon av AD kan jeg råde deg til å bruke artikler og Microsofts kunnskapsbase.
Til slutt noen tips:
- Prøv å ikke kombinere rollene til PDC Emulator og proxy-server på samme maskin hvis mulig. For det første, med et stort antall maskiner i nettverket og Internett-brukere, øker belastningen på serveren, og for det andre, med et vellykket angrep på proxy-tjeneren din, vil ikke bare Internett "falle", men også hoveddomenekontrolleren, og dette er fullt feil arbeid hele nettverket.
- Hvis du konstant administrerer et lokalt nettverk, og ikke kommer til å gjøre det implementering av Active Katalog for kunder, legg til maskiner til domenet gradvis, si fire til fem om dagen. Siden hvis du har et stort antall maskiner på nettverket (50 eller flere) og du klarer det alene, så er det usannsynlig at du klarer deg selv i løpet av helgen, og hvis du har det, så er det ikke kjent hvor korrekt alt blir. I tillegg kan du bruke en fil eller intern e-postserver til å utveksle dokumentasjon innenfor nettverket (dette ble beskrevet av meg i # 11, 2006). Det eneste i dette tilfellet er å finne ut hvordan du konfigurerer brukerrettigheter for å få tilgang til filserveren. Fordi hvis det for eksempel ikke er inkludert i domenet, vil brukerautentisering være basert på poster lokal base SAM. Det er ingen data om domenebrukere. Men hvis filserveren din er blant de første maskinene som er inkludert i AD, og ikke er en domenekontroller, vil det være mulig å autentisere med både den lokale SAM-en og AD-kontoen. Men for det siste alternativet må du tillate (hvis ikke allerede gjort) tilgang til filserveren over nettverket for både domenemedlemmer og lokale kontoer i de lokale sikkerhetsinnstillingene.
O ytterligere tilpasning katalogtjenester (opprette og administrere kontoer, tildele gruppepolicyer osv.) les neste artikkel.
applikasjon
Hva er nytt i Active Directory Windows Server 2003
MED Windows-utgivelse Server 2003 har følgende endringer i Active Directory:
- Det ble mulig å gi nytt navn til et domene etter at det ble opprettet.
- har forbedret seg brukergrensesnitt ledelse. Du kan for eksempel endre attributtene til flere objekter samtidig.
- Dukket opp godt middel Group Policy Management - Group Policy Management Console (gpmc.msc, du må laste den ned fra Microsofts nettsted).
- Funksjonsnivåene til domenet og skogen har endret seg.
O siste endring Jeg må si mer detaljert. Et AD-domene i Windows Server 2003 kan være på ett av følgende nivåer, oppført i rekkefølge etter økende funksjonalitet:
- Windows 2000 blandet (blandet Windows 2000). Det er tillatt å ha kontrollere av forskjellige versjoner - både Windows NT og Windows 2000/2003. Dessuten, hvis Windows 2000/2003-serverne er like, kan NT-serveren, som allerede nevnt, bare fungere som en backup-domenekontroller.
- Windows 2000 Native (native Windows 2000). Det er tillatt å ha kontrollere som kjører Windows Server 2000/2003. Dette nivået er mer funksjonelt, men det har sine egne begrensninger. Du vil for eksempel ikke kunne gi nytt navn til domenekontrollere.
- Windows Server 2003 Interim (mellomliggende Windows Server 2003). Det er tillatt å ha kontrollere som kjører Windows NT samt Windows Server 2003. Brukes for eksempel når en master domenekontroller som kjører en Windows NT-server oppgraderes til W2K3. Nivået har litt mer funksjonalitet enn Windows 2000 Native-nivået.
- Windows Server 2003. Bare kontrollere som kjører Windows Server 2003 er tillatt i domenet. På dette nivået kan du dra full nytte av tjenesten Windows-kataloger Server 2003.
Skogfunksjonsnivåene for domener er nesten de samme som for domener. Det eneste unntaket er at det bare er ett Windows 2000-nivå der Windows NT- og Windows Server 2000/2003-kontrollere kan brukes i en skog.
Det skal bemerkes at endringen funksjonsnivå domene og skog er en irreversibel operasjon. Det vil si at det ikke er noen bakoverkompatibilitet.
1. Korobko I. Active Directory - teori om konstruksjon. // "Systemadministrator", nr. 1, 2004 - C. 90-94. (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=01.2004;a=11).
2. Markov R. Windows 2000/2003-domener - vi nekter arbeidsgruppe... // "Systemadministrator", nr. 9, 2005 - C. 8-11. (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2005; a = 01).
3. Markov R. Installasjon og Windows oppsett 2K-server. // "Systemadministrator", nr. 10, 2004 - C. 88-94. (http://www.samag.ru/cgi-bin/go.pl? q = artikler; n = 10.2004; a = 12).
Alexander Emelyanov
Active Directory (AD) er verktøy utviklet for Microsoft Server-operativsystemet. Den ble opprinnelig laget som en lettvektsalgoritme for tilgang til brukerkataloger. Siden versjonen av Windows Server 2008 er det en integrasjon med autorisasjonstjenester.
Gjør det mulig å håndheve en gruppepolicy som bruker de samme innstillingene og programvaren på alle kontrollerte PC-er ved å bruke System Center Configuration Manager.
Med enkle ord for nybegynnere er dette en serverrolle som lar deg administrere all tilgang og tillatelser fra ett sted. lokalt nettverk
Funksjoner og formål
Microsoft Active Directory - (den såkalte katalogen) en pakke med verktøy som lar deg manipulere brukere og nettverksdata. hovedmålet Oppretting – Forenkler arbeidet til systemadministratorer i store nettverk.
Kataloger inneholder diverse opplysninger relatert til brukere, grupper, nettverksenheter, fildelinger- med et ord, gjenstander. For eksempel bør brukerattributter som er lagret i katalogen være som følger: adresse, pålogging, passord, mobiltelefonnummer, etc. Katalogen brukes som autentiseringspunkter, som du kan finne ut nødvendig informasjon om brukeren med.
Grunnleggende begreper man møter i løpet av arbeidet
Det er en rekke spesialiserte konsepter som gjelder når du arbeider med AD:
- Server er en datamaskin som inneholder alle data.
- Kontroller – En server med en AD-rolle som håndterer forespørsler fra personer som bruker domenet.
- AD-domene - en samling enheter, samlet under ett unikt navn, samtidig med felles base katalogdata.
- Datalageret er den delen av katalogen som er ansvarlig for å lagre og hente data fra enhver domenekontroller.
Hvordan aktive kataloger fungerer
Hovedprinsippene for arbeidet er:
- Autorisasjon, som det blir mulig å bruke en PC på nettverket med ganske enkelt ved å gå inn personlig passord... I dette tilfellet overføres all informasjon fra kontoen.
- Sikkerhet... Active Directory inneholder funksjonalitet for brukergjenkjenning. For ethvert nettverksobjekt kan du eksternt, fra én enhet, angi de nødvendige rettighetene, som vil avhenge av kategoriene og spesifikke brukere.
- Nettverksadministrasjon fra ett punkt. Mens du arbeider med Active Directory, trenger ikke systemadministratoren å rekonfigurere alle PC-er hvis du trenger å endre tilgangsrettigheter, for eksempel til en skriver. Endringer gjøres eksternt og globalt.
- Full DNS-integrasjon... Med dens hjelp oppstår ikke forvirring i AD, alle enheter er utpekt på samme måte som i World Wide Web.
- Stor skala... En samling servere kan kontrolleres av én enkelt Active Directory.
- Søk utføres i henhold til ulike parametere, for eksempel datamaskinnavn, pålogging.
Objekter og attributter
Objekt - et sett med attributter, samlet under sitt eget navn, som representerer en nettverksressurs.
Attributt - egenskaper ved et objekt i katalogen. Disse inkluderer for eksempel brukerens fulle navn, pålogging. Men attributtene til en PC-konto kan være navnet på denne datamaskinen og beskrivelsen.
"Ansatt" - et objekt som har attributtene "Fullt navn", "Posisjon" og "TabN".
LDAP-beholder og navn
Container - typen objekter som kan består av andre gjenstander... Et domene kan for eksempel inkludere kontoobjekter.
Hovedformålet deres er bestilling av gjenstander etter type skilt. Oftest brukes containere til å gruppere objekter med de samme attributtene.
Nesten alle beholdere viser en samling av objekter, og ressurser vises unikt objekt Active Directory. En av hovedtypene AD-beholdere er en organisasjonsenhet, eller OU (organisasjonsenhet). Objekter som er plassert i denne beholderen tilhører bare domenet de er opprettet i.
Lettvektskatalog Tilgangsprotokoll, LDAP) er den viktigste TCP/IP-tilkoblingsalgoritmen. Den er designet for å redusere mengden nyanser under tilgang til katalogtjenester. LDAP definerer også handlingene som brukes til å spørre og redigere katalogdata.
Tre og sted
Et domenetre er en struktur, en samling domener som deler et felles skjema og konfigurasjon som danner et felles navneområde og er koblet sammen med tillit.
En domeneskog er en samling trær som henger sammen.
Et nettsted er en samling enheter i IP-undernett, som representerer en fysisk modell av et nettverk, hvis planlegging utføres uavhengig av den logiske representasjonen av konstruksjonen. Active Directory har muligheten til å opprette n-te antall nettsteder eller kombinere n-te antall domener under ett nettsted.
Installere og konfigurere Active Directory
La oss nå gå direkte til å konfigurere Active Directory på Windows eksempel Server 2008 (på andre versjoner er prosedyren identisk):
Klikk på "OK"-knappen. Det skal bemerkes at disse verdiene er valgfrie. Du kan bruke IP-adressen og DNS fra nettverket ditt. 
- Deretter må du gå til "Start"-menyen, velg "Administrative verktøy" og "".
- Gå til elementet "Roller", velg feltet " Legg til roller”.
- Velg en " Domenetjenester Active Directory ", klikk" Neste "to ganger, og deretter" Installer ".
- Vent til installasjonen er fullført.
- Åpne Start-menyen - " Henrette". Skriv inn dcpromo.exe i feltet.
- Klikk "Neste".
- Velg en " Skape nytt domene i den nye skogen"Og klikk" Neste "igjen.
- I neste vindu, skriv inn navnet, klikk på "Neste".
- Plukke ut Kompatibilitetsmodus(Windows Server 2008).
- La alt stå som standard i neste vindu.
- Vil starte konfigurasjonsvinduDNS... Siden det ikke ble brukt på serveren før, ble det ikke opprettet noen delegering.
- Velg en katalog for installasjon.
- Etter dette trinnet må du stille inn administrasjonspassord.
For pålitelighet må passordet oppfylle følgende krav:
Etter at AD er ferdig med å konfigurere komponentene, må du starte serveren på nytt.
Konfigurasjonen er fullført, snapin-modulen og rollen er installert på systemet. Du kan kun installere AD på Windows-familier Server, konvensjonelle versjoner slik som 7 eller 10 kan bare tillate at administrasjonskonsollen installeres.
Administrasjon i Active Directory
Som standard på Windows Serverkonsoll Active Directory-brukere og datamaskiner fungerer med domenet som datamaskinen tilhører. Du kan få tilgang til datamaskinen og brukerobjektene i dette domenet gjennom konsolltreet, eller koble til en annen kontroller.
Verktøyene til den samme konsollen lar deg se Ekstra alternativer objekter og søke etter dem, kan du opprette nye brukere, grupper og endre fra tillatelse.
Det er det forresten 2 typer grupper i Active Directory - sikkerhet og distribusjon. Sikkerhetsgrupper er ansvarlige for å differensiere tilgangsrettigheter til objekter, de kan brukes som distribusjonsgrupper.
Distribusjonsgrupper kan ikke skille rettigheter, men brukes hovedsakelig til å sende meldinger på nettverket.
Hva er AD Delegation
Selve delegasjonen er overføring av deler av tillatelser og kontroll fra overordnet objekt til den andre ansvarlige.
Det er kjent at hver organisasjon har flere systemadministratorer ved sitt hovedkvarter. Ulike oppgaver bør være på forskjellige skuldre. For å bruke endringer må du ha rettighetene og tillatelsene, som er delt inn i standard og spesiell. Spesielle - gjelder for et bestemt objekt, og standard er et sett med eksisterende tillatelser som gjør visse funksjoner tilgjengelige eller utilgjengelige.
Etablere et tillitsforhold
Det er to typer i AD tillitsfulle forhold: "Enveis" og "toveis". I det første tilfellet stoler det ene domenet på det andre, men ikke omvendt, henholdsvis, det første har tilgang til ressursene til det andre, og det andre ikke. I den andre typen er tillit "gjensidig". Det er også "outbound" og "inbound" relasjoner. Ved utgående, stoler det første domenet på det andre, og lar dermed brukere av det andre bruke ressursene til det første.
Under installasjonen bør følgende prosedyrer utføres:
- Bekrefte nettverkstilkoblinger mellom kontrollerene.
- Sjekk innstillingene.
- Melodi navneoppløsning for eksterne domener.
- Lag lenke fra siden av det tillitsfulle domenet.
- Opprett en lenke fra siden av kontrolleren som tilliten er adressert til.
- Sjekk det opprettede enveisforholdet.
- Hvis det er et behov i etableringen av bilaterale relasjoner - for å gjøre installasjonen.
Global katalog
Det er en domenekontroller som vedlikeholder kopier av alle objekter i skogen. Det gir brukere og programmer muligheten til å søke etter objekter i et hvilket som helst domene i den gjeldende skogen ved å bruke attributt oppdagere inkludert i den globale katalogen.
Den globale katalogen (GC) inkluderer et begrenset sett med attributter for hvert skogobjekt i hvert domene. Den mottar data fra alle partisjoner av domenekatalogen i skogen, de kopieres ved hjelp av standard prosess Active Directory-replikering.
Skjemaet bestemmer om attributtet skal kopieres. Det er en mulighet konfigurere tilleggsegenskaper som vil bli gjenskapt i den globale katalogen ved hjelp av "Active Directory Schema". For å legge til et attributt til den globale katalogen, velg replikeringsattributtet og bruk alternativet "Kopier". Dette vil opprette en replikering av attributtet til den globale katalogen. Attributtparameterverdi isMemberOfPartialAttributeSet vil bli sann.
Til finne ut plasseringen global katalog, må du skrive inn på kommandolinjen:
Dsquery server –isgc
Replikerer data i Active Directory
Replikering er en kopieringsprosedyre, som utføres når det er nødvendig å lagre den samme oppdaterte informasjonen som finnes på enhver kontrollør.
Den er produsert uten operatørmedvirkning... Det finnes følgende typer replikainnhold:
- Datareplikaer opprettes fra alle eksisterende domener.
- Dataskjemakopier. Siden dataskjemaet er det samme for alle objekter i Active Directory-skogen, blir replikaene bevart på tvers av alle domener.
- Konfigurasjonsdata. Viser oppbygging av kopier blant kontrollere. Informasjonen gjelder alle domener i skogen.
Hovedtypene av replikaer er intrasite og inter-site.
I det første tilfellet, etter endringene, venter systemet og varsler deretter partneren om å opprette en replika for å fullføre endringene. Selv i fravær av endringer, skjer replikeringsprosessen automatisk etter en viss tidsperiode. Etter at brytende katalogendringer er tatt i bruk, skjer replikering umiddelbart.
Replikeringsprosedyre mellom noder skjer i mellom minimal nettverksbelastning, dette unngår tap av informasjon.
Administratorer av Windows-nettverk kan ikke unngå å bli kjent med. Denne oversiktsartikkelen vil fokusere på hva Active Directory er og hva de spises med.
Så, Active Directory er en katalogtjenesteimplementering fra Microsoft... Under katalogtjenesten i i dette tilfellet underforstått Software pakke, hjelpe systemadministratoren å jobbe med slike nettverksressurser som delte mapper, servere, arbeidsstasjoner, skrivere, brukere og grupper.
Active Directory har hierarkisk struktur bestående av gjenstander. Alle eiendommer er delt inn i tre hovedkategorier.
- Bruker- og datamaskinkontoer;
- Ressurser (som skrivere);
- Tjenester (som e-post).
Hvert objekt har unikt navn og har en rekke egenskaper. Objekter kan grupperes.
Brukeregenskaper Active Directory har en skogstruktur. Skogen har flere trær som inneholder domener. Domener inneholder på sin side de nevnte objektene.
Active Directory-struktur Vanligvis er objekter i et domene gruppert i organisasjonsenheter. Underavdelinger brukes til å bygge et hierarki innenfor et domene (organisasjoner, territorielle inndelinger, avdelinger osv.). Dette er spesielt viktig for geografisk spredte organisasjoner. Når du bygger strukturen, anbefales det å opprette så få domener som mulig, om nødvendig opprette separate inndelinger. Det er på dem det er fornuftig å bruke grupperetningslinjer.
Arbeidsstasjonsegenskaper En annen måte å strukturere Active Directory på er nettsteder... Nettsteder er en måte å fysisk gruppere dem sammen, ikke logisk, basert på nettverkssegmenter.
Som nevnt har hvert objekt i Active Directory et unikt navn. For eksempel en skriver HPLaserJet4350dtn som er i underavdeling Advokater og i domenet primer.ru vil ha et navn CN = HPLaserJet4350dtn, OU = Advokater, DC = primer, DC = ru. CN er et vanlig navn, OU- underavdeling, DC- klassen til domeneobjektet. Et objektnavn kan ha mange flere deler enn i dette eksemplet.
En annen form for å skrive navnet på et objekt ser slik ut: primer.ru/Advokater/HPLaserJet4350dtn... 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. Noen objekter har også en UPN ( UPN) i formatet objekt @ domene.
Her generell informasjon om hva Active Directory er og hva de er for i lokale nettverk på Windows basert... Til slutt er det fornuftig å si at administratoren har muligheten til å arbeide med Active Directory eksternt gjennom Administrasjonsverktøy for ekstern server for Windows 7 (KB958830)(nedlasting) og Administrasjonsverktøy for ekstern server for Windows 8.1 (KB2693643) (nedlasting).
I 2002, da jeg gikk ned gangen til informatikkavdelingen på mitt favorittuniversitet, så jeg en fersk plakat på døren til NT Systems-kontoret. Plakaten avbildet ikonene til brukerkontoer, samlet i grupper, hvorfra pilene igjen gikk til andre ikoner. Alt dette ble skjematisk kombinert til en bestemt struktur, det ble skrevet noe om enhetlig system pålogging, autorisasjon og lignende. Så vidt jeg forstår nå, avbildet den plakaten arkitektur Windows-systemer NT 4.0 domener og Windows 2000 Active Directory. Fra det øyeblikket begynte mitt første bekjentskap med Active Directory og sluttet umiddelbart, da det var en vanskelig økt, en morsom ferie, hvoretter en venn delte FreeBSD 4 og Red-diskene Hat Linux, og de neste årene stupte jeg inn i verden av Unix-lignende systemer, men jeg har ikke glemt innholdet på plakaten.
Jeg måtte gå tilbake til systemer basert på Windows Server-plattformen og bli nærmere kjent med dem da jeg flyttet til et selskap hvor styringen av hele IT-infrastrukturen var basert på Active Directory. Jeg husker at sjefsadministratoren for det selskapet på hvert møte fortsatte å gjenta noe om noen Active Directory Best Practices. Nå, etter 8 år med intermitterende kommunikasjon med Active Directory, forstår jeg ganske godt hvordan det fungerer dette systemet og hva er Active Directory Best Practices.
Som du sikkert allerede har gjettet, vil vi snakke om Active Directory.
Alle som er interessert i dette emnet, velkommen til katt.
Disse anbefalingene gjelder for klientsystemer fra Windows 7 og oppover, for domener og skoger Windows-nivå Server 2008 / R2 og nyere.
Standardisering
Du bør begynne å planlegge for Active Directory ved å utvikle standardene dine 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 det pent hyppig anbefaling for IT-fagfolk. Prinsippet «først skriver vi dokumentasjonen, og så bygger vi systemet ved hjelp av 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.
Min anbefaling er å skrive dokumentasjonen først, tenke over det, og først deretter begynne å installere den første domenekontrolleren.
For eksempel vil jeg gi en del av dokumentet om standarder for navngivning av objekter i Active Directory.
Navngivning av objekter.
- Navn tilpassede grupper må starte med GRUS_-prefikset (GR - Group, US - Users)
- Navnet på datamaskingrupper skal ikke starte med GRCP_-prefikset (GR - Gruppe, CP - Datamaskiner)
- Navnet på delegeringen av myndighetsgrupper må begynne med GRDL_-prefikset (GR - Group, DL - Delegation)
- Navnet på ressurstilgangsgrupper må begynne med GRRS_-prefikset (GR - Gruppe, RS - ressurser)
- Gruppenavn for retningslinjer må starte med prefiksene GPUS_, GPCP_ (GP - Gruppepolicy, USA - Brukere, CP - Datamaskiner)
- Navnet på klientdatamaskiner må være to eller tre bokstaver fra organisasjonsnavnet etterfulgt av et tall atskilt med en bindestrek, for eksempel nnt-01.
- Servernavn skal starte med bare to bokstaver, etterfulgt av en bindestrek etterfulgt av serverrollen og servernummeret, for eksempel nn-dc01.
Din tilnærming til å skrive dokumentasjon bør være veldig grundig, dette vil spare mye tid i fremtiden.
Forenkle alt du kan, prøv å oppnå balanse
Når du bygger Active Directory, må du følge prinsippet om å finne en balanse, velge enkle og greie mekanismer.
Prinsippet for balanse er å oppnå den nødvendige funksjonaliteten og sikkerheten samtidig som løsningens enkelhet maksimeres.
Det er nødvendig å prøve å bygge systemet slik at strukturen er forståelig for den mest uerfarne administratoren eller til og med en bruker. 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 denne anbefalingen eksisterte på grunn av prinsippet om «del og hersk», eller fordi Microsoft fortalte alle at domenet er sikkerhetsgrensen og deler organisasjonen inn i domener, vil vi få separate strukturer som er lettere å kontrollere hver for seg. Men som praksis har vist, er det lettere å vedlikeholde og kontrollere enkeltdomenesystemer, der organisasjonsenheter (OU) er sikkerhetsgrensene, og ikke domener. Unngå derfor å lage komplekse flerdomenestrukturer, det er bedre å gruppere objekter etter OU.
Selvfølgelig skal man opptre uten fanatisme - hvis det er umulig å klare seg uten flere domener, så må man lage flere domener, også med skog. 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 av dette objektet, og allerede tilordne til gruppen nødvendige rettigheter... 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. Det skjer nesten alltid at det etter en stund kommer en annen ansatt på jobb som trenger lignende rettigheter, og i stedet for å delegere rettigheter til ulike seksjoner Active Directory, vil det være mulig å ganske enkelt legge det til den nødvendige gruppen, for hvilken en rolle allerede er definert i systemet og de nødvendige myndighetene er delegert.
Et eksempel til. Du må delegere rettighetene til OU med brukere til systemadministratorgruppen. Ikke deleger rettigheter direkte til administratorgruppen, men opprett spesiell gruppe som GRDL_OUName_Operator_Accounts som du tildeler rettigheter til. Så er det bare å legge til gruppen med ansvarlige administratorer i gruppen GRDL_OUName_Operator_Accounts. Det vil definitivt vise seg at du i nær fremtid må delegere rettighetene til denne OUen til en annen gruppe administratorer. Og i så fall legger du bare til administratordatagruppen til delegeringsgruppen GRDL_OUName_Operator_Accounts.
Jeg foreslår følgende gruppestruktur.
- Brukergrupper (GRUS_)
- Administratorgrupper (GRAD_)
- Delegasjonsgrupper (GRDL_)
- Policygrupper (GRGP_)
- Servergrupper (GRSR_)
- Klientdatamaskingrupper (GRCP_)
- Få tilgang til grupper delte ressurser(GRRS_)
- Skrivertilgangsgrupper (GRPR_)
Følg prinsippet om balanse, begrens antall roller for grupper og husk at navnet på gruppen ideelt sett fullt ut skal beskrive dens rolle.
OU arkitektur.
Arkitekturen til OU bør først og fremst tenkes ut fra et synspunkt om sikkerhet og delegering av rettigheter til denne OU. systemadministratorer... Jeg anbefaler ikke å planlegge arkitekturen til OU-er når det gjelder å binde gruppepolicyer til dem (selv om dette oftest gjøres). For noen kan anbefalingen min virke litt merkelig, men jeg anbefaler ikke å binde gruppepolicyer til OU i det hele tatt. Les mer i avsnittet Gruppepolicyer.
OU-administratorer
Jeg anbefaler at du tildeler en egen OU for administrative kontoer og grupper, hvor du kan plassere kontoene og gruppene til alle administratorer og tekniske støtteingeniører. Tilgang til denne OU bør begrenses for vanlige brukere, og deleger administrasjonen av objekter fra denne OU bare til hovedadministratorene.
OU datamaskiner
OUer for datamaskiner planlegges best med tanke på den geografiske plasseringen til datamaskinene og typene datamaskiner. 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 oppgis Spesiell oppmerksomhet... Som nevnt i avsnittet om OUer bør brukerkontoer grupperes ut fra prinsippet om å delegere 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). Obligatoriske felter er: Fornavn, Initialer, Etternavn, Vist navn (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 initialene til eieren og prefikset lokal (for eksempel iivlocal)
- Med rettigheter til å administrere servere og Active Directory. Må bare inneholde initialer (for eksempel iiv).
La meg forklare hvorfor du bør skille administrative kontoer inn i serveradministratorer og klientdatamaskinadministratorer. Dette må gjøres av sikkerhetsmessige årsaker. Administratorer av klientdatamaskiner vil ha rett til å installere programvare på klientdatamaskiner... Hva og for hvilken programvare som skal installeres, kan du aldri si sikkert. Derfor er det utrygt å kjøre installasjonen av applikasjonen med domeneadministratorrettigheter; hele domenet kan bli kompromittert. Du må bare administrere klientdatamaskiner med lokale administratorrettigheter for den datamaskinen. Dette vil gjøre det umulig for en rekke angrep på domeneadministratorkontoer, for eksempel "Pass The Hash". I tillegg må klientdatamaskinadministratorer lukke Terminal Services-tilkoblingen og nettverkstilkoblingen til datamaskinen. Støtte- og administratordatamaskinene bør plasseres på et eget VLAN for å begrense tilgangen til dem fra klientdatamaskinens nettverk.
Tildeling av administratorrettigheter til brukere
Hvis du trenger å gi administratorrettigheter til en bruker, må du ikke i noe tilfelle sette hans konto for det daglige arbeidet i en gruppe. lokale administratorer datamaskin. 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 en policy som begrenser applikasjonen kun til brukerens datamaskin ved å bruke målretting på elementnivå. Brukeren vil kunne bruke denne kontoen ved å bruke Kjør AS-mekanismen.
Passordpolicyer
Skape individuelle politikere passord for brukere og administratorer ved hjelp av en finmasket passordpolicy. Det er ønskelig at bruker passord besto av minst 8 tegn og endres minst en gang i kvartalet. Det er tilrådelig for administratorer å endre passordet annenhver måned, og det må være minst 10-15 tegn langt og oppfylle kompleksitetskravene.
Sammensetningen av domene og lokale grupper. Begrensede grupper-mekanisme
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 å ha blitt revet Aktivt domene Katalog, administratorer legger seg til domenegrupper som domeneadministratorer legger bedriftsadministratorer til nødvendige grupper teknisk støtteingeniører og andre brukere er også tildelt 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 forverres dersom selskapet ansetter flere administratorer og hver fra tid til annen utsteder 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 gruppene kun kontrolleres av gruppepolicyer, som vil sette alt i orden med hver applikasjon.
Sammensetning av innebygde grupper
Det er verdt å si at innebygde grupper som kontooperatører, sikkerhetskopieringsoperatører, krypteringsoperatører, gjester, utskriftsoperatører, serveroperatører bør være tomme, både i domenet og på klientdatamaskiner. Disse gruppene er først og fremst nødvendige for å sikre bakoverkompatibilitet med gamle systemer, og brukere av disse gruppene gis for mange rettigheter i systemet, og privilegieeskaleringsangrep blir mulig.
Lokale administratorkontoer
Ved å bruke mekanismen for begrensede grupper er det nødvendig å blokkere Kontoer lokale administratorer på lokale datamaskiner, blokker gjestekontoer og tøm den lokale administratorgruppen på lokale datamaskiner. Bruk aldri gruppepolicy til å angi passord for lokale administratorkontoer. Denne mekanismen er ikke sikker, passordet kan trekkes ut direkte fra policyen. Men hvis du bestemmer deg for ikke å blokkere kontoene til lokale administratorer, så for riktig installasjon passord og deres rotasjon bruker LAPS-mekanismen. Dessverre er ikke LAPS-konfigurasjonen helautomatisert, og derfor vil det være nødvendig å manuell innstilling legge til attributter til Active Directory-skjemaet, gi rettigheter til dem, tilordne grupper og så videre. Derfor er det lettere å blokkere kontoene til lokale administratorer.
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.
Bruk policy - gruppe-prinsippet når du oppretter en policy. 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 OU, men til domeneroten og juster 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 policyer til OUer. (Dette 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. Med disse innstillingene vil retningslinjer bli brukt raskere.
Sett opp din daglige backup politiker kl Strømhjelp Shell, slik at du i tilfelle konfigurasjonsfeil alltid kan returnere innstillingene til de opprinnelige.
Sentrallager for maler (Central Store)
Fra og med Windows 2008 ble det mulig å lagre ADMX-maler for gruppepolicyer i en sentral butikk, i SYSVOL. Inntil da, som standard, ble alle policymaler lagret lokalt på klienter. For å plassere ADMX-maler i sentrallageret, må du kopiere innholdet i % SystemDrive% \ Windows \ PolicyDefinitions-mappen sammen med undermapper fra klientsystemer (Windows 7/8 / 8.1) til domenekontrollerkatalogen% SystemDrive% \ Windows \ SYSVOL \ domene \ Policyer \ PolicyDefinitions med innhold flettes, men ingen erstatning. Det neste trinnet er å gjøre den samme kopieringen fra serversystemene, og starter med den eldste. Sist men ikke minst, når du kopierer mapper og filer fra siste versjon server, gjør en sammenslåing og ERSTATT kopi.
Kopiere ADMX-maler
I tillegg, i det sentrale depotet, kan du plassere ADMX-maler for alle programvareprodukter, for eksempel som Microsoft Office, Adobe-produkter, Google og andre. Gå til programvareleverandørens nettsted, last ned Group Policy ADMX-malen og pakk den ut til mappen % SystemDrive% \ Windows \ SYSVOL \ domene \ Policies \ PolicyDefinitions-mappen på en av domenekontrollerne. Nå kan du administrere det du vil programvareprodukt gjennom gruppepolicyer.
WMI-filtre
WMI-filtre er ikke veldig raske, så målretting på varenivå foretrekkes. Men hvis målretting på varenivå ikke kan brukes, og du bestemte deg for å bruke WMI, anbefaler jeg at du umiddelbart oppretter flere av de vanligste filtrene for deg selv: OS"," Kun serveroperativsystemer "," Windows 7 "filtre," Windows 8 "," Windows 8.1 "," Windows 10 "filtre. Hvis du har ferdiglagde sett med WMI-filtre, vil det være lettere å bruke det nødvendige filteret på den nødvendige policyen.
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
- Revidere Brukerkonto Ledelse - suksess, fiasko
- Overvåke Kerberos-autentiseringstjenesten – feil
- Revidere andre kontopåloggingshendelser - feil
- Endring av revisjonsrevisjonspolicy – suksess, fiasko
Avanserte revisjonsinnstillinger
Jeg vil ikke dvele på revisjonsinnstillingene i detalj, siden det er et tilstrekkelig antall artikler på Internett om 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 å tildele separate servere for innsamling og analyse av loggfiler.
Administrasjons- og renseskript
Alle lignende og ofte gjentatte handlinger må utføres ved hjelp av administrasjonsskript. Disse handlingene inkluderer å opprette brukerkontoer, opprette administratorkontoer, opprette grupper, opprette en OU og så videre. Skriptobjekter lar deg følge Active Directory-objektnavnelogikken ved å bygge inn syntakskontroller rett i skriptene.
Det er også verdt å skrive renseskript som automatisk kontrollerer sammensetningen av grupper, identifiserer brukere og datamaskiner som ikke har vært koblet til domenet på lenge, oppdager brudd på dine andre standarder, og så videre.
Jeg har ikke sett bruken av administrative skript for å håndheve standarder og utføre bakgrunnsoperasjoner som en eksplisitt offisiell anbefaling. Men selv foretrekker jeg kontroller og prosedyrer i automatisk modus ved bruk av skript, siden dette sparer mye tid og eliminerer et stort antall feil og selvfølgelig min litt unix-tilnærming til administrasjon påvirker her, når det er lettere å skrive et par kommandoer enn å klikke på vinduene.
Manuell administrasjon
Du og kollegene dine må gjøre noen av administrasjonsoperasjonene manuelt. For disse formålene anbefaler jeg å bruke mmc-konsollen med snapin-modulene lagt til.
Som det vil bli diskutert senere, må domenekontrollerne fungere i Server Core-modus, det vil si at hele AD-miljøet kun skal administreres fra datamaskinen din ved å bruke konsoller. For å administrere Active Directory, må du installere administrasjonsverktøy for ekstern server på datamaskinen. Konsoller bør startes på datamaskinen din som en bruker med Active Directory-administratorrettigheter, til hvem kontroll er delegert.
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 alle domene må det være minst to kontrollere. Domenekontrollere bør ha så få tjenester som mulig. Ikke lag en filserver av en domenekontroller eller, gud forby, heve rollen som en terminalserver på den. Bruk Server Core-operativsystemer på domenekontrollere, fjern all WoW64-støtte, dette vil redusere antallet nødvendige oppdateringer og vil øke deres sikkerhet.
Microsoft har tidligere frarådet virtualisering av domenekontrollere på grunn av potensialet for uløselige replikeringskonflikter ved gjenoppretting fra øyeblikksbilder. Kanskje det var andre grunner, jeg kan ikke si sikkert. Nå har hypervisorer lært hvordan de kan fortelle kontrollerne om å gjenopprette dem fra øyeblikksbilder, og dette problemet har forsvunnet. Jeg har virtualisert kontrollere hele tiden uten å ta noen øyeblikksbilder, fordi jeg ikke forstår hvorfor du kanskje trenger å gjøre en på domenekontrollere. Etter min mening er det lettere å sikkerhetskopiere domenekontrolleren med standard midler... Derfor anbefaler jeg å virtualisere så mange domenekontrollere som mulig. Denne konfigurasjonen vil være mer fleksibel. Når du virtualiserer domenekontrollere, plasser dem på separate fysiske verter.
Hvis du trenger å være vert for en domenekontroller i et usikret fysisk miljø eller i et avdelingskontor til organisasjonen din, bruk en RODC til dette formålet.
FSMO-roller, primære og sekundære kontrollere
FSMO-rollene til domenekontrollere fortsetter å skape frykt i hodet til nybegynnere administratorer. Nybegynnere studerer ofte Active Directory fra 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 eieren lagrer all informasjon om arbeidet knyttet til en bestemt rolle direkte i Active Directory. Og hvis vi overfører rollen til en annen kontroller, ber han først og fremst om den lagrede informasjonen i Active Directory og begynner å utføre tjenesten. Et domene kan eksistere uten rollemestere i ganske lang tid. 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), som kan bæres av alle kontrollere i domenet. Jeg anbefaler å tildele en GC-rolle til hver domenekontroller i domenet, jo flere jo bedre. Selvfølgelig kan du finne tilfeller der det kanskje ikke er verdt å installere GC-rollen på en domenekontroller. Vel, hvis du ikke trenger det, trenger du det ikke. Følg anbefalingene uten fanatisme.
DNS-tjeneste
DNS er avgjørende for driften av Active Directory og bør fungere uten avbrudd. Service DNS er bedre bare sett på hver domenekontroller og lagre DNS-soner i selve Active Directory. Hvis du skal bruke Active Directory til å lagre DNS-soner, bør du konfigurere TCP/IP-tilkoblingsegenskapene på domenekontrollere slik at hver kontroller har primær DNS-server det var en annen DNS-server, og du kan sette adressen 127.0.0.1 som en sekundær. Denne innstillingen er nødvendig fordi en fungerende DNS kreves for normal start av Active Directory-tjenesten, og for å starte DNS må Active Directory-tjenesten kjøres, siden selve DNS-sonen ligger i den.
Sørg for å sette opp omvendt oppslagssoner for alle nettverkene dine og slå på automatisk sikker oppdatering PTR poster.
Jeg anbefaler i tillegg å aktivere automatisk rengjøring av sonen fra foreldet DNS-poster(dns rensing).
Jeg anbefaler å spesifisere sikre Yandex-servere som DNS-videresendinger, hvis det ikke er andre raskere på din geografiske plassering.
Nettsteder og replikering
Mange administratorer er vant til å tro at nettsteder er en geografisk samling av datamaskiner. For eksempel nettstedet Moskva, nettstedet Petersburg. Dette synet kommer fra det faktum at den opprinnelige inndelingen av Active Directory i nettsteder ble gjort for å balansere og separere nettverksreplikeringstrafikk. 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 etter en tidsplan. Eller, generelt, 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 sammenkoblet med en tilkobling med lav båndbredde, noe som er svært sjeldent i vår tid. Derfor deler jeg Active Directory inn i nettsteder, ikke for å balansere replikeringstrafikk, men for å balansere nettverksbelastning generelt og for mer rask behandling klientforespørsler fra nettstedets datamaskiner. La meg forklare med et eksempel. Det er en organisasjons 100-megabit LAN, som betjenes av to domenekontrollere, og det er en sky hvor organisasjonens applikasjonsservere 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 finner en kanal til Internett mindre enn 10 megabit per sekund, så vil jeg aktivere Notify Based Replication, dette er når datareplikering skjer 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 en 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 deling fysiske og intellektuelle ressurser. Det er derfor jeg deler denne artikkelen med deg, og jeg håper at mine anbefalinger vil hjelpe deg med å forbedre systemene dine, og at du vil bruke betydelig 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 i kommentarene deler din kunnskap og praksis for å bygge Active Directory hvis mulig.
Fred og vennlighet til alle!
Du kan hjelpe og overføre noen midler til utviklingen av nettstedet
