Regeloperatoren memberOf i Microsoft Entra ID stopper med at blive evalueret efter den 3. november 2026, og fejltilstanden er tavshed. Dynamiske medlemskabsgrupper, dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management, der bruger den, vil hverken give en fejl eller forsvinde. De vil ganske enkelt fastholde deres medlemskab, som det så ud den 3. november, for altid. Det betyder, at medarbejdere, der forlader organisationen, beholder deres adgang, mens nye medarbejdere aldrig får den.

Et nedbrud bliver opdaget på få minutter. En fastfrosset adgangsmodel bliver først opdaget ved en audit.

Her er, hvad du bør gøre inden den 3. november.

Hvad gjorde memberOf egentlig?

Preview-funktionen gjorde det muligt for en dynamisk gruppe at hente medlemmerne fra andre grupper:

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])

Det var det tætteste, Entra ID kom på indlejrede grupper, som downstream-tjenester kunne læse. Organisationer brugte funktionen til at flade et gruppehierarki ud til en struktur, som SharePoint, Teams, Conditional Access og gruppebaseret licensering kunne bruge, fordi indlejrede grupper aldrig har fungeret problemfrit med disse tjenester.

Microsofts angivne årsag til at udfase funktionen er skala. Under previewen blev det observeret, at memberOf kunne forsinke behandlingen af dynamisk medlemskab i en hel tenant – ikke kun for de grupper, der brugte funktionen.

Der kan være en alternativ løsning under udvikling, men der er endnu ikke noget nyt på vej ud.

Hvad går i stykker, og hvor mærker du det først?

Det fastfrosne medlemskab forplanter sig til alt det, der afhænger af gruppen:

• Adgang til SharePoint og Teams. Medarbejdere, der forlader organisationen, beholder adgangen til sites og kanaler. Nye medarbejdere får den aldrig.
• Targeting i Conditional Access. Nye medarbejdere falder uden for en politik, som de burde være omfattet af. Din MFA- eller enhedsoverholdelsespolitik holder dermed stille og roligt op med at dække dem.
• Gruppebaseret licensering. Nye medarbejdere får ikke tildelt licenser. Medarbejdere, der forlader organisationen, fortsætter med at optage licenser, som du betaler for.
• Access packages. Automatiske tildelingspolitikker holder op med både at tildele og fjerne adgange, så en tidsbegrænset adgang i stilhed bliver permanent.
• Dynamiske administrative enheder. Det delegerede administrationsscope begynder at afvige fra organisationsstrukturen.

For regulerede organisationer er der et yderligere problem. Hvis jeres procedure for adgangskontrol siger, at medlemskab vedligeholdes automatisk af en attributbaseret regel, og den regel i stilhed er holdt op med at blive evalueret, er der ikke længere overensstemmelse mellem den dokumenterede proces og systemets faktiske tilstand.

Det er en audit finding, og den kan være svær at afgrænse bagefter. I skal kunne dokumentere, hvem der havde adgang til hvad – og hvor længe.

Hvilke dele af din tenant glemmer folk at kontrollere?

Næsten alle kontrollerer dynamiske grupper. Der er to andre steder, hvor memberOf-regler kan gemme sig, og som næsten ingen kontrollerer:

• Dynamiske administrative enheder. De bliver konfigureret én gang af en person på identity-teamet og derefter aldrig rørt igen. De er heller ikke synlige under et almindeligt adgangseftersyn. Når en sådan enhed fryser fast, holder det delegerede administrationsscope op med at følge organisationsstrukturen.
• Automatiske tildelingspolitikker i Entitlement Management. Reglen ligger i politikkens konfiguration af tilladte mål i stedet for på selve gruppeobjektet. Derfor vil en eksport, der kun fokuserer på grupper, overse den fuldstændigt.

Begge dele kræver Microsoft Graph for at kunne enumereres korrekt. Ingen af dem dukker op, hvis du kun søger under Groups i administrationscenteret.

Den detalje, næsten alle overser: Nogle af dine medlemskaber er allerede frosset fast

Her er den opdagelse, der ændrer, hvordan du bør prioritere arbejdet – og den kommer direkte fra de dokumenterede begrænsninger ved preview-funktionen.

memberOf fjernede aldrig medlemmer, når en kildegruppe blev slettet, eller når et medlem blev fjernet fra en kildegruppe. Dokumentationen siger det direkte: Berørte brugere forbliver medlemmer af memberOf-gruppen, indtil reglen ændres.

Hold det op mod udfasningen. Det betyder, at fastfrysningen den 3. november ikke er starten på jeres drift. Hvis en kildegruppe, der refereres til i en af jeres regler, er blevet slettet eller har fået fjernet medlemmer, er noget af jeres adgang allerede forældet i dag – og har været det, lige så længe kildegruppen har været væk eller medlemmet har været fjernet.

Det er derfor, en memberOf-gennemgang bør identificere hvert eneste kildegruppe-ID i hver regel og kontrollere, om gruppen stadig findes.

Et kildegruppe-ID, der ikke kan opløses, er ikke bare et irriterende datakvalitetsproblem. Det er et tegn på adgang, der på et tidspunkt er holdt op med at afspejle virkeligheden.

Og det er præcis den slags, du helst selv vil opdage, frem for at få det påpeget under en audit.

Hvordan beslutter du, hvad du skal gøre med hver regel?

Der er tre ærlige udfald – og et fjerde, som folk helst undgår at sætte navn på.

Omskriv reglen ved hjælp af understøttede operatorer. Hvis kildegrupperne svarer til en reel attribut, såsom afdeling, stillingsbetegnelse, virksomhedsnavn eller en extension attribute, kan du udtrykke reglen direkte ud fra denne attribut.

Det kan være det bedste udfald, og det tvinger ofte organisationen til endelig at tage den samtale om kvaliteten af HR-data, som burde have været taget for længe siden.

Konverter til tildelt medlemskab. Fastfrys medlemskabet bevidst, og administrer det gennem jeres joiner/mover/leaver-proces. Det er kedeligt, auditerbart og ærligt omkring, hvem der ejer listen.

Slet reglen. En betydelig del af grupperne fra preview-perioden viser sig ikke at blive brugt til noget.

Accepter, at nogle grupper har brug for et dynamisk medlemskab. Det er den løsning, folk ofte springer over. Hvis en gruppes medlemskab udelukkende består af alle medlemmerne fra andre grupper, findes der ingen attribut, der kan udtrykke det. Hvis medlemskabet samtidig skal holdes løbende opdateret, er tildelt medlemskab ikke en migration.

Hvordan tester du en omskrivning, før du implementerer den?

Du ønsker både coverage og precision på 100 %, men de fleste migrationsplaner holder kun øje med coverage.

Coverage er andelen af de nuværende medlemmer, som den foreslåede regel stadig inkluderer. Coverage under 100 % betyder, at nogle personer mister adgang, når ændringen implementeres. Det hører du om samme morgen.

Precision er andelen af den population, som den foreslåede regel inkluderer, og som faktisk er medlem i dag. Precision under 100 % betyder, at nogle personer får adgang, når ændringen implementeres.

Ingen rapporterer om det. Og det er præcis derfor, det er den farlige af de to.

En regel med 100 % coverage og 80 % precision ser ud som en problemfri migration på dagen – men bliver til en stille over-tildeling af adgang, som fortsætter for altid.

Da vi udviklede vores eget analyseværktøj, gjorde vi precision til den blokerende tærskel i stedet for coverage. Værktøjet vil ikke foreslå en omskrivning, der udvider adgangen, men det foreslår gerne en, der efterlader dig med en navngiven liste på otte personer, som manuelt skal tilføjes igen.

En kort manuel opgave er bedre end en usynlig udvidelse af rettigheder.

Uanset hvordan du beregner værdierne, bør du validere den foreslåede regel i Entra-portalen, før du implementerer den, og sammenligne medlemskabet før og efter.

En tilgang i 3 trin

Trin 1: Find alle anvendelser.

Eksportér dynamiske grupper, og søg efter memberOf i reglerne. Gør det samme for dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management via Graph.

For hvert fund skal du registrere, hvad der bruger gruppen: sites, teams, Conditional Access-politikker, licenstildelinger, access packages osv.

Migrationsrisikoen ligger i de systemer og funktioner, der bruger gruppen – ikke i selve gruppeobjektet.

Hvis du vil være sikker på, at du får det hele med, og har brug for hjælp, så kontakt os for en gratis vurdering.

Trin 2: Beslut dig for hver gruppe.

Husk den begrænsning, der oprindeligt fik folk til at bruge memberOf: Funktionen kunne ikke kombineres med andre regler eller operatorer.

En omskrivning er derfor sjældent en direkte oversættelse én til én. Det er en mulighed for at udtrykke den oprindelige intention korrekt.

Trin 3: Validér og dokumentér.

Sammenlign medlemskabet før og efter, bekræft, at de downstream-systemer og -funktioner, der bruger grupperne, stadig fungerer korrekt, og dokumentér ændringen.

Under GxP, NIS2 eller DORA er dokumentationen af valideringen selve leverancen.

Læg en buffer ind inden den 3. november. Du ønsker ikke, at den sidste gruppe bliver migreret på den sidste dag.

Arbejder du med memberOf-grupper i et reguleret miljø?

Vi gennemfører en read-only-vurdering af din tenant og giver dig et register, en anbefaling for hver gruppe samt en valideringsplan.

Kontakt os for at høre mere.