AGDLP – hvorfor må vi ha det?

Forrige modul lærte du om grupper. Du vet at Global og Domain Local finnes, og du vet at grupper brukes til å gi rettigheter. Men hvorfor trenger vi to forskjellige gruppetyper? Hvorfor ikke bare én?

La oss illustrere problemet med et eksempel. NovaTech har 200 ansatte fordelt på 4 avdelinger, og bedriften har 50 forskjellige mapper på filserveren med ulike tilgangsbehov. Hver ansatt trenger tilgang til 5-10 mapper.

Den naive løsningen – gi hver bruker direkte tilgang til hver mappe – betyr fort:

• 200 brukere × 7 mapper i snitt = 1400 tilgangstildelinger å vedlikeholde
• Ny ansatt Per i Salg → du må manuelt sette opp ham med tilgang til 7 mapper
• Per bytter til Markedsføring → fjern 7 tilganger, legg til 7 nye
• Per slutter → husk å fjerne alle 7 tilgangene (gjør du ikke det = sikkerhetshull)

AGDLP gir oss en tilgangskjede som separerer to ting som ofte forveksles:

AGDLP kobler disse to verdenene via grupper, så de kan endres uavhengig av hverandre.

AGDLP-mønsteret i detalj

AGDLP står for Accounts → Global groups → Domain Local groups → Permissions. La oss gå gjennom hvert ledd med Kari Hansen som case:

🪪 A — Account (brukerkontoen)

Vi starter med selve brukeren. Kari har en domenekonto: kari.hansen. Hun jobber i Salg-avdelingen hos NovaTech.

🌐 G — Global Group (rollebasert)

Vi lager en gruppe som representerer rollen Karis er i. Alle som jobber i Salg legges i denne gruppen. Vi kaller den g_salg.

Hvis Kari bytter til Markedsføring senere, flytter vi henne fra g_salg til g_markedsforing – og hennes tilganger oppdateres automatisk. Du trenger ikke å huske hver eneste mappe hun hadde tilgang til.

🏠 DL — Domain Local Group (ressursbasert)

For hver ressurs vi vil dele ut, lager vi en gruppe som representerer den tilgangen. For lese-tilgang til Salg-mappen: dl_salg_filer_read.

Deretter legger vi g_salg som medlem av dl_salg_filer_read. Hele Salg-rollen får dermed tilgangen i ett strøk.

🔐 P — Permissions (faktisk rettighet)

Til slutt setter vi de faktiske NTFS-rettighetene på selve mappen. Vi gir dl_salg_filer_read Read-tilgang til \\fileserver\Salg.

Magien skjer når en ny ansatt starter. Anta at Ola begynner i Salg:

1. Opprett brukerkontoen ola.nordmann
2. Legg ham i g_salg
3. Det er det. Han har nå tilgang til alle Salg-mapper automatisk.

Hvis Ola slutter, slett kontoen hans (eller deaktiver den). Alle tilgangene fjernes umiddelbart fra hele kjeden, fordi de var aldri tildelt ham direkte.

Navnekonvensjoner – språk for grupper

Sensorveiledningen din nevner eksplisitt at du skal «følge fast navnekonvensjon». Dette er ikke kosmetisk – det er essensielt fordi gruppenavn forteller hvem som leser dem hva gruppen gjør, uten å måtte slå opp.

Standard-mønsteret som brukes i forelesningene dine:

Legg merke til strukturen i DL-navnene: dl_<ressurs>_<handling>. Dette gjør at du ved et blikk kan se hva gruppen gir tilgang til og på hvilken måte.

Velkommen til PowerShell

OK – så vi vet hvordan vi burde sette opp tilgangsstyring (AGDLP). Men hvis vi skal lage 30 brukere, 4 OU-er, 4 Global-grupper, 8 Domain Local-grupper, og koble dem alle riktig... det blir mye klikking i grafiske verktøy.

Dette er hvor PowerShell kommer inn. PowerShell er et automatiseringsspråk som er bygget rett inn i Windows. Du skriver instrukser, kjører dem, og PowerShell utfører dem mye fortere og mer pålitelig enn manuell klikking.

Hva gjør PowerShell spesielt?

Verb-Substantiv – PowerShells DNA

Det fantastiske med PowerShell-kommandoer (kalt cmdlets) er at de følger et helt forutsigbart navnemønster: Verb-Substantiv.

Verbet sier hva du vil gjøre. Substantivet sier hva du vil gjøre det på.

De 5 mest brukte verbene er:

• Get – hent / les noe
• Set – endre noe som finnes
• New – opprett noe nytt
• Remove – slett noe
• Add – legg til noe i en samling (f.eks. gruppemedlem)

Variabler, parametre, pipeline

For å skrive nyttige scripts trenger du tre konsepter til. La oss ta dem kjapt.

1. Variabler – lagre verdier

En variabel er et navn vi gir til en verdi vi vil bruke senere. I PowerShell starter alle variabler med $:

2. Parametre – gi cmdleter informasjon

Cmdletene tar in informasjon via parametre. Disse skrives med -Navn verdi:

Legg merke til at vi bruker variabelen $brukernavn i stedet for å skrive «kari.hansen» direkte. Dette er kjernen i hvorfor variabler er kraftige – vi kan bytte verdier én gang og ha dem brukt mange steder.

3. Pipeline – send data fra én cmdlet til neste

Pipeline (skrevet med |) lar oss sende output fra én kommando som input til den neste. Dette er supernyttig:

Verktøykassen: AD-cmdletene

Til eksamen trenger du å kjenne til disse cmdletene – ikke huske eksakt syntaks utenat, men forstå hva de gjør og når de brukes:

Brukeradministrasjon

Backtick (`) på slutten av linja er PowerShells «fortsett på neste linje» – kun for lesbarhet.

Gruppeadministrasjon

OU-administrasjon

ForEach-Object – iterere over data

OK – så vi vet hvordan vi oppretter én bruker. Men sjeldsynt har vi bare én. Vi har 30 nye ansatte, og vi vil ikke skrive New-ADUser 30 ganger.

Dette er hvor iterasjon kommer inn. Vi sier til PowerShell: «For hvert element i denne lista, gjør X». PowerShell vil utføre X for hvert eneste element, automatisk.

Cmdleten heter ForEach-Object (kortform %). Pseudokoden:

I PowerShell:

To kritiske ting å forstå her:

• Pipeline-en sender lista inn (med |)
• $_ betyr «det nåværende elementet i loopen». Første runde: $_ = "kari.hansen". Andre runde: $_ = "ola.nordmann". Osv.

Import-CSV – data inn i scriptet

I virkeligheten kommer brukerinformasjonen sjelden i en kort liste i koden – den kommer i en CSV-fil fra HR-systemet. CSV (Comma-Separated Values) er den enkleste tabellfilformatet som finnes:

Første linje er kolonneoverskriftene. Hver påfølgende linje er én rad med data.

Import-CSV leser denne fila og gir oss en samling objekter – ett objekt per rad. Hvert objekt har egenskaper som matcher kolonneoverskriftene:

Legg merke til $_.Name og $_.Department – det er slik vi henter egenskaper fra det nåværende objektet. Punktum mellom variabel og egenskap.

Mapping fra CSV til AD-bruker

I scriptet bruker du verdiene fra CSV-en til å fylle New-ADUser-parameterne:

If-Else og Try-Catch

If-Else – betinget logikk

Ofte skal scriptet ditt ta forskjellige valg avhengig av situasjonen. Hva hvis brukeren allerede finnes? Da skal du ikke prøve å opprette den på nytt.

Logikken er enkel: hvis betingelsen i parentesen er sann, kjøres første blokk. Ellers kjøres else-blokken.

Try-Catch – feilhåndtering

Hva skjer hvis CSV-fila ikke finnes? Hva hvis AD-tjenesten er nede? Hva hvis vi prøver å opprette en bruker i en OU som ikke eksisterer? Uten feilhåndtering krasjer scriptet ditt.

Try-Catch er PowerShells måte å si: «Prøv å gjøre dette. Hvis det går galt, gjør dette i stedet for å krasje.»

Pseudokode – bygg et helt script

Nå skal vi sette alt sammen. Husk det viktigste poenget fra eksamenstekstene dine:

Det betyr at du ikke trenger å huske eksakt PowerShell-syntaks på eksamen. Du trenger å vise at du forstår logikken. La oss bygge et komplett pseudokode-script som dekker et realistisk eksamen-scenario:

La oss bygge dette steg for steg som pseudokode:

Legg merke til at dette pseudokode-scriptet inkluderer alle nøkkelelementene fra pensumguiden:

• ✅ Import-CSV for å lese fila (steg 1)
• ✅ ForEach-Object for å iterere (steg 2)
• ✅ If-Else for å sjekke om brukeren finnes (steg 3)
• ✅ Try-Catch for feilhåndtering (rundt steg 3-7)
• ✅ AGDLP-prinsippet (steg 7: legger i Global-gruppe)
• ✅ DN-bygging (steg 4: bygger sti dynamisk)

Nøkkelpunktene du må huske

Det var en stor modul – men du har akkurat dekket hjertet av AD-automatisering. Her er destillasjonen: