Gruppepolitikker er den mekanisme, der sørger for, at tusind maskiner opfører sig ens. Den samme egenskab gør dem til et testområde, hvor en enkelt fejl får stor rækkevidde: en forkert indstilling eller en for bred rettighed i én politik rammer alle de maskiner og brugere, politikken gælder for. Svaret på, hvad testen kan vise, hviler derfor på to spørgsmål. Hvad sætter politikkerne op, og hvem kan ændre dem?
Det første spørgsmål handler om hærdning. Det andet handler om kontrol over miljøet, og det kan være det alvorligste.
Sådan virker arven
Microsoft beskriver en gruppepolitik som en samling indstillinger, der gemmes i Active Directory og i en delt mappe på domænecontrollerne. Politikker kobles til lokationer, domæner og organisationsenheder, og de arves som udgangspunkt nedad i strukturen. En maskine henter sine politikker ved opstart, en bruger ved login, og derefter opdateres de løbende.
For IT-afdelingen er pointen, at politikkerne er usynlige i hverdagen. De virker, så længe ingen klager. Over år samler der sig politikker fra gamle projekter, testopsætninger, der aldrig blev fjernet, og undtagelser for enkelte afdelinger. Strukturen af organisationsenheder afgør, hvad der rammer hvem, og den er måske ikke tegnet op nogen steder.
Det, testen ser på
En test af gruppepolitikker kigger på opsætningen fra en almindelig konto, fordi meget af den kan læses af alle brugere i domænet. Fundene falder i nogle få grupper.
- Rettigheder til at ændre · hvem der kan redigere en politik eller koble den til en organisationsenhed. En bruger eller gruppe med den ret kan i praksis styre alle maskiner, politikken rammer.
- Filer, politikkerne peger på · scripts og installationspakker i delte mapper, hvor andre end administratorer kan skrive. → Delte mapper og rettigheder
- Loginoplysninger · politikker eller tilknyttede filer, der indeholder adgangskoder til konti. → Adgangskoder i scripts og konfigurationsfiler
- Svag opsætning · indstillinger, der sænker sikkerheden bredt, fx gamle protokoller, der er slået til for at få et ældre system til at virke. → Gamle protokoller
- Huller i dækningen · maskiner, der ligger i en organisationsenhed, hvor de vigtige politikker ikke rammer.
Forberedelsen fra IT’s side er beskeden. Testeren har brug for en almindelig konto og en kort beskrivelse af strukturen: hvilke organisationsenheder der rummer klienter, servere og domænecontrollere, og hvem der administrerer politikkerne i dag. Fortæl også, hvis en del af opsætningen styres fra et andet værktøj end gruppepolitikker, fx en løsning til enhedsstyring i skyen. Så kan rapporten sige, hvad der faktisk blev dækket, og hvad der ligger et andet sted.
Rapporten bør skelne mellem det, der er en svaghed i opsætningen, og det, der er en vej til kontrol. Det første kan vente på en planlagt hærdning. Det andet kan ikke.
Hvorfor rækkevidden er så stor
En rettighed til at ændre en politik, der gælder alle klienter, er i realiteten administratoradgang til alle klienter. Hvis politikken gælder servere eller domænecontrollere, rækker den endnu længere. Den slags rettigheder kan være givet til en servicedesk, en leverandør eller en projektgruppe for længe siden, og de fremgår ikke af listen over medlemmer i de privilegerede grupper. → Privilegerede grupper i Active Directory
Det samme gælder filer, som politikkerne kører. Et script, der afvikles på alle maskiner ved opstart, er kun så sikkert som den mappe, det ligger i. Kan en almindelig bruger ændre filen, kan den bruger påvirke alle de maskiner, der kører den.
Derfor kan en rettighedsfejl i en bredt koblet politik rangere højt, selv om den ser uskyldig ud i en liste. Det er rækkevidden, der bestemmer alvoren, ikke indstillingen i sig selv. Bed testeren angive, hvilke maskiner hver politik i fundet gælder for, så I kan se omfanget med det samme.
Sådan retter I efter testen
Rettelserne følger to spor, der kører hver for sig.
- Kontrol først · fjern rettigheder til at redigere og koble politikker fra alle, der ikke administrerer kataloget. Stram rettighederne på de mapper og filer, politikkerne bruger.
- Fjern loginoplysninger · adgangskoder i politikker og scripts skal fjernes og skiftes, fordi de må betragtes som kendte.
- Ryd op i politikkerne · politikker uden formål, uden kobling eller med modstridende indstillinger fjernes eller samles.
- Hærd planmæssigt · svag opsætning rettes som en del af et hærdningsforløb. Microsoft anbefaler at tage udgangspunkt i en anerkendt og afprøvet basisopsætning frem for at bygge sin egen. → Hærdningsstandarder
- Luk huller i dækningen · sørg for, at alle maskiner ligger, hvor de vigtige politikker rammer.
Det første og andet punkt kan være hurtige rettelser. Det fjerde er et projekt, fordi skærpede indstillinger kan stoppe ældre systemer. Test dem på en lille gruppe maskiner først, og hav en vej tilbage. → Permanente rettelser
Hold styr på ændringer
Gruppepolitikker kan blive ændret uden at gå gennem den samme ændringsstyring som servere og netværk, fordi ændringen er hurtig at lave. Det er en af grundene til, at de vokser. Indfør, at ændringer i politikker, der rammer mange maskiner, registreres, godkendes og kan føres tilbage. Overvåg ændringer i politikker og i rettighederne til dem, så en uventet ændring bliver set.
Er driften lagt ud, skal aftalen sige, hvem der må ændre politikkerne, og hvordan I får besked, når det sker. Et tænkt eksempel: driftsleverandøren tilføjer en politik for at løse et printerproblem på én afdeling, men kobler den højt i strukturen, så den rammer alle. Uden registrering opdager ingen det, før noget går i stykker.
Det skal I lade være med
- At se gruppepolitikker som ren konfiguration. Retten til at ændre dem er en privilegeret adgang.
- At hærde alle indstillinger på én gang. Ældre systemer kan stoppe uden varsel.
- At lade scripts ligge i mapper, som andre end administratorer kan skrive i.
- At beholde politikker, ingen kan forklare. De er en kilde til både fejl og fund.
- At ændre politikker uden registrering. Det gør det umuligt at se, hvornår en svaghed kom til.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke politikker og rettigheder testeren kunne se og vurdere fra de aftalte konti, og om de gav en vej til bredere kontrol. Den kan ikke garantere, at alle politikker er vurderet i detaljer, og den viser ikke, om en skærpet indstilling vil virke sammen med jeres systemer. Det afklares ved afprøvning internt.
Tjekliste til gruppepolitikkerne
- ☐ Er det kun administratorer af kataloget, der kan ændre og koble politikker?
- ☐ Er mapper og filer, politikkerne bruger, beskyttet mod ændringer?
- ☐ Er loginoplysninger fjernet fra politikker og scripts, og er de skiftet?
- ☐ Er politikker uden formål fjernet?
- ☐ Findes der en plan for hærdning ud fra en anerkendt basisopsætning?
- ☐ Registreres og overvåges ændringer i politikkerne?
Kilder
- Microsoft Learn: Group Policy overview for Windows Server: politikker gemmes i AD og på domænecontrollerne, kobles til lokationer, domæner og organisationsenheder og arves nedad.
- Microsoft Learn: Security baselines guide: anbefaler en anerkendt og afprøvet basisopsætning frem for en hjemmelavet, leveret bl.a. som gruppepolitikker.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Lokale administratorkonti på klienter og servere · Rettelser uden at stoppe driften
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
