Indlejrede grupper i Entra ID laver ballade i SharePoint

Hvis du bruger indlejrede grupper i Entra ID, altså grupper, der er medlemmer af andre grupper, kommer du hurtigt ud for problemer med rettigheder. En bruger i den inderste gruppe kan åbne webstedet i SharePoint, men får ikke appen, licensen eller pladsen i teamet. Eller også får vedkommende det hele, men først næste dag. Det virker nogle gange og andre gange slet ikke.

Det skyldes, at Entra ID ikke selv afgør, hvad en gruppe i en gruppe betyder. Det gør hver tjeneste, der bruger gruppen, og de gør det forskelligt. Samtidig er den genvej, Microsoft selv har tilbudt, dynamiske grupper med memberOf, ved at blive lukket. Efter den 3. november 2026 bliver de grupper ikke længere opdateret.

Hvad en indlejret gruppe er#

I Entra ID kan en sikkerhedsgruppe være medlem af en anden sikkerhedsgruppe. Microsoft kalder det nested groups. Er gruppen Salg Vest medlem af Salg, er brugerne i Salg Vest indirekte medlemmer af Salg. Det kender alle, der har arbejdet med Active Directory, og det er derfra, vanen kommer.

I Entra ID har indlejringen grænser fra starten (Microsoft):

• Kun sikkerhedsgrupper. En Microsoft 365-gruppe kan ikke have andre grupper som medlemmer og kan ikke selv være medlem af en sikkerhedsgruppe.
• Ikke i synkroniserede grupper. En gruppe, der kommer fra det lokale Active Directory via synkronisering, kan ikke få grupper tilføjet i Entra ID.
• Ikke med mail. Distributionsgrupper kan ikke indgå, og en sikkerhedsgruppe kan ikke være medlem af en mailaktiveret sikkerhedsgruppe.
• Ikke i rollegrupper. En gruppe, der kan tildeles administratorroller, kan ikke have grupper som medlemmer.

På samme side står den sætning, der forklarer det meste af balladen: indlejrede grupper får ikke adgang til de delte ressourcer og programmer, der er tildelt den overordnede gruppe. Det, Entra ID tillader, er altså ikke det samme som det, resten af Microsoft 365 respekterer.

Hvem der tæller medlemmerne under gruppen med#

Microsoft har en liste over, hvor indlejrede grupper virker, og hvor de ikke gør (Microsoft). Med et par tjenester mere ser billedet sådan ud:

Tildelingen af apps er den, flest falder over. Microsoft skriver det direkte i vejledningen: når en gruppe tildeles en app, får kun brugerne i gruppen adgang, og tildelingen gælder ikke for grupper inde i den (Microsoft). En app, hvor Assignment required er slået til, afviser derfor brugeren i Salg Vest, selv om Salg er tildelt.

I Power Platform bliver medlemmer af en indlejret gruppe først oprettet i miljøet, når de logger på første gang, og de kan ikke bruge data i Dataverse, før de får en sikkerhedsrolle (Microsoft). Og Office 365 Groups-connectoren giver kun de direkte medlemmer, som jeg skrev i En gruppes medlemmer i en Power App.

SharePoint: det virker efter alt at dømme, men Microsoft lover det ikke#

Rettigheder i SharePoint Online, der gives til en sikkerhedsgruppe fra Entra ID, er den del, hvor indlejring oftest regnes for at virke, og den gør, at mange tror, at indlejring virker overalt. Men der findes ingen Microsoft-side, der med rene ord skriver, at en bruger i en gruppe i en gruppe får adgang til et websted. Det, der findes, er indirekte tegn og en frarådning.

Tegnene:

• Grænsen for SharePoint tæller indirekte medlemskab med: en bruger kan være med i op til 2.047 sikkerhedsgrupper i alt, direkte og indirekte, før login og søgeresultater bliver uforudsigelige (Microsoft).
• Et svar på Microsoft Q&A fra 8. februar 2022, markeret som godkendt, skriver, at en sikkerhedsgruppe i en sikkerhedsgruppe kan lægges ind i webstedets rettigheder, og at begge gruppers medlemmer så får adgang (Microsoft Q&A). Det er et forumsvar og ikke dokumentation.
• En åben pull request i PnP Core SDK fra 21. september 2026 beskriver, at en bruger kan høre til en SharePoint-gruppe gennem en indlejret Entra-gruppe uden at stå i den. SharePoints eget opslag viser kun de direkte medlemskaber, så indirekte medlemmer er usynlige for scripts (GitHub).
• Restricted site access control tæller indirekte medlemmer med ved deling, som beskrevet nedenfor.

Frarådningen står på Microsofts side om deling og rettigheder i SharePoint. Om kommunikationswebsteder skriver den, at indlejrede sikkerhedsgrupper kan give problemer med ydelsen og ikke anbefales (Microsoft). Siden siger ikke, at det ikke virker, og den siger heller ikke, hvad problemerne består i.

Et klart nej findes der ikke heller. Entra-siden skriver, at indlejrede grupper ikke får adgang til de delte ressourcer og programmer, der er tildelt den overordnede gruppe, og de ord er brede nok til, at de kan læses som et nej til SharePoint. Sætningen nævner dog ikke SharePoint. Et spørgsmål på Microsoft Q&A fra januar 2025 om indlejrede grupper, der er synkroniseret fra det lokale Active Directory, fik fra en MVP kun et link til siden med grænserne og hverken et ja eller et nej (Microsoft Q&A).

Hvad der er dokumenteret, og hvad der er erfaring, er altså ikke det samme, og det forklarer, at to personer med hver sin test kan komme til hver sin konklusion.

Problemerne kommer tre steder.

Websteder, der hører til en gruppe. Et teamwebsted får sine ejere og medlemmer fra Microsoft 365-gruppen, og den kan ikke indeholde andre grupper. En afdelings sikkerhedsgruppe kan godt lægges direkte i webstedets SharePoint-gruppe Medlemmer. Så får afdelingen adgang til filerne, men ikke til teamet, gruppens postkasse eller Planner, fordi medlemmerne ikke står i Microsoft 365-gruppen. To brugere, der har samme adgang til dokumenterne, ser to forskellige ting i Teams.

Arv og brudt arv. Rettighederne på et bibliotek, en mappe eller en fil viser gruppen, ikke personerne. Hvem der står i gruppen, og i grupperne under den, står i Entra ID. Hver mappe med egne rettigheder er et sted mere, hvor en gruppe skal foldes ud for at se, hvem der faktisk har adgang. Med to lag grupper og et par hundrede brudte arv er det ikke længere noget, nogen kan svare på uden et script. Hvad brudt arv koster i sig selv, står i Rettigheder flyttes ikke, de oversættes og Unikke rettigheder på en mappe i SharePoint.

Deling og begrænset adgang. Med Restricted site access control fra SharePoint Advanced Management kan et websted begrænses til medlemmerne af bestemte grupper. Når deling uden for grupperne er slået fra, må et SharePoint-websted nu deles med indlejrede sikkerhedsgrupper i kontrolgrupperne (Microsoft). For OneDrive skriver Microsoft, at det endnu ikke kan lade sig gøre (Microsoft). Det er den samme indstilling og to forskellige svar.

Derfor virker det nogle gange#

At det virker for nogle brugere og ikke for andre, har flere årsager, og de kan optræde på samme tid.

Tjenesten afgør det. Det første er tabellen ovenfor. En bruger med adgang til webstedet i SharePoint har ikke nødvendigvis adgang til appen, der bruger samme gruppe. Fejlen ligger ikke hos brugeren, men i at to tjenester læser gruppen forskelligt.

For mange grupper i tokenet. En app, der får brugerens grupper i tokenet, får dem med de indirekte medlemskaber regnet med. Men der er et loft: 200 grupper i et JWT og 150 i et SAML-token. Er brugeren med i flere, sender Entra ID ingen grupper, men en besked om, at listen skal hentes i Microsoft Graph (Microsoft). En app, der ikke henter listen, ser brugeren som medlem af ingen grupper. Indlejring får antallet til at vokse, så det rammer netop de brugere, der står mange steder: ledere, administratorer og folk, der har været i organisationen længe. Vælger appen kun at få de grupper, der er tildelt appen, kommer indlejrede grupper slet ikke med (Microsoft).

Ventetid. En ændring i en gruppe slår ikke igennem med det samme alle steder. Rights Management i Purview gemmer gruppemedlemskab i op til tre timer (Microsoft), og når rollen som SharePoint-administrator aktiveres gennem en gruppe i Privileged Identity Management, kan der gå op til 24 timer, før den virker i SharePoint (Microsoft). En test lige efter ændringen siger derfor ikke meget.

I SharePoint selv er ventetiden ikke dokumenteret. Microsoft angiver ikke, hvor længe der går, fra en gruppe ændres i Entra ID, til ændringen kan mærkes på et websted, og en deltager i en tråd på Tech Community skrev i august 2020, at der ikke findes en side, der gør det. Det, der findes, er enkeltstående erfaringer: op til tre timer i den tråd (Tech Community), op til 24 timer, før en ny sikkerhedsgruppe kunne vælges i SharePoint, i et svar fra oktober 2020 (Microsoft Q&A), og i december 2022 et svar fra en Microsoft-medarbejder om, at det kan tage “nogle gange få timer, nogle gange få dage”, selv om vedkommendes egen test tog en halv time (Microsoft Q&A). Spørgeren i den sidste tråd havde ikke indlejrede grupper. Ventetiden rammer altså også almindelige grupper, og indlejring er ikke nødvendig for at se den.

Synkroniserede grupper. En gruppe, der kommer fra det lokale Active Directory, kan ikke få grupper tilføjet i Entra ID. Om indlejringen i det lokale Active Directory følger med ved synkroniseringen, skriver Microsoft ikke. De ældste rapporter om, at indlejring ikke virker i SharePoint Online, handler om netop dette. I en tråd på Tech Community fra september 2016 til april 2017 fik brugere med globale grupper indlejret i lokale grupper kun Limited Access, og et svar fra april 2017 lyder, at man ikke kan bruge grupper i grupper i SharePoint Online, “at least not reliably” (Tech Community). Det er næsten ti år gammelt og viser ikke, hvordan det virker i dag.

Dynamiske grupper med memberOf. Den sidste årsag er den, Microsoft nu fjerner.

Microsoft lukker memberOf#

Siden 2022 har Entra ID haft en prøveudgave af reglen memberOf i dynamiske grupper. En dynamisk gruppe med reglen samler medlemmerne af andre grupper i én gruppe:

user.memberof -any (group.objectId -in ['<gruppens objekt-id>'])

Medlemmerne af den dynamiske gruppe er direkte medlemmer, og derfor kan apps og licensering læse dem. Det var Microsofts eget svar på indlejrede grupper, og Microsofts sammenligning af gruppetyper skriver stadig, at Microsoft 365-grupper understøtter indlejring gennem dynamiske grupper (Microsoft).

Den 5. august 2026 meddelte Microsoft i Message Center (MC1448379), at prøveudgaven slutter. Efter den 3. november 2026 holder dynamiske grupper, dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management, der bruger memberOf, op med at blive opdateret. De bliver stående med de medlemmer, de havde (Microsoft). Begrundelsen er, at memberOf kan gøre behandlingen af alle dynamiske grupper i tenanten langsommere. Microsoft skriver, at der arbejdes på et alternativ, men ikke hvornår det kommer. Microsoft nævner selv følgerne: forældet adgang i Teams og SharePoint og huller i betinget adgang, gruppebaseret licensering og adgangspakker.

En frossen gruppe er værre end en, der er slået fra. Den, der forlader afdelingen, beholder adgangen. Den, der kommer til, får ingen. Og ingen får en fejl.

Det er reglen i dynamiske grupper, der lukker, ikke memberOf i Microsoft Graph. Opslag af en brugers grupper, også de indirekte, med transitiveMemberOf virker som før (Microsoft).

Prøveudgaven havde i forvejen sine begrænsninger: højst 500 grupper med memberOf pr. tenant og 50 kildegrupper pr. gruppe, kun direkte medlemmer af kildegrupperne, og en bruger, der blev fjernet fra en kildegruppe, blev stående i den dynamiske gruppe, indtil reglen blev ændret. Microsoft skriver, at den kun bør bruges i testmiljøer.

Grupperne med reglen kan findes med Microsoft Graph PowerShell:

1Connect-MgGraph -Scopes 'Group.Read.All'
2Get-MgGroup -All -Property Id,DisplayName,GroupTypes,MembershipRule |
3    Where-Object { $_.GroupTypes -contains 'DynamicMembership' -and $_.MembershipRule -match 'memberof' } |
4    Select-Object DisplayName, Id, MembershipRule

Scriptet er ikke kørt. Dynamiske administrative enheder og tildelingspolitikker skal findes for sig. Til politikkerne har Microsoft et script, der kun læser, på siden om automatisk tildeling (Microsoft).

Hvad man gør i stedet#

Én gruppe pr. adgang, med direkte medlemmer. Til apps, licenser og teams er det det eneste, der virker hver gang. Gruppen hedder efter det, den giver adgang til, og medlemmerne står i den selv.

Dynamiske grupper på attributter. Afdeling, lokation, jobtitel eller en extensionAttribute, som HR-systemet eller Active Directory fylder ud. Det er Microsofts egen anbefaling til at erstatte memberOf (Microsoft). Det kræver Entra ID P1, og det kræver, at attributterne er rigtige. En forkert afdeling i HR-systemet er så en forkert adgang.

En flad gruppe, som et script vedligeholder. Hvor der virkelig er brug for “alle i de her grupper”, kan et planlagt script hente alle medlemmer med transitiveMembers i Microsoft Graph (Microsoft) og skrive dem som direkte medlemmer i en almindelig gruppe. Det flytter problemet til et job, der skal køre og overvåges, men det er synligt, og det kan læses af alle tjenester.

Indlejring i SharePoint med omtanke. Skal en sikkerhedsgruppe ligge i en sikkerhedsgruppe på et websted, er det efter alt at dømme muligt, men Microsoft fraråder det. Hold det til ét lag, prøv med en testbruger fra den nederste gruppe, vent en dag, før testen kaldes mislykket, og skriv ned, hvilken gruppe der giver hvad. Ligger gruppen i stedet direkte i webstedets SharePoint-gruppe, kræver det ingen indlejring, og scripts kan se, hvem der står i den. Det kan godt være en konfigurationsliste, som i Selvbetjening til nye websteder, og grupperne webstedet ikke kendte, hvor grupperne og deres rettigheder står pr. webstedstype. Hvorfor reglerne holder bedst, når de er bygget ind, står i Styring af SharePoint, der bliver fulgt.

Spørg, hvem der læser gruppen#

Om en gruppe i en gruppe virker, kan ikke ses i Entra ID. Det afgøres af den tjeneste, der læser den. Er det betinget adgang, går det. Er det SharePoint-rettigheder, går det efter alt at dømme, men det er hverken skrevet ned eller anbefalet, og der kan gå timer, før det kan ses. Er det en app, en licens, et team eller et Power Platform-miljø, går det ikke. Er det en dynamisk gruppe med memberOf, er der frist til den 3. november 2026.