Poenget med Group Policy er at det er bare så god som din Active Directory design. Hvis du har implementert dine nettsteder, domener og organisasjonsenheter i feil vei, vil Group Policy være vanskelig å bruke og feilsøke. Så det første trinnet i å planlegge hvordan du skal gjennomføre Group Policy på nettverket er å planlegge hvordan du skal implementere Active Directory selv. Slik planlegging inkluderer beslutninger som: Hvor mange skoger du vil distribuere (én eller flere)? Hvor mange domene trær? Vil det være underdomener? Hva slags OU strukturen vil hvert domene har? Og så videre. Hver av disse beslutningene bør alltid gjøres ved å stille spørsmålet: Hvilke konsekvenser vil min beslutning ha på hvordan gruppepolicy er implementert i min virksomhet? La oss se på noen retningslinjer som kan hjelpe deg med å utforme Active Directory effektivt så langt Group Policy er bekymret.
KISS
Den første og åpenbare prinsippet er å "! Keep It Simple, Stupid" eller "KISS" I sammenheng med Group Policy planlegging, betyr dette to ting:
Så la oss si at du begynner på Active Directory utforming ved å bestemme at du kommer til oss ett domene (se figur 1) med to eller kanskje tre nivåer av organisasjonsenheter innenfor det. Det er et godt sted å begynne. Hva blir det neste
Figur 1: Har bare ett domene hvis mulig
Server organisasjonsenheter
Group Policy er ikke bare for å administrere stasjonære; det er også veldig bra for å låse ned servere for å sikre at de er sikre og fungerer. Og ved å servere mener jeg både medlemsservere (som inkluderer filservere, utskriftsservere, webservere, DHCP-servere, og så videre) og domenekontrollere. Den beste måten å låse ned domenekontrollere, er å la dem i standard Domain Controllers OU og konfigurere en GPO knyttet til at OU. Det er to måter du kan gjøre dette:
Konfigurer innstillingene i standard Domain Controllers Policy.
Hvilke tilnærming er bedre? Noen eksperter anbefaler å la standard GPO urørt og skape et nytt GPO og flytte den til toppen av koblingen For GPOer knyttet til OU. På den måten hvis noe går galt senere du minst ha standard GPO på plass og urørt. På den annen side, hvis du kjører den nye sikkerhetskonfigurasjon Wizard (SCW) av Windows Server 2003 Service Pack 1 på en domenekontroller, så i tillegg til andre endringer det vil endre visse innstillinger i Standard Domain Controllers Policy til å lage din domenekontroller sikrere. Så enten tilnærming fungerer fint, men personlig foretrekker jeg den andre tilnærmingen.
Hva om dine medlemsservere? Trikset her er å innse at de ulike medlem server roller er i utgangspunktet trinnvis forskjellig fra baseline (som ikke har noen rolle) medlem server. Så en god tilnærming er å skape et toppnivå medlemsservere OU og deretter under det legge ytterligere organisasjonsenheter for hver rolle (figur 2):
Figur 2: OU struktur for medlemsservere.
Fordelen med denne tilnærmingen er at du nå kan lage en baseline Medlems Servere GPO som generelt sikrer et medlem server og koble det til medlems Servere OU. På den måten alle medlems servere barnet organisasjonsenheter vil automatisk arve denne politikken. Da kan du lage en utskriftsservere GPO og koble det til utskriftsservere OU, en filservere GPO og koble det til filservere OU, og så videre. Disse ulike GPOer knyttet til barnet organisasjonsenheter i medlems Server OU kan brukes til trinnvis herde sikkerhet for hver server rolle over grunnleggende herding gitt av medlemsservere GPO.
Her er et tips:
hvis du ønsker å finne ut mer om bruk av ovennevnte tilnærming til å herde servere ved hjelp av Group Policy, lese Windows Server 2003 Security Guide som er tilgjengelig fra Microsoft Download Center . Denne guiden har veldig bra forslag om hvordan du kan sikre forskjellige serverroller og det er vel verdt å pløye gjennom sine nesten 300 sider med innhold. Hvis du ikke har tid til å lese hele guide, sjekk ut bloggen min ITreader.net og klikk Group Policy etter emner, og du vil finne mye nyttig informasjon som jeg har hentet fra min egen lesning av Guide samt andre ressurser for Microsoft.
Desktop og brukerorganisasjonsenheter
OU strukturen du planlegge for domenet kan stole på ulike ting, inkludert bedriftens organisasjonskartet, avdelingskontorer, antall avdelinger, og så videre. Det er ingen hard og rask eneste beste måten å utforme organisasjonsenheter for et domene, men følgende tips kan hjelpe deg å unngå problemer senere når du begynner å lage GPOer å låse ned brukere og deres stasjonære datamaskiner.
First off, bør du bare opprette en OU hvis det er noen overbevisende grunn til det å eksistere. For eksempel, hvis brukere i salg, markedsføring og Reference avdelinger alle har lignende behov så langt som sikkerhet går, gruppe sine kontoer i en enkelt OU stedet for tre. Så hvis salget brukerne har noen mindre forskjell i sikkerhetskrav fra de to andre avdelingene, kan du opprette og knytte en annen GPO til OU og bruke sikkerhetsfiltrering for å sikre at bare medlemmer av Sales gruppen har som GPO innstillingen brukes på dem.
Neste, bør du prøve å lage din organisasjonsenheter sammen avdelingslinjer fremfor geografisk plassering. På den måten kan du gjøre mer effektiv bruk av delegasjon når du trenger å bruke den. Hvis du må ha geografisk organisasjonsenheter, gjøre dem toppnivå organisasjonsenheter og deretter lage barn organisasjonsenheter under dem for hver divisjon eller avdeling (figur 3):
Figur 3: En typisk OU struktur.
Deretter oppretter eget organisasjonsenheter for datamaskinkontoer og brukerkontoer (figur 4). På den måten kan du bruke egen organisasjonsenheter til å låse ned maskininnstillinger og brukerinnstillinger. Selvfølgelig kan du oppnå det samme ved å lumping sammen datamaskin og brukerkontoer til en enkelt OU, knytte to GPOer til at OU, og deaktivere maskininnstillingene i ett OU og brukerinnstillingene i den andre OU. Men å holde datamaskinen og brukerkontoer i separate organisasjonsenheter vil gjøre det lettere for deg å feilsøke når gruppepolicy ikke gjør det du forventet, og det gjør feil i å konfigurere politikken mindre sannsynlig også.
Figur 4: Bruk egen organisasjonsenheter for datamaskiner og brukerkontoer.
også, prøver å unngå å bruke Blokkering, Tvunget, Loopback, og andre måter å endre standard Group Policy arv rekkefølge. Det er fordi du bruker disse funksjonene kan gjøre det veldig vanskelig å feilsøke hvorfor gruppepolicy ikke gjør hva du har tenkt at den skal gjøre. Hvis du finner du absolutt må bruke disse funksjonene i Group Policy design, har du sannsynligvis ikke har utviklet Active Directory struktur svært godt. Det eneste unntaket fra denne regelen er sikkerhetsfiltrering, som er et kraftig verktøy som kan bidra til å gjøre GPO målretting mer nøyaktig uten kompliserende design. Jeg skal dekke sikkerhetsfiltrering i en fremtidig artikkel om WindowsNetworking.com.
Til slutt, unngå å gjøre endringer i Standard domenepolicy. I stedet oppretter en ny GPO, koble den til domenet, og konfigurere innstillingene etter behov. Men vær veldig forsiktig med hva du konfigurerer i noen GPO knyttet til et domene fordi noen du utfører vil arves av alle PC og brukerkontoer i alle organisasjonsenheter i domenet. Så moralen er, når det er mulig konfigurere politikk ved OU-nivå og ikke på domenenivå, og bruk domene GPOer bare for å konfigurere kontoen policy for domenet.