Du har endelig konfigurert Microsoft 365-tenanten din med helt fantastiske, finjusterte, veldokumenterte policyer og konfigurasjoner – og du kan endelig sove godt om natten. 🥰 Men kan du egentlig det?

Hvordan vet du at konfigurasjonen du satte før lunch også gjelder etter lunch? Eller etter 1 dag? Eller etter en uke? Kanskje konfigurasjonen du utførte ble reversert umiddelbart av noen andre fordi den skapte problemer? Hvordan vet du isåfall at den ble reversert? Og er den flotte dokumentasjonen din troverdig lenger? 🧐🥵

Vi har en fin betegnelse som beskriver dette scenarioet:

Configuration drift (konfigurasjonsdrift) er et begrep innen IT-drift der servere, applikasjoner eller infrastruktur gradvis avviker fra sin opprinnelige, ønskede tilstand. Dette skjer ofte gjennom uoffisielle, manuelle endringer («hotfixes»), oppdateringer eller feil, noe som fører til inkonsekvente miljøer, sikkerhetshull og systemfeil.

Microsoft har nå lansert en forhåndsvisning av UTCM (Unified Tenant Configuration Management) som skal hjelpe oss med å ha mer kontroll på konfigurasjonsdrift i en Microsoft 365 tenant.

🤔 Hva er UTCM?

Kort forklart er UTCM (Unified Tenant Configuration Management) en løsning fra Microsoft som gjør det mulig å hente ut mesteparten av Microsoft 365 sin konfigurasjon (snapshots), definere den som en baseline og monitorere den.

Microsoft har per idag ikke lansert et grafisk grensesnitt for dette – så man må benytte endepunktene som er gjort tilgjengelig i Microsoft sitt Graph API.

Konfigurasjonen (snapshot) du velger å hente for de ulike ressursene lagres som en baseline i en monitor.

Monitoren kjører hver 6. time en kontroll på om tenant sin konfigurasjon avviker fra baseline.

Dersom det blir funnet avvik så blir dette rapportert som en konfigurasjonsdrift.

Konfigurasjonsdrift vil vise deg hva som er verdi i baseline og hva som er satt som den nye verdien i tenant – slik at du har mulighet til å gjøre en vurdering om hvilken verdi som skal være gjeldende.

• Dersom du ønsker å beholde den nye verdien i tenant så må du oppdatere baseline i monitoren. -Etter dette vil varselet om konfigurasjonsdrift slettes.

• Dersom du ønsker å beholde verdi i baseline så må du endre tenant sin konfigrasjon tilbake til slik den er definert i baseline.

Den nåværende testversjonen (public preview) av UTCM inneholder kun funksjonalitet for overvåking og deteksjon av konfigurasjonsdrift. Den tillater foreløpig ikke automatisert utbedring.

For å ta i bruk et verktøy som gir så mye innsikt i konfigurasjonen/sikkerheten i din tenant, så har Microsoft valgt en tilnærming som krever at vi manuelt aktivererer tjenesten og tildeler de nødvendige rettighetene basert på hva du ønsker å monitorere. Dette skal vi se nærmere på i punktet under.

⚠️ Forutsetninger for UTCM

Hvilke tilganger som trengs, vil avhenge av hvilke ressurser du planlegger å overvåke. Dette sikrer at UTCM ikke har tilgang til langt mer enn behovet.

For at UTCM skal kunne funger må den først «inviteres» inn i din Microsoft 365-løsning. Dette gjøres ved å opprette en egen «service principal» (en slags systembruker) som representerer løsningen. Denne vil du kunne finne igjen i Entra ID under Enterprise Applications med navnet Unified Tenant Configuration Management.

I testfasen (Public Preview) skjer ikke etableringen av dette automatisk. Du har to hovedmåter å gjøre dette på:

• Alternativ 1: Bruk av PowerShell (anbefalt for de fleste)
• Alterantiv 2: Bruk av Microsoft Graph API

Hvordan utfører jeg dette? Du finner oppdatert dokumentasjon på hvordan utføre dette her.

Hvilke ressurser støttes? Her finner du oversikt. Per i dag så støttes Defender, Entra, Exchange Online, Intune, Purview og Teams.

Hvordan vet jeg hvilke rettighet jeg må gi? Her finner du en fin oversikt over alle tilganger (permissions). Skal du for eksempel monitorere Conditional Access policyene dine så må du legge til Policy.Read.All.

🛡️ Bruker/applikasjonstilgang

Etter at punktet ovenfor er utført så har Microsoft sine systemer («backend») tilgang til å kjøre UTCM i din Microsoft 365 tenant. Det er på denne måten Microsoft kan kjøre en sjekk hver 6. time uten at du trenger å være pålogga. Du har altså gitt Microsoft tilgang til å kjøre dette selv.

Men du trenger også å etablere tilganger til dine brukerkontoer og eventuelle applikasjoner/integrasjoner som skal administrere UTCM.

Følgende roller er tilgjengelig:

• Lesetilgang: ConfigurationMonitoring.Read.All
• Lese/skrivetilgang: ConfigurationMonitoring.ReadWrite.All

Brukere/applikasjoner som er tildelt rollene kan da jobbe med Graph API endepunktene til UTCM.

Et eksempel kan være at du ønsker en integrasjon som sjekker om det finnes noen konfigurasjonsdrift. Da vil man som oftest opprette en Entra ID Application Registration som har application permission ConfigurationMonitoring.Read.All. Dette betyr at applikasjonen har de nødvendige rettighetene for å sjekke dette selv uten at en bruker trenger å logge på.

🧐 Hvordan fungerer UTCM?

1. Etablere en eller flere Monitor(s)
   • Monitor er den funksjonen som sjekker om tenant har konfigurasjonsdrift
   • Kjøringsfrekvensen er per dags dato låst til hver 6. time
   • Modus er per dags dato kun monitorering – ikke f.eks. automatisk reversering av konfigurasjonsdrift.
   • Man gir monitoren et ønsket navn og valgfri beskrivelse.
2. Definere baseline konfigurasjon
   • Når man oppretter en monitor, så må man også definere en baseline
   • En baseline er en samling av konfigurasjonstilstander for utvalgte ressurser
   • Man gir baseline et navn og en valgfri beskrivelse
3. Velge ressurser
   • Når man har har definert navn på baseline så må man velge ut hvilke ressuser man ønsker å monitorere
   • Det er et stort utvalg ressurser å velge mellom, f.eks. Conditional Access policyer, grupper, brukere eller Compliance policyer.
   • Når man har valgt en eller flere ressurser så må man definere hva som er ønsket konfigurasjonstilstand. Man kan gjøre det manuelt ved å følge definisjonene i UTMC Schema – eventuelt bruke snapshots.
4. Laste inn snapshots av nåværende konfigurasjon
   • Dersom man velger å bruke snapshots så hentes gjeldende konfigurasjon automatisk – og denne kan da benyttes inn i monitoren.
   • Når man henter f.eks. snapshot for Conditional Access policyer, så får man hver enkelt policy i retur. Hver policy legges inn som egen ressurs under baseline.
   • Snapshots er også noe man kan hente ut når som helst (uten å gå via monitor) – f.eks. for å studere nåværende konfigurasjon eller om man ønsker en integrasjon som daglig lagrer ressurser sin konfigurasjon i et tredjepartssystem.
5. Intervall for kontroll av konfigurasjonsdrift
   • Monitoren kjører hver 6. time.
   • Dette er per dags dato ikke mulig å endre.
6. Funn av konfigurasjonsdrift
   • Når monitoren oppdager at baseline avviker fra tenant sin konfigurasjon så opprettes det en konfigurasjonsdrift (configuration drift).
   • Innholdet er tidspunkt for deteksjon, tilhørende monitor, ressurstype, samt en ovesikt ønskede verdier fra baseline og nåværende verdier i tenant.

🌐 Graph API endepunkt

Her er en simpel oversikt over Graph API endepunkt. Et tips for å jobbe med Graph API er Graph Explorer.

Base URL: https://graph.microsoft.com/beta/admin/configurationManagement

😱 Håndtering av konfigurasjonsdrift

UTCM har per dags dato ingen innebygd automatikk i å håndtere konfigurasjonsdrift. Man får heller ikke se hvem som har utført endringer.

Fordelen er at du får se oversikt over alle detekterte konfigurasjonsdrift – som igjen inneholder hva verdien var før, hva den er nå og tidspunkt for deteksjon. På den måten kan du enklere planlegge veien videre i håndtering av dette.

Det betyr at du må selv lage automasjon, rutiner eller hva du måtte ønske for å jobbe videre med en konfigurasjonsdrift. For eksempel sjekke Entra ID sin Audit Log for å finne ut hvem som gjorde endringen.

😫 Begrensninger

Her er en oversikt over begrensninger per dags dato som er viktig å ta med i planlegginga av UTCM. Det er sikkert fristende å ta en snapshot av alle ressursene i hele tenanten, men da møter du nok fort på problemer med begrensningene. Begynn med de ressursene som du anser å være viktigst å passe på! 😎

• Opp til 30 monitorer
• Opp til 800 ressurser kan monitoreres per døgn
• Når en monitor oppdateres så slettes all tilhørende historikk (tidligere resultat og detektert konfigurasjonsdrift)
• Konfigurasjonsdrift som løses slettes etter 30 dager
• Snapshot kan hente ut maksimum 20,000 ressurser per måned
• Maksimum 12 snapshots er synlig for administrator. For å lage nye må man slette eksisterende.
• Snapshot lagres i 7 dager før det automatisk slettes.

🤖 Våre gode venn Claude vibbekoder litt!

Det er litt tungtvint å navigere i Microsoft Graph API for å jobbe med UTCM. Jeg ga dokumentasjonen til våre gode venn Claude Code og den satte igang vibbekodinga uten noen voldsomme protester 😍

Det ble utvikla en frontend i React som benytter en multi-tenant Entra ID App Registration som har tilgangen delegated ConfigurationMonitoring.Read.All.

Ved hjelp av svært få timer kan man ved hjelp av vibbekoding få erstatta masse manuell knoting med Graph API endepunkt med en fullverdig webapplikasjon – nydelig! 😍

💪 Veien videre for UTCM

Her er noen planlagte endringer som jeg har plukka opp ymse steder på nettet:

• Push konfigurasjonsendringer fra UTCM
• Automatisk tilbakejustering ved konfigurasjonsdrift
• Graph API Notifications (f.eks. når en jobb fullføres)
• Monitor kan konfigueres til å kjøre i intervallene 1, 2, 6, 12 eller 24 timer

🧐 Konklusjon

UTCM er en ganske etterlengta løsning fra Microsoft for å håndtere konfigurasjonsdrift. Tidligere har man måttet ty til tredjepartsløsninger eller PowerShell DSC for å oppnå noe tilsvarende. Men nå får man det altså rett ut av boksen (Graph API) fra Microsoft selv.

Selv om løsningen er en forhåndsversjon så er den ganske nyttig om man får implementert den på en god måte. Et minimum som man bør sørge for selv er varsling når det oppstår konfigurasjonsdrift. Siden alt bygger på Graph API så er ikke det noe særlig stort problem å løse.

Blir spennende å se hvordan løsninga utvikler seg videre! 😍💪