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.

Ulrich Bojko
Udviklingschef

The post Udfasningen af memberOf i Entra: Dine grupper går ikke i stykker – de fryser fast appeared first on Strator.

Denne skelnen er vigtigere nu end nogensinde før, fordi de strategiske indsatser er reelle, og markedsføringen omkring dem er højlydt. To nylige og omfattende undersøgelser hjælper med at skære igennem støjen: Digitaliseringsstyrelsens rapport fra december 2025 om open source i den offentlige sektor og en international undersøgelse af seksten digitalt modne lande, som Digitaliseringsstyrelsen bestilte året før. Læst i sammenhæng peger de på den samme ubehagelige men nyttige konklusion. Digital suverænitet er en formåen, og formåen skal opbygges. 

Suverænitet er ikke et produkt du kan købe 

Det er fristende at tro, at en bestemt type platform afgør spørgsmålet. Det gør den ikke. Man kan være reelt uafhængig på en proprietær platform, hvis man har en god styring, og fuldstændig fanget i open source, hvis man ikke har det. Mærket på emballagen betyder meget lidt. Organisationen bag den afgør næsten alt. 

De store udbydere er selv et godt eksempel på dette. I løbet af det seneste år har Microsoft færdiggjort sin EU Data Boundary og indført suverænitetsløsninger såsom krypteringsnøgler, der opbevares hos kunden, adgangskontrol baseret i Europa og lokal implementering af centrale arbejdsbelastninger – alt sammen med direkte fokus på suverænitetshensyn. Det er betydelige investeringer, og de gør det muligt at opnå digital suverænitet på en hyperscale-kommerciel cloud på en måde, der ikke var mulig for blot få år siden. Samtidig er der stadig uafklarede spørgsmål, såsom udenlandsk lovgivnings rækkevidde over data, der fysisk er lagret i Europa, hvilket ingen indkøbsbeslutning i sig selv fuldt ud kan fjerne. Læren er ikke, at én udbyder er sikker, og en anden ikke er det. Læren er, at uanset hvad man vælger, overgår ansvaret for at forstå, hvad man besidder, hvor det befinder sig, og hvordan man ville afhænde det, hvis det blev nødvendigt, ikke til leverandøren. Det forbliver hos dig. 

Så det egentlige spørgsmål er aldrig »hvilken platform giver os digital suverænitet«. Det er »forstår vi vores konfiguration, ejer vi vores data, kender vi vores kontrakter, og har vi en økonomisk bæredygtig måde at skifte kurs på«. Det er organisatoriske egenskaber, ikke produktegenskaber. 

Kontrol og ansvar er én og samme beslutning 

Digitaliseringsstyrelsens rapport fra 2025 taler klart om den handel, som ingen bryder sig om at nævne. Når du får større kontrol over din teknologi, påtager du dig også et større ansvar: licensbetingelser, sikkerhedsopdateringer, support, maintenance og ganske enkelt at vide, hvad du arbejder med. Kontrol er ikke en præmie, man modtager. Det er en arbejdsbyrde, man påtager sig. Rapporten undgår omhyggeligt at hævde, at mere åbenhed altid er bedre; den siger tværtimod det modsatte. Træf valg ud fra den værdi, de tilfører, og vær ærlig om, hvorvidt du kan gennemføre det, du har valgt. 

Danmark oprettede et særligt open source-kontor til sundhedssektoren. Selvom det var teknisk højt anset, gik det alligevel i opløsning. Ikke på grund af kodens kvalitet, men på grund af manglende organisatorisk og økonomisk opbakning. Teknisk ekspertise er ikke i sig selv nok til at sikre vedvarende operationel opbakning. Det gør finansiering, ejerskab og lederskab derimod. Især lederskab. Det samme mønster viser sig omvendt, hvor suverænitet lykkes. Den opretholdes af en organisation med et lederskab, der har besluttet at afsætte ressourcer til den, ikke af en licens, der tilfældigvis tillod det. 

Derfor kæmper de mindste organisationer mest, og hvorfor svaret sjældent er en heroisk genopbygning internt. Duelighed er krævende netop fordi det er rigtigt arbejde, og at lade som om en platform fjerner det arbejde er hvordan afhængighed stille og roligt hober sig op. 

Forudsætningerne er det sted, hvor suveræniteten egentlig opbygges 

Hvis digital suverænitet er en duelighed, bliver det praktiske spørgsmål, hvad denne duelighed består af. Digitaliseringsstyrelsens rapport, der bygger på erfaringer fra offentlige myndigheder i Danmark og i udlandet, opstiller en klar og fordelsagtigt neutral leverandørliste over forudsætninger. Disse forudsætninger gælder i lige så høj grad for proprietær software som for open source. 

Den første forudsætning er organisation og ledelse. Nogen skal stå bag beslutningen, formulere begrundelsen for den og investere i den kompetence, der skal til for at gennemføre den, uanset om denne kompetence opbygges internt eller købes. Den anden er en bevidst beslutning om support og maintenance. Der er behov for det, uanset om softwaren er open source eller ej. Al software har brug for support og maintenance, og det ville være en fejl at lade den stå uden ejerskab. Den tredje forudsætning er evnen til at vurdere sikkerhed og modenhed, til at bedømme, om der står et aktivt fællesskab eller en kompetent leverandør bag en komponent, i stedet for at antage, at en licens garanterer det. Den fjerde forudsætning er et reelt overblik over licenser, kontrakter og data; at vide, hvilke vilkår der binder dig, hvor dine oplysninger befinder sig, og hvad dine aftaler rent faktisk siger. Det femte punkt er open standards og integration, så systemerne kan kommunikere med hinanden, og – hvad der er afgørende – så man senere kan skifte leverandør uden at skulle afmontere det hele. Det sidste punkt er en honest lifetime economics, hvor man sammenligner en løsnings samlede omkostninger i stedet for den angivne pris, fordi værdien af at kunne skifte aldrig fremgår af en faktura. 

Ingen af disse forudsætninger er tekniske kneb. De er alle discipliner. Tilsammen udgør de det, som digital suverænitet reelt består af, og det opmuntrende er, at de kan udvikles bevidst. 

Organisationer behøver ikke at stå alene  

Organisationer behøver ikke at erhverve evnen til at udøve digital suverænitet på selvstændig vis, og de mest udviklede lande har indset dette. Det gennemgående mønster i den internationale undersøgelse er fremkomsten af fælles forvaltning: neutrale organisationer, der har denne formåen på vegne af mange. I Danmark giver OS2-fællesskabet kommunerne mulighed for at samle midler og kompetencer med fælles løsninger, ud fra princippet om, at de, der er afhængige af noget, bidrager til at opretholde det og bevarer muligheden for at skifte leverandør. Estland og Finland gik så langt som til at oprette en fælles institution med personale og et budget, udelukkende med det formål at forvalte den software, de deler. Italien har oprettet et statsligt kontor til at vejlede og støtte indførelsen af open source, Tyskland har etableret både et offentligt organ til at udvikle fælles løsninger og et agentur til at finansiere vedligeholdelsen af kritisk open source, og Den Europæiske Union er i færd med at sammensætte fælles byggesten, som flere lande kan trække på. 

Det afgørende er ikke, hvilken model der vinder, men, at hver enkelt af dem betragter duelighed som noget, der skal finansieres, bemandes og deles, snarere end noget, der tages for givet. Digital suverænitet i stor skala er lige så meget en kollektiv disciplin som en individuel. 

Digital suverænitet er en ledelsesmæssig holdning 

Alt dette fører tilbage til ét enkelt punkt, og det er et punkt, som CTO’en og CIO’en skal tage ansvaret for. Ledelsen, nærmere bestemt CIO’en og/eller CTO’en, er dem, der skal træffe beslutninger om digital suverænitet. Det er vigtigt, at de gør dette allerede under selve indkøbsprocessen. Datalokalisering, mulighed for at skifte leverandør, open standards og klarhed omkring kontrakter bør ikke være eftertanker, der først kommer frem, når en platform allerede er valgt. De hører som standard til kravene, der gælder for alle leverandører, uanset hvem de er. Behandlet på den måde bliver digital suverænitet beslutningen om at tage ansvar for sin egen infrastruktur, at vide, hvad man kører og hvorfor, samt bevidst at holde sine muligheder åbne. 

De mest holdbare eksempler er governed, ikke improviseret. Aarhus blev for eksempel ikke mere digitalt uafhængigt ved blot at skifte til et andet produkt. Byen fastlagde en retning over mange år – fra et krav om at overveje alternativer, over en handlingsplan og en digital strategi, til afsatte budgetmidler med henblik på at udvide udvalget af leverandører. Den røde tråd er ikke en teknologi. Det er vedvarende, værdidrevet governance og en afvisning af at lade andre bestemme tempoet som udgangspunkt. Det langvarige princip bag det er værd at huske: Vælg den bedste og mest økonomiske løsning uanset softwaretype. Disse løsninger skal vælges af en organisation, der forstår, hvad den vælger. 

Det er netop denne formåen, vi opbygger hos Strator. Platformen er jeres uanset om den er kommerciel eller open source, i skyen eller on-premises. Det egentlige spørgsmål er, om I kan styre den, og om I kan forlade den, hvis I nogensinde bliver nødt til det. Digital suverænitet er ikke blot en sætning i kontrakten; det er bevidstheden om, at organisationen kender sin situation og har evnen til at migrere, hvis den vælger det.  

The post Digital suverænitet er ikke en licens. Det er en formåen. appeared first on Strator.

The post Hvad er digital suverænitet – når vi taler dokumenter? appeared first on Strator.