Hjelp til policies

[Kenny Bones]

hva slags domain mener du? Skal passord-policyes settes i default domain policy?

Eller selvfølgelig om jeg har flere OUer der policyene skal være forskjellig, må jeg jo linke policyen til korrekt OU.

 

Hva betyr "enforced" uansett da? Er det ikke så enkelt som at "ingen unntak" eller om jeg linker en policy til en gruppe og setter enforced så betyr det at policyen blir låst?

Da kan jeg forstå at det er en løsning som man kun bør bruke om det er absolutt nødvendig. Eller om man har rot i AD og brukerne sine.

 

Så kort sagt, om jeg lager en gruppe og melder inn en del brukere i det og deretter linker en group policy til den gruppen, vil group policyen kun gjelde for den gruppen?

Er ikke dette også noe som kan settes oversiktelig og greit i group policy manager?

[Kenny Bones]

Oops! Dobbelpost!

Endret 16. juni 2005 av raziel014

[roac]

hva slags domain mener du? Skal passord-policyes settes i default domain policy?

Eller selvfølgelig om jeg har flere OUer der policyene skal være forskjellig, må jeg jo linke policyen til korrekt OU.

 

Hva betyr "enforced" uansett da? Er det ikke så enkelt som at "ingen unntak" eller om jeg linker en policy til en gruppe og setter enforced så betyr det at policyen blir låst?

Da kan jeg forstå at det er en løsning som man kun bør bruke om det er absolutt nødvendig. Eller om man har rot i AD og brukerne sine.

 

Så kort sagt, om jeg lager en gruppe og melder inn en del brukere i det og deretter linker en group policy til den gruppen, vil group policyen kun gjelde for den gruppen?

Er ikke dette også noe som kan settes oversiktelig og greit i group policy manager?

Ja, password-policies MÅ settes på domene-nivå for domenebrukere, altså i en GPO som er linket mot det aktuelle domenet. Det kan ikke settes forskjellig passord-policy for domenekontoer som befinner seg i forskjellige domener. Den eneste måten å få forskjellige passordpolicies på domenebrukere er å opprette flere domener i skogen. Slik er løsnignen designet, og det er ingen ting du kan gjøre med det. Som sagt, dersom du setter passord-policy på et OU, vil den kun gjelde for lokale brukere på de PCene som har maskinkonto i det aktuelle OUet, eller et underliggende.

 

Enforced (No override) betyr gjennomtvunget, altså at policyen gjelder selv om det er satt satt en motstridende innstillig nærmere brukeren (i ou-strukturen). Normalt sett er det den policyen som er nærmest brukeren (altså lengst ut i treet) som gjelder, men dersom det er satt flere policies som er enforced, vil den som er nærmest rot (domenet) gjelde.

 

Grunenn til at enforced ikke bør brukes såfremt det ikke er strengt nødvendig, er at det er mindre oversiktlig. Man kan gå inn på det aktuelle OU og det ser ut som policiene der er satt riktig, men resultatet blir noe annet, fordi innstillinger fra et overliggende OU overstyrer innstillingene fra GPOen på OUet som brukeren ligger i.

 

Det er forøvrig ikke mulig å linke GPOer til grupper, og dersom du linker en GPO til et OU som inneholder en gruppe, har dette heller ikke noen effekt. Kontoen til den/de aktuelle brukeren(e) og/eller PCen(e) må ligge i OUet, eller et underliggende.

 

Et par nyttige linker følger:

How does the Group Policy 'No Override' and 'Block Inheritance' work?

Windows 2000 Group Policies

Profiles and Group Policy Primer

 

Edit: Referanser:

 

2279 - Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure

2282 - Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure

Endret 16. juni 2005 av roac

[MasterBlaster]

Bra svart roac, men du tar feil på et punkt.

 

Det er forøvrig ikke mulig å linke GPOer til grupper, og dersom du linker en GPO til et OU som inneholder en gruppe, har dette heller ikke noen effekt. Kontoen til den/de aktuelle brukeren(e) og/eller PCen(e) må ligge i OUet, eller et underliggende.

 

Det er mulig i Windows 2003 å sette GPOer direkte på en security gruppe. Default blir alle GPOer automatisk tilegnet gruppen "authenticated users". Dette kan du sjekke og teste selv ved bruk av det hendige verktøyet GPMC. Start dette verktøyet, klikk på en policy du finner i ett av dine domains - sjekk under fanen "scope" og nederst (På høyre side) under overskriften Security filtering. Her kan du velge hvilken security gruppe du vil at GPO skal "ramme".

[roac]

Bra svart roac, men du tar feil på et punkt.

 

Det er forøvrig ikke mulig å linke GPOer til grupper, og dersom du linker en GPO til et OU som inneholder en gruppe, har dette heller ikke noen effekt. Kontoen til den/de aktuelle brukeren(e) og/eller PCen(e) må ligge i OUet, eller et underliggende.

 

Det er mulig i Windows 2003 å sette GPOer direkte på en security gruppe. Default blir alle GPOer automatisk tilegnet gruppen "authenticated users". Dette kan du sjekke og teste selv ved bruk av det hendige verktøyet GPMC. Start dette verktøyet, klikk på en policy du finner i ett av dine domains - sjekk under fanen "scope" og nederst (På høyre side) under overskriften Security filtering. Her kan du velge hvilken security gruppe du vil at GPO skal "ramme".

Godt forsøk, men du tar feil, så nå tar jeg dette grundig all den tid jeg vet hva jeg snakker om her.

 

For det første. Du kan ikke linke en GPO til en gruppe, men til en site, et domene eller et OU, i tillegg til at du har en lokal poliy som kan settes på den enkelte PC/Server. Det du snakker om er security filtering, som kan kontrollere hvem som har lov til å få innstillingene i policyen. Du er fremdeles avhengig av at den enkelte brukerkonto eller maskinkonto befinner seg i det aktuelle OU, eller et underliggende, dersom GPOen er linket til et OU. Det hjelper fremdeles like lite om brukeren ikke ligger i OUet, men at en gruppen han/hun er medlem av faktisk gjør det.

 

Hvis det er noe mer du lurer på i forbindelse med GPOer må du gjerne spørre meg, jeg er innom her for å hjelpe og oppklare, men jeg tror vi har ryddet opp i det meste nå.

[roac]

Bra svart roac, men du tar feil på et punkt.

 

Det er forøvrig ikke mulig å linke GPOer til grupper, og dersom du linker en GPO til et OU som inneholder en gruppe, har dette heller ikke noen effekt. Kontoen til den/de aktuelle brukeren(e) og/eller PCen(e) må ligge i OUet, eller et underliggende.

 

Det er mulig i Windows 2003 å sette GPOer direkte på en security gruppe. Default blir alle GPOer automatisk tilegnet gruppen "authenticated users". Dette kan du sjekke og teste selv ved bruk av det hendige verktøyet GPMC. Start dette verktøyet, klikk på en policy du finner i ett av dine domains - sjekk under fanen "scope" og nederst (På høyre side) under overskriften Security filtering. Her kan du velge hvilken security gruppe du vil at GPO skal "ramme".

Godt forsøk, men du tar feil, så nå tar jeg dette grundig all den tid jeg vet hva jeg snakker om her.

 

For det første. Du kan ikke linke en GPO til en gruppe, men til en site, et domene eller et OU, i tillegg til at du har en lokal poliy som kan settes på den enkelte PC/Server. Det du snakker om er security filtering, som kan kontrollere hvem som har lov til å få innstillingene i policyen. Du er fremdeles avhengig av at den enkelte brukerkonto eller maskinkonto befinner seg i det aktuelle OU, eller et underliggende, dersom GPOen er linket til et OU. Det hjelper fremdeles like lite om brukeren ikke ligger i OUet, men at en gruppen han/hun er medlem av faktisk gjør det.

 

Hvis det er noe mer du lurer på i forbindelse med GPOer må du gjerne spørre meg, jeg er innom her for å hjelpe og oppklare, men jeg tror vi har ryddet opp i det meste nå.

[kamus]

Bra svart roac, men du tar feil på et punkt.

 

Det er forøvrig ikke mulig å linke GPOer til grupper, og dersom du linker en GPO til et OU som inneholder en gruppe, har dette heller ikke noen effekt. Kontoen til den/de aktuelle brukeren(e) og/eller PCen(e) må ligge i OUet, eller et underliggende.

 

Det er mulig i Windows 2003 å sette GPOer direkte på en security gruppe. Default blir alle GPOer automatisk tilegnet gruppen "authenticated users". Dette kan du sjekke og teste selv ved bruk av det hendige verktøyet GPMC. Start dette verktøyet, klikk på en policy du finner i ett av dine domains - sjekk under fanen "scope" og nederst (På høyre side) under overskriften Security filtering. Her kan du velge hvilken security gruppe du vil at GPO skal "ramme".

Godt forsøk, men du tar feil, så nå tar jeg dette grundig all den tid jeg vet hva jeg snakker om her.

 

For det første. Du kan ikke linke en GPO til en gruppe, men til en site, et domene eller et OU, i tillegg til at du har en lokal poliy som kan settes på den enkelte PC/Server. Det du snakker om er security filtering, som kan kontrollere hvem som har lov til å få innstillingene i policyen. Du er fremdeles avhengig av at den enkelte brukerkonto eller maskinkonto befinner seg i det aktuelle OU, eller et underliggende, dersom GPOen er linket til et OU. Det hjelper fremdeles like lite om brukeren ikke ligger i OUet, men at en gruppen han/hun er medlem av faktisk gjør det.

 

Hvis det er noe mer du lurer på i forbindelse med GPOer må du gjerne spørre meg, jeg er innom her for å hjelpe og oppklare, men jeg tror vi har ryddet opp i det meste nå.

Jeg er dønn enig med deg roac, men jeg mener at hvis du legger en security group inn i filtering, så kan man i en singel GPO også bruke security groups i tillegg til brukere og maskiner.

 

Filtering using security groups

Endret 16. juni 2005 av kamus

[roac]

Jeg er dønn enig med deg roac, men jeg mener at hvis du legger en security group inn i filtering, så kan man i en singel GPO også bruke security groups i tillegg til brukere og maskiner.

 

Filtering using security groups

La meg sitere websiden du ga link til:

The settings in a GPO will apply only to users and computers that are contained in the domain, organizational unit, or organizational units where the GPO is linked, and that are specified in, or are members of a group that are specified in Security Filtering.

 

For å gjenta en gang til: Du kan ikke gi brukere innstillinger via GPO ved å linke en GPO til et OU hvor det er en gruppe som brukere er medlemmer av. Det må være brukerobjektet som ligger i OUet (eller underliggende).

 

Takk for at du fant dokumentasjon for at jeg hadde rett

Endret 16. juni 2005 av roac

[Kenny Bones]

Det jo vel ganske likt uansett vel? Man kan jo legge en gruppe inn i et OU og deretter linke en policy til OUet. Da vil jo den policyen gjelde for den gruppen også da, så blir jo samme resultat vel?

 

Hm, skal lage en oversikt i Visio jeg for å prøve å forstå bedre. Kan sikkert legge den ved her senere så kan du/dere se over om det er noe jeg har misforstått.

[roac]

Det jo vel ganske likt uansett vel? Man kan jo legge en gruppe inn i et OU og deretter linke en policy til OUet. Da vil jo den policyen gjelde for den gruppen også da, så blir jo samme resultat vel?

 

Hm, skal lage en oversikt i Visio jeg for å prøve å forstå bedre. Kan sikkert legge den ved her senere så kan du/dere se over om det er noe jeg har misforstått.

Nei, det blir ikke likt. Tenk følgende:

 

- Domene
 - OU 1
   - Gruppe
 - OU 2
   - Bruker

Du Linker en GPO til OU1. "Bruker" er medlem av "Gruppe". Uansett om du setter security filtering eller ei til for "Gruppe" på GPOen, vil "Bruker" aldri kunne få innstillingene fra den GPOen som er linket til OU1, all den tid bruker ikke ligger innunder det aktuelle OU. Dette har blitt gjort veldig klart en del ganger nå, såvel fra meg som den linken kamus ga.

 

La meg bare gjenta en gang for alle: Du kan ikke sette GPO på en gruppe, men bare begrense hvem som får innstillingene fra den ved hjelp av security filtering.

Endret 17. juni 2005 av roac

[kamus]

Jepp, roac du har helt rett, jeg leste ikke teksten godt nok, misforstod den noe i forhold til definisjonen. Som jeg sa i forrige innlegg, du hadde helt korrekt men jeg mente at man kunne bruke security goups inn via filtering.

 

Kamus

[dirr]

hehe, denne tråden har jo tatt helt av, spesiellt med tanke på at jeg besvarte spørsmålet i andre post!

 

Jeg vil også bekrefte at roac har rett, så nå håper jeg diskusjonen er avsluttet

[roac]

Passord polices må settes i Default Domain Policy (ikke Default Domain Controller Policy).

Jeg håper ikke at dette får tråden til å ta av igjen, men føler at en liten korrigering (aka flisespikking) er på sin plass. Password policies for domenekontoer må settes på en policy som linkes til domenet, dette trenger ikke være default domain policy, men default domain policy er vel den eneste policy som er linket til domenet som standard.