DigitalForensics

70 13 63 23

Privilegerede roller: tildelinger og ændringshistorik i Entra ID

Privilegerede roller: tildelinger og ændringshistorik i Entra ID

Forside › Microsoft 365 og Entra ID: logkilderne · Gennemgået oktober 2026 · Af John Nielsen

Mange undersøgelser ender med spørgsmålet: Hvem havde rettighederne til at gøre det her, og hvornår fik de dem? Det gælder, når en administrator er under mistanke, når en kompromitteret konto pludselig kunne ændre politikker, og når en revision skal vise, at adgangen til de mest følsomme funktioner var styret. I Microsoft Entra ID kan rettigheder komme fra direkte rolletildelinger, fra tidsbegrænsede aktiveringer, fra medlemskab af grupper og fra rettigheder givet til apps. Historikken skal stykkes sammen fra flere kilder, og den nuværende tilstand siger lidt om fortiden.

Haster det? PIM’s egen visning af historikken dækker kun de seneste 30 dage, og ældre tildelinger skal derfor findes, mens de stadig ligger i auditloggen. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.

Virksomhedens håndtering af mistanke mod en IT-administrator er beskrevet på bevissikring-digitalt.dk. Her ser vi på, hvordan rollehistorikken rekonstrueres teknisk. Den samlede tekniske undersøgelse af en administrator står i Undersøgelse af en administrator, der kan slette loggen.

Fire veje til privilegier

  • Direkte, aktiv rolletildeling · Brugeren har rollen permanent eller i en fast periode
  • Berettiget tildeling med aktivering · Brugeren kan selv aktivere rollen i et tidsrum, evt. med godkendelse og begrundelse
  • Medlemskab af en rolletildelbar gruppe · Gruppen har rollen, og alle medlemmer arver den
  • App-rettigheder · En app eller serviceprincipal har rettigheder, der svarer til administratorrettigheder

Den anden vej kræver en licens, der omfatter administration af privilegerede identiteter; på tidspunktet for gennemgangen (oktober 2026) Entra ID P2 eller Entra ID Governance. Udløber licensen, fjernes berettigede tildelinger ifølge Microsoft, mens permanente bliver, hvilket kan forklare pludselige ændringer i rollebilledet. PIM’s egen visning af historikken dækker de seneste 30 dage. Uden den licens er alle tildelinger direkte, og historikken findes kun i den almindelige auditlog.

Rollerne kan desuden være afgrænset til et område, fx en administrativ enhed eller en bestemt app. En bruger med en afgrænset rolle har ikke rettighederne i hele tenanten, og afgrænsningen skal fremgå, når det vurderes, hvad brugeren kunne gøre.

Andre rollesystemer ved siden af

Entra-rollerne er ikke de eneste. Exchange Online har sine egne rollegrupper, Azure-abonnementer har deres egen rollebaserede adgangsstyring, og et lokalt Active Directory har sine administrative grupper, der kan give adgang til Entra via synkronisering og hybride funktioner. En fuld kortlægning af, hvem der kunne hvad, skal omfatte de systemer, der er relevante for sagen. Lokale domænegrupper og deres logs er beskrevet i Active Directory og domænecontroller-logs.

Nuværende tilstand

Start med et øjebliksbillede: alle aktive tildelinger, alle berettigede tildelinger, medlemmer af rolletildelbare grupper og apps med højt privilegerede rettigheder. Hent dem i fuld form via Graph eller PowerShell med tidspunkter for start og eventuel udløb, og hash eksporten. Øjebliksbilledet viser, hvem der har rettighederne nu, og dermed hvem der kunne have ændret noget siden hændelsen.

Historikken

Ændringer i rolletildelinger registreres i auditloggen som tilføjelse og fjernelse af medlemmer i roller og grupper, og for berettigede tildelinger som anmodninger, godkendelser og aktiveringer med begrundelse og varighed. Ved gennemgangen hed aktiviteterne fx Add member to role, Remove member from role, Add member to role completed (PIM activation), Add eligible member to role in PIM completed og Add member to group; uden for PIM findes også Add member to role outside of PIM. For hver post findes den initierende konto, målet, rollen og tidspunktet.

Ud fra posterne bygges en rolletidslinje pr. konto: hvornår blev rollen tildelt eller aktiveret, hvornår udløb eller blev den fjernet, og af hvem. Aktiveringer er særligt nyttige, fordi de ofte har en begrundelse, en varighed og eventuelt en godkender. En aktivering umiddelbart før en mistænkelig ændring og en deaktivering lige efter er et mønster, der kan tale både for og imod mistanken; begrundelsen kan forklare den.

Auditloggens opbevaring er begrænset. Ligger tildelingen længere tilbage, kan tidspunktet nogle gange aflæses af selve tildelingsobjektet, men en fjernet tildeling efterlader intet objekt. Har organisationen sendt auditloggen til et eget logarkiv, er historikken længere.

Grupper og indirekte rettigheder

Medlemskab af en rolletildelbar gruppe giver rollen, uden at det fremgår af rollens direkte medlemsliste. Undersøg derfor både rolletildelinger og gruppemedlemskaber, og vær opmærksom på, at gruppens ejere kan tilføje medlemmer. Rettigheder kan også opnås ved at blive ejer af en app med højt privilegerede rettigheder og tilføje egne legitimationsoplysninger til den. Den vej kræver ikke en rolle til brugeren og overses let; se OAuth-apps og samtykke-phishing.

Administratorer, der kan ændre logningen

En administrator med de højeste rettigheder kan ændre indstillinger for logning og opbevaring og kan i nogle tilfælde fjerne andre spor. Ændringerne registreres selv, men det er grunden til, at en undersøgelse af en administrator bør bygge på logs, administratoren ikke selv kontrollerer, og udføres af en anden identitet end administratorens. Metoden er beskrevet i Undersøgelse af en administrator, der kan slette loggen.

Mønstre efter kompromittering

  • En ny konto oprettes og får en administratorrolle.
  • En eksisterende konto tilføjes en rolletildelbar gruppe.
  • En app får nye legitimationsoplysninger eller nye app-rettigheder.
  • En berettiget tildeling ændres til permanent.
  • Godkendelseskrav for aktivering fjernes.

Sådanne ændringer kan være angriberens måde at sikre adgang på længe efter den oprindelige konto er lukket. Den samlede metode til at finde og dokumentere den slags spor er beskrevet i Bagdøre efter en administrator.

Nødadgangskonti

De fleste organisationer har en eller to konti til nødadgang med permanente globale rettigheder og særlige undtagelser fra politikker. Skal en kurator overtage administrationen, se Konkursboets IT. Brug af dem bør være sjælden og dokumenteret. Logins og ændringer fra en nødadgangskonto i perioden er et vigtigt fund, uanset om de viser sig at være legitime.

Fremgangsmåde

  1. Afgræns spørgsmålet: Hvilken handling skal forklares, og hvilke rettigheder krævede den? Microsofts dokumentation af rollernes tilladelser viser, hvilke roller der kunne udføre den.
  2. Sikr øjebliksbilledet af tildelinger, berettigelser, rolletildelbare grupper og privilegerede apps.
  3. Eksportér auditloggen for hele den tilgængelige periode, filtreret på rolle-, gruppe- og apphændelser, og gem også den ufiltrerede eksport.
  4. Byg rolletidslinjen for de konti, der kunne udføre handlingen på tidspunktet.
  5. Kobl til logins: For de konti, der havde rettighederne, gennemgås loginloggen omkring handlingens tidspunkt, så det kan ses, hvilken session der udførte den, og om den blev godkendt med en metode, der var registreret kort forinden; se MFA-ændringer og betinget adgang i Entra ID-loggene.
  6. Kontrollér ændringer af logning og opbevaring i samme periode.

Rækkefølgen sikrer, at undersøgelsen ikke kun ser på den konto, der er under mistanke, men på alle, der kunne have gjort det. Det er vigtigt for uvildigheden, og det er ofte dér, den alternative forklaring findes.

Typiske fejlkilder

  • Kun direkte tildelinger gennemgået: Grupper, aktiveringer og app-rettigheder overses.
  • Nuværende tilstand antages at gælde bagud.
  • Afgrænsede roller læses som globale.
  • Serviceprincipaler forveksles med personer: En ændring udført af en automatisering kan stå i loggen med appens navn.
  • Tidszone: Auditloggen er i UTC.

Hvad historikken kan og ikke kan bevise

Rollehistorikken kan vise, hvilke konti der havde hvilke rettigheder på et bestemt tidspunkt, og hvem der gav dem. Det er ofte afgørende for, om en bestemt konto overhovedet kunne have udført en handling. Den viser ikke, at kontoen faktisk udførte handlingen; det kræver revisionsposten for selve handlingen. Og den viser ikke, hvem der betjente kontoen.

Dokumentation

Rapporten bør indeholde øjebliksbilledet af alle privilegerede tildelinger med hashværdier, rolletidslinjen for de relevante konti med kildehenvisning til hver post, de licenser og logarkiver, der bestemmer historikkens længde, og en klar angivelse af perioder, hvor historikken ikke kan rekonstrueres. Til revisionsformål kan den samme metode bruges til at dokumentere, at adgangen var styret; se For IT-revision og DPO’er.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: Registrerede enheder i Entra ID som vedvarende adgang · Adgang til andres postkasser: FullAccess, SendAs og delegering i auditloggen

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.