En av de tingene som jeg alltid har likt om Windows Server 2003 er hvor fleksibel den er i forhold til sikkerhet. Windows Server 2003 er fleksibel nok til å imøtekomme selv de mest bisarre bedriftens sikkerhetspolitikk. Dessverre skjønt, er biprodukt av en slik fleksibilitet kompleksitet. Windows Server 2003 har så mange forskjellige lag med sikkerhet at det kan være vanskelig å forutsi utfallet av politiske endringer, eller for å spore opp uønskede sikkerhetspolitiske innstillinger.

Fordi sikkerhetspolitikk har tradisjonelt vært så vanskelig å håndtere i Windows Server-miljøer, Microsoft har inkludert et verktøy med Windows Server 2003 som er designet for å gjøre sikkerhetspolitikk administrasjon mye enklere. Dette verktøyet kalles resulterende policysett konsoll (RSoP). I denne artikkelen vil jeg introdusere deg til dette verktøyet og forklare hvordan du kan bruke den til å lage sikkerhetspolitikk administrasjon mye enklere.

Hvorfor er det så vanskelig å håndtere sikkerhetspolitikk?

Før du kan virkelig sette pris RSoP, må du forstå hva som gjør sikkerhetspolicyer så vanskelig å håndtere. Problemet stammer fra den hierarkiske natur gruppen politikk. Som du sikkert allerede vet, kollektive avtaler er samlinger av enkelte politiske elementer kjent som gruppepolicyinnstillinger.

Normalt, hvis du ønsket å gjøre en endring i bedriftens sikkerhetspolitikk, ville du åpner den aktuelle gruppen politikk, spore opp gruppen policyinnstillingen som styrer ønsket aspekt av sikkerhet, og deretter lage og lagre endringene .

Hva gjør denne tilsynelatende enkle prosessen så komplisert, er at flere av kollektive avtaler kan gjelde for en enkelt bruker. Ofte vil disse retningslinjene inneholder motstridende gruppepolicyinnstillinger. Når slike motsetninger oppstår, må du være i stand til å finne ut hvilken gruppe policyinnstillingen er dominerende og hvilke innstillinger er over skrevet.

Så hvordan kan du finne ut hvilken gruppe policy innstillinger er dominerende? Du må forstå hierarkiet group policy. Gruppe politikk kan eksistere på den lokale datamaskinen, site, domene og organisasjonsenhetsnivå. Windows behandler gruppen politikk i den rekkefølgen for å oppnå effektiv politikk. Elementer fra hver policy flettes sammen. For eksempel, hvis en lokal politikk inneholdt en innstilling som sier at passord må være åtte tegn, og en områdenivå politikk indikerte at passord må endres hver 30. dag, så effektiv politikk skulle tilsi at passord må være åtte tegn, og må være skiftes hver 30. dag.

Ting fungerer litt annerledes når motsetninger oppstår skjønt. Når motsetninger oppstår, overstyrer høyere nivå politikk lavere nivå policy for motstridende policyinnstillingen. Eventuelle policyinnstillinger som ikke er motstrid flettes sammen på vanlig måte. For eksempel, hvis den lokale sikkerhetspolitikk indikerte at passord må være åtte tegn, og må endres hver 30. dag, og områdenivå politikk indikerte at passord må være 10 tegn langt, så effektiv politikk vil være at passord må være 10 tegn lang og må byttes hver 30. dag. Den effektive politikken holder 30 dagers regelen fordi de to politikk er flettet sammen. Men overstyrer regel ti karakter regelen åtte karakter fordi politikken krever ti karakter passord finnes på et høyere nivå i hierarkiet gruppepolicy (områdenivå) enn den politikken som krever åtte tegn.

Selv om dette er en grunnleggende beskrivelse av hvordan effektiv politikk er beregnet, er det faktisk litt mer komplisert enn som så. Windows lar gruppen politikk som skal gjelde for brukere og til datamaskiner. Derfor er det mulig at du kan ha både en brukerpolicy og en datamaskin politikk på hvert nivå av hierarkiet group policy. Bruker og datamaskin politikk er flettet sammen på hvert nivå i hierarkiet før høyere nivå politikk blir behandlet.

Så hvis høyere nivå politikk er alltid dominerende så du kan lure på hvorfor du ikke bare bør bruke høye nivå politikk eksklusivt og unngå all forvirring. Vel, det er et par grunner til dette. Den første grunnen til ikke å bruke høynivå politikk utelukkende er at de gjelder bredt. For eksempel, hvis du skulle sette passord lengde policy på OU nivå, så ville du mister muligheten til å ha forskjellige minimum passord lengder satt for ulike domener.

En viktig grunn til ikke å bruke høye nivå politikk utelukkende er at når en bruker ikke er logget inn i et domene, da den lokale datamaskinen politikken er din primære sikkerhetsmekanisme. Hvis du ikke tilordner en lokal sikkerhetspolicy til hver arbeidsstasjon, så er det mulig for brukeren å betjene maskinen på en svært usikker måte. Sure, vil høyere nivå politikk sparke inn så snart brukeren logger seg på domenet, men du trenger en politikk som vil beskytte maskinen før logge inn.

Ser den resulterende policysett

Forhåpentligvis, etter å ha lest forrige avsnitt, forstår du hvor komplisert gruppen politikk kan være. Jeg håper også at du forstår hvordan denne kompleksiteten kan gjøre det svært vanskelig å bestemme effektiv politikk for en bruker. Som jeg nevnte tidligere i artikkelen skjønt, kan det RSoP verktøyet gjør livet mye enklere ved å automatisere prosessen med å beregne effektiv politikk.

Den RSoP konsollen kun skip med Windows Server 2003. Dette betyr ikke at du er begrenset til å bruke det i domener som kjører Windows Server 2003 utelukkende skjønt. Du kan bruke RSoP verktøyet på domener som kjører en blanding av Windows 2000 og Windows 2003 servere.

Den enkleste måten å bruke RSoP verktøyet er å åpne Active Directory Users and Computers konsoll og naviger til Brukere container. Deretter høyreklikker du på brukeren som har konto du ønsker å analysere og velg deretter Alle oppgaver | Resulterende policysett (Logging) kommandoer fra de resulterende hurtigmenyer.

Som jeg nevnte tidligere, den effektive politikken er bare delvis basert på de retningslinjer som er tilordnet til en bruker. Datamaskinen nivå politikk også gå inn å bestemme effektiv politikk. Derfor, den første skjermen som du vil se spør du hvilken datamaskin du vil bruke ved fastsettelse av effektiv politikk. Du kan velge å bruke datamaskinen som du bruker, en annen datamaskin, eller du kan velge å ignorere datamaskinen delen av politikken alle sammen. Figur A viser hva denne skjermen ser ut

Figur A:. Du må i utgangspunktet velge hvilken datamaskin du ønsker at politikken beregnet for

Klikk på Neste og du vil se en rask oppsummering av brukeren og innstillingene du har valgt. Klikk på Neste en gang til og RSoP verktøyet vil samle nødvendig informasjon og vise resulterende policysett konsollen, som vist i figur B.

Figur B: Den resulterende policysett konsollen viser brukerens effektiv politikk

Som du kan se i figuren, den resulterende policysett konsollen ser ut akkurat som den Group Policy Editor. Forskjellen er imidlertid at sikkerhetsinnstillingene som du viser gjennom denne konsollen reflektere den brukervalgte effektive politikk.

Nå som jeg har vist deg hvordan du kan vise en brukers effektiv politikk, lurer du kanskje på hva du kan gjøre hvis effektiv politikk ikke reflekterer de innstillingene som du forventer. For eksempel i figur B, vil du legge merke til at brukeren Bob er konfigurert til å få sin konto låst ute etter 5 dårlige påloggingsforsøk. Hva om jeg hadde ventet det å si tre dårlige påloggingsforsøk skjønt?

I en slik situasjon, ville jeg selvsagt trenger å vite hvor det uventede innstillingen kom fra. For å finne ut, bare høyreklikk på innstillingen og velg Egenskaper kommando fra den resulterende hurtigmenyen. Når du gjør det, vil du se et eiendommer ark som viser sikkerhetsinnstillingen i større detalj. Denne egenskaper ark vil ikke la deg endre innstillingen, men hvis du velger kategorien presedens, kan du finne ut hvilken gruppe policy objekt inneholder uakseptable innstillingen. For eksempel i figur C, kan du se at policyinnstillingen kommer fra Standard domenepolicy

Figur C:. Forrang kategorien viser hvor politikken innstillingen fra

Regler Planlegging

Tidligere, når du høyre klikket på brukerkontoen og valgte Alle oppgaver kommandoen fra hurtigmenyen, du kanskje har lagt merke til et alternativ som heter resulterende policysett (planlegging). Jeg ønsker ikke å kjede deg med detaljer om du bruker dette alternativet fordi det fungerer på samme måte som den resulterende policysett (Logging) alternativ som jeg allerede har vist deg. Jeg hadde i det minste vil du være klar over at dette alternativet finnes skjønt. Policy Planning alternativet kan du se effekten av endringer i sikkerheten før du gjør dem. For eksempel, hvis du hadde planer om å flytte brukeren til en annen plassering på nettverket, farten kan potensielt føre til drastiske endringer i brukerens effektiv politikk. Dette verktøyet lar deg se konsekvensene av en slik operasjon uten egentlig å måtte utføre operasjonen.

Konklusjon

I denne artikkelen, jeg har forklart at den hierarkiske natur gruppepolicyobjekter tendens til å gjøre avgjøre en brukers effektiv politikk forvirrende. Jeg fortsatte med å demonstrere hvordan man bruker den RSoP verktøy for å bestemme effektiv politikk og for å spore opp uventede gruppepolicyinnstillinger hvis det er nødvendig. Anmeldelser