Account Operators: Rolle og Begrænsninger i AD

I den komplekse verden af Active Directory (AD) er administration af brugerrettigheder en af de mest kritiske opgaver for at opretholde sikkerheden. Blandt de mange indbyggede sikkerhedsgrupper er Account Operators-gruppen ofte genstand for misforståelser. Mange tror, at denne gruppe har vidtrækkende beføjelser, mens andre undervurderer den potentielle risiko, den udgør. Denne artikel vil dykke ned i, hvad Account Operators reelt kan og ikke kan, afkræfte almindelige myter og give klare retningslinjer for, hvordan man bedst håndterer denne gruppe for at beskytte sin organisation.

Hvad er Account Operators-gruppen?

Ifølge Microsofts officielle definition giver Account Operators-gruppen begrænsede privilegier til oprettelse af konti til en bruger. Medlemmer af denne gruppe kan oprette og ændre de fleste typer konti, herunder brugerkonti, lokale grupper og globale grupper. De kan også logge lokalt på domænecontrollere. Det er dog afgørende at forstå gruppens begrænsninger for at få et fuldstændigt billede af dens funktion.

Primære Roller og Rettigheder

• Oprettelse og Ændring af Konti: Medlemmer kan oprette nye brugere og grupper samt ændre eksisterende (dog med vigtige undtagelser).
• Lokal Logon på Domænecontrollere: De har rettigheden til at logge direkte på en domænecontroller, hvilket giver dem adgang til administrative værktøjer på disse kritiske servere.

Væsentlige Begrænsninger

Selvom navnet antyder en bred kontrol over konti, er der strenge begrænsninger indbygget for at beskytte de mest privilegerede aktiver i Active Directory. Et medlem af Account Operators-gruppen kan IKKE:

• Administrere administratorkontoen eller andre brugerkonti, der er medlemmer af administrative grupper.
• Ændre medlemskabet af højt privilegerede grupper såsom: Administrators, Domain Admins, Enterprise Admins, Server Operators, Backup Operators, Print Operators eller selve Account Operators-gruppen.
• Ændre brugerrettigheder (User Rights Assignments), som definerer, hvilke handlinger en bruger kan udføre på et system, f.eks. "Log on as a service".

Disse begrænsninger er designet til at forhindre en Account Operator i direkte at eskalere sine egne eller andres privilegier til domæneadministratorniveau.

Afkræftning af Myter: Hvad Siger Testene?

På internettet florerer der mange påstande om, hvad Account Operators kan. Nogle blogindlæg og endda AI-værktøjer har fejlagtigt hævdet, at de kan tilføje brugere til højt privilegerede grupper. For at få klarhed er det nødvendigt at teste disse teorier i et kontrolleret laboratoriemiljø. Lad os se på resultaterne.

Myte 1: Kan de tilføje brugere til Domain Admins?

Dette er en af de mest almindelige misforståelser. Et forsøg på at tilføje en bruger til "Domain Admins"-gruppen som en Account Operator vil altid resultere i en "Access is denied"-fejl. Systemet forhindrer eksplicit denne handling.

Add-ADGroupMember -Identity "Domain Admins" -Members [brugernavn]
FEJL: Access is denied

Myte 2: Kan de ændre adgangskoden for en administrator?

Svaret her er mere nuanceret og er kilden til megen forvirring. Som udgangspunkt kan en Account Operator ikke ændre adgangskoden for en bruger, der er medlem af en beskyttet gruppe som Domain Admins. Men der findes et kort tidsvindue, hvor det *kan* lade sig gøre.

Dette skyldes en baggrundsproces i Active Directory kaldet SD Propagator (Security Descriptor Propagator). Når en bruger tilføjes til en beskyttet gruppe, bliver attributten adminCount på brugerobjektet sat til 1. Denne proces kører som standard hvert 60. minut, men i praksis ofte hurtigere. Før `adminCount` er sat til 1, er brugeren endnu ikke fuldt beskyttet af de strengeste sikkerhedsindstillinger, og en Account Operator kan i dette korte tidsrum nå at nulstille adgangskoden. Så snart `adminCount` er sat, er det ikke længere muligt.

I en reel penetrationstest er dette tidsvindue så lille, at det er praktisk talt umuligt at udnytte. Det er dog vigtigt at forstå mekanismen for at undgå forkerte konklusioner under test.

Myte 3: Kan de tilføje brugere til en undergruppe af Domain Admins?

Hvad nu hvis man opretter en ny gruppe, "NestedAdmins", og gør den til medlem af Domain Admins? Kan en Account Operator så tilføje brugere til "NestedAdmins"?

Igen er svaret ja, men kun midlertidigt. Ligesom med brugerobjekter har gruppeobjekter også en `adminCount`-attribut. Når "NestedAdmins" bliver medlem af Domain Admins, vil SD Propagator-processen efter kort tid sætte dens `adminCount` til 1. Før dette sker, kan en Account Operator tilføje brugere til gruppen. Efter processen er kørt, vil forsøget fejle med "Access is denied".

Sammenligningstabel: Rettigheder før og efter SD Propagator

Denne tabel opsummerer, hvordan rettighederne ændrer sig, når SD Propagator-processen har beskyttet et objekt.

Den Reelle Værdi (og Risiko) ved Account Operators

Selvom en Account Operator ikke direkte kan blive Domain Admin, er gruppen langt fra værdiløs for en angriber. Privilegierne kan misbruges kreativt til at opnå adgang på andre måder. En angriber med kontrol over en Account Operator-konto kan potentielt:

• Få adgang til LAPS-adgangskoder: Tilføje en bruger til en gruppe, der har rettigheder til at læse LAPS (Local Administrator Password Solution) adgangskoder for arbejdsstationer og servere.
• Opnå lokal administratoradgang: Tilføje en bruger til en gruppe, der giver lokale administratorrettigheder på et stort antal maskiner. Dette kan bruges til at dumpe legitimationsoplysninger fra hukommelsen (LSASS).
• Få RDP-adgang: Tilføje en bruger til grupper, der giver adgang via Remote Desktop (RDP) til servere eller arbejdsstationer, hvilket åbner for yderligere angreb.
• Få adgang til følsomme data: Tilføje en bruger til grupper med adgang til forretningskritiske data, såsom HR-, finans- eller IT-afdelingens filshares. Det handler ikke altid om at blive domæneadministrator; data-tyveri kan være lige så skadeligt.

Kreativitet er nøglen for en angriber. Account Operator-rettigheder giver dem mulighed for at manipulere adgang til mange andre ressourcer, der ikke er direkte beskyttet af `adminCount`-mekanismen.

Bedste Praksis for Håndtering af Account Operators

For at minimere risikoen forbundet med denne gruppe, bør organisationer følge disse retningslinjer:

1. Hold gruppen tom: Som standard er Account Operators-gruppen tom. Dette er den sikreste konfiguration. Undgå at tilføje brugere til denne gruppe, medmindre der er en ekstremt velbegrundet årsag.
2. Undgå delegeret administration via denne gruppe: Brug i stedet en mere detaljeret delegeringsmodel, hvor specifikke rettigheder tildeles til specifikke grupper i afgrænsede Organizational Units (OUs). Princippet om mindste privilegium (Principle of Least Privilege) bør altid følges.
3. Overvåg medlemskab og aktivitet: Hvis gruppen skal bruges, skal dens medlemskab og alle handlinger udført af dens medlemmer overvåges nøje. Enhver ændring bør generere en alarm.
4. Uddan dit IT-personale: Sørg for, at administratorer forstår de reelle rettigheder og begrænsninger for alle indbyggede grupper for at undgå utilsigtede sikkerhedshuller.

Ofte Stillede Spørgsmål (FAQ)

Kan en Account Operator gøre sig selv til Domain Admin?

Nej, ikke direkte. Gruppen er eksplicit blokeret fra at ændre medlemskabet af Domain Admins og andre beskyttede grupper. En eskalering af privilegier ville kræve udnyttelse af andre fejlkonfigurationer i netværket.

Hvorfor kan jeg nogle gange ændre adgangskoden for en ny administrator?

Dette skyldes forsinkelsen i SD Propagator-processen, der sætter `adminCount`-attributten. Det er et kortvarigt fænomen, som forsvinder, så snart objektet er fuldt beskyttet, typisk inden for få minutter.

Er Account Operators-gruppen farlig?

Den er ikke så farlig som Domain Admins, men den er en privilegeret gruppe. I de forkerte hænder kan den være en effektiv trædesten til yderligere kompromittering af netværket. Den bør behandles med forsigtighed.

Bør vi slette Account Operators-gruppen?

Nej. Det er en indbygget gruppe, som ikke kan slettes. Den bedste praksis er at sikre, at den forbliver tom og overvåges.