Når en AD-test finder en vej fra en almindelig konto til en administrator, går vejen ikke nødvendigvis gennem de kendte administratorgrupper. Den går gennem en rettighed, som nogen engang har givet over en del af kataloget: retten til at nulstille adgangskoder, ændre medlemskaber eller styre bestemte objekter. Svaret på, hvorfor den slags fund overrasker, hviler på, at delegerede rettigheder ikke vises i de lister, IT normalt kigger i, og at de arves videre til alt, der senere lægges samme sted.
Delegering er ikke en fejl i sig selv. Det er netop den måde, Microsoft anbefaler at give smallere rettigheder på. Problemet er delegering, der ikke længere svarer til et behov.
Hvad delegering er
Microsoft beskriver, hvordan administration kan uddelegeres ved hjælp af organisationsenheder. Objekter, der skal styres, samles i en enhed, og en gruppe får ret til bestemte opgaver i den. Én gruppe kan få fuld kontrol, en anden kun ret til at oprette og slette brugere, og en tredje kun ret til at nulstille adgangskoder. Rettighederne kan gøres arvelige, så de også gælder for underliggende enheder.
Det er et fint redskab til at give servicedesken og afdelinger netop det, de skal bruge. Men hver delegering er en ny rettighed i kataloget, og over tid lægger de sig i lag.
Hvordan rettighederne hober sig op
Et tænkt forløb: for ti år siden fik en lokal IT-ansvarlig på en filial fuld kontrol over filialens brugere. Senere blev filialens enhed lagt ind under en fælles enhed, og rettigheden blev arvet med. Endnu senere blev nogle servicekonti og en enkelt administratorkonto flyttet derind, fordi det var praktisk. Den lokale IT-ansvarlige har forladt virksomheden, men gruppen findes, og en anden medarbejder er medlem.
Ingen af trinene var forkerte for sig. Tilsammen har en almindelig medarbejder fået ret til at nulstille adgangskoden på en administratorkonto. Den slags kæder er det, testen leder efter.
Microsoft peger på en anden mekanisme, der gør det sværere: den, der får ret til at oprette objekter i en enhed, får samtidig ret til at ændre de objekter, den selv opretter. Rettigheder kan altså opstå som en bivirkning af en anden rettighed.
Det, testen ser på
Testen ser på rettighederne som sammenhænge snarere end enkeltlinjer. Fundene beskrives som det, der kan lade sig gøre, ikke som en fremgangsmåde.
- Rettigheder over privilegerede konti · hvem der kan ændre adgangskoder, medlemskaber eller egenskaber på konti med høje rettigheder. → Privilegerede grupper i Active Directory
- Rettigheder over grupper · hvem der kan tilføje medlemmer til grupper, der giver adgang til servere eller data.
- Rettigheder givet til personer · rettigheder, der er givet direkte til en brugerkonto i stedet for en gruppe, og som derfor er svære at gennemgå.
- Arvede rettigheder · rettigheder, der gælder langt længere ned i strukturen, end det var meningen.
- Ejerskab · konti eller grupper, der ejer objekter og derfor kan ændre deres rettigheder.
Rapporten bør vise hele vejen, ikke kun den sidste rettighed. Det kan være et led midt i kæden, der er lettest og sikrest at bryde.
Det, IT skal have klar
En test af rettigheder kræver ikke meget forberedelse, men den bliver bedre, hvis testeren kender de bevidste valg. Giv en kort oversigt over de delegeringer, I kender til: hvilke grupper servicedesken bruger, hvilke afdelinger der selv administrerer brugere, og hvilke programmer der har fået rettigheder i kataloget. Så kan rapporten skelne mellem en kendt delegering, der er bredere end nødvendigt, og en rettighed, som ingen vidste fandtes.
Aftal også, hvordan testeren skal forholde sig, hvis en vej til de mest betroede konti viser sig. Det normale er at påvise vejen og stoppe, uden at ændre noget. Hvis der alligevel ændres noget, skal det fremgå af testerens liste over spor, så det kan rulles tilbage.
Sådan kortlægger I på begrebsniveau
Kortlægning af rettigheder er arbejdskrævende, fordi standardværktøjerne viser én rettighed ad gangen. Der findes værktøjer, som kan vise rettigheder som sammenhænge, men selve opgaven er den samme uanset værktøj.
- Start med det vigtigste · kortlæg først, hvem der har rettigheder over de mest betroede konti, grupper og domænecontrollere.
- Find ejeren · for hver delegering: hvilket behov dækker den, og hvem i virksomheden står inde for den?
- Skel mellem gruppe og person · rettigheder givet direkte til personer flyttes over på grupper eller fjernes.
- Se på arven · vurder, om en rettighed skal gælde for alt under en enhed, eller kun for enheden selv.
- Flyt de betroede konti · administratorkonti og tjenestekonti med høje rettigheder bør ligge i enheder, hvor kun de mest betroede administratorer har rettigheder. → Lagdelt administration
Microsoft anbefaler, at de standardenheder, der oprettes med kataloget, forbliver under kontrol af de mest betroede administratorer, og at delegering sker i særskilte enheder. Det er et godt princip at bygge oprydningen op om.
Rettelser uden at stoppe driften
Fjernes en delegering, som nogen bruger hver dag, mærkes det med det samme. Servicedesken kan ikke længere nulstille adgangskoder, eller et program kan ikke længere oprette konti. Aftal ændringerne med dem, der bruger rettighederne, og erstat dem med smallere roller, før de gamle fjernes. → Mindst mulig adgang i praksis
Rettigheder, der giver vej til de mest betroede konti, bør fjernes hurtigt, også selv om resten af oprydningen tager tid. Resten kan indgå i en samlet plan. → Oprydning i Active Directory efter testen
Det skal I lade være med
- At kigge efter administratorer kun i gruppemedlemskaber. Delegerede rettigheder kan give lige så meget.
- At fjerne rettigheder uden at kende brugen. Servicedesk og integrationer kan stoppe.
- At give rettigheder direkte til personer. De forsvinder ikke, når personen skifter rolle.
- At lægge betroede konti i enheder, hvor andre har rettigheder. Arven rækker også til dem.
- At se oprydningen som en engangsopgave. Nye delegeringer kommer til hele tiden.
Hvad kan og ikke kan konkluderes
Testen viser de rettigheder og veje, testeren fandt fra de aftalte konti, og den peger på de led, der kunne bruges. Den giver ikke en fuldstændig oversigt over alle rettigheder i kataloget, og den kan ikke vurdere, hvilke delegeringer driften har brug for. Det er IT-afdelingens og systemejernes opgave.
Tjekliste til delegerede rettigheder
- ☐ Er rettigheder over de mest betroede konti og grupper kortlagt?
- ☐ Har hver delegering en ejer og et kendt formål?
- ☐ Er rettigheder givet direkte til personer flyttet eller fjernet?
- ☐ Ligger administratorkonti i enheder uden bred delegering?
- ☐ Er arv vurderet, så rettigheder ikke rækker længere end tilsigtet?
- ☐ Er der en fast gennemgang af nye delegeringer?
Kilder
- Microsoft Learn: Delegating administration by using OU objects: delegering via organisationsenheder, arvelige rettigheder, standardenheder under kontrol af de mest betroede administratorer og afledte rettigheder til objekter, man selv opretter.
- Microsoft Learn: Implementing least-privilege administrative models: rettigheder ud over det daglige behov og mindst mulig adgang til administration.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Active Directory-test i dybden · Gruppepolitikker som testområde
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
