Delegering i Entra ID: PIM, administrative units og custom roles

Hva de tre mekanismene faktisk løser — og hva de ikke løser

PIM styrer *når*, ikke *hva*

Privileged Identity Management er et tidsstyrings- og aktiveringslag oppå rolletildelinger som allerede finnes. Det gir just-in-time-aktivering, tidsbegrenset tilgang med start- og sluttdato, godkjenningskrav, MFA-krav ved aktivering, begrunnelsesfelt og revisjonshistorikk — for Entra-katalogroller, Azure-ressursroller (RBAC) og, via PIM for Groups, medlemskap og eierskap i grupper.

Det PIM ikke gjør, er å definere nye rettigheter. En bruker som aktiverer Helpdesk Administrator gjennom PIM, har i aktiveringsvinduet nøyaktig de samme rettighetene som en bruker med permanent tildeling av samme rolle. PIM reduserer eksponeringstiden. Det reduserer ikke rettighetsomfanget.

Konsekvensen er at PIM løser «for mange har rettighetene hele tiden», men ikke «denne personen skal kunne gjøre nøyaktig én ting». Microsofts eget svar på det siste er entitlement management — tilgangspakker med delegerte pakkeforvaltere — og ikke PIM.

Lisenskrav: Entra ID P2 eller Entra ID Governance, for kvalifiserte brukere, for godkjennere, for de som utfører rollegjennomganger, og for medlemmer og eiere i PIM for Groups. Kjente begrensninger i PIM for Groups: maks 500 rolletildelbare grupper per tenant, ingen nestede grupper som aktive medlemmer i rolletildelbare grupper, og verken dynamiske grupper eller grupper synkronisert fra lokalt AD kan aktiveres i PIM.

Administrative units avgrenser mindre enn folk tror

En administrative unit (AU) lar deg scope en rolletildeling til et utvalg brukere, grupper eller enheter. Det er riktig verktøy for «kun min avdeling» — men med fire begrensninger som gir problemer i praksis:

For det første, gruppemedlemmer er ikke i scope. Legger du en gruppe i en AU, er det gruppeobjektet som er avgrenset. AU-administratoren kan endre gruppens egenskaper og medlemskap, men ikke egenskapene til de enkelte medlemmene — med mindre medlemmene også er lagt inn i AU-en separat. Dette er den vanligste feilantakelsen.

For det andre, ikke alle roller kan scopes. Kun et definert subsett støtter AU-scope: Authentication Administrator, Cloud Device Administrator, Groups Administrator, Helpdesk Administrator, License Administrator, Password Administrator, Privileged Authentication Administrator, SharePoint Administrator, Teams Administrator, User Administrator og noen få til. Azure RBAC-roller støttes ikke i det hele tatt — AU gjelder kun Entra-roller. Intune-enhetsadministrasjon er heller ikke dekket.

For det tredje er lisensmodellen kontraintuitiv. Å opprette AU-er er gratis, og medlemmene krever ingen lisens — men hver administrator med AU-scopet rolle krever P1, og bruker du dynamiske medlemsskapsregler (for eksempel department eq "Logistikk"), kreves P1 per medlem. Den elegante løsningen er altså den dyre.

For det fjerde kan AU-er ikke nestes, og de støttes ikke sammen med Entra ID Governance.

Restricted management administrative units er en egen variant som beskytter objekter mot alle unntatt administratorer eksplisitt scopet til AU-en — også Global Administrator. Nyttig, men: innstillingen er irreversibel (må settes ved opprettelse), maks 100 per tenant, kun sikkerhetsgrupper støttes (ikke Microsoft 365-grupper, mail-enabled security groups eller distribusjonsgrupper), og objekter i en slik AU kan ikke administreres via PIM, entitlement management, lifecycle workflows eller tilgangsgjennomganger.

Custom roles gir ny sammensetning, ikke ny granularitet

En egendefinert rolle er «a collection of permissions that you add from a preset list. These permissions are the same permissions used in the built-in roles». Du kan sette sammen rettigheter på nye måter og scope til tenant, AU eller enkeltressurs (for eksempel én app-registrering). Du kan ikke lage rettigheter som ikke finnes.

Det tydeligste eksempelet er passordtilbakestilling. Rettigheten microsoft.directory/users/password/update er ikke tilgjengelig for custom roles. Den eneste passordrelaterte rettigheten i listen er microsoft.directory/users/passwordPolicies/update, som gjelder policy-egenskaper — ikke selve passordet. Ønsket «kan tilbakestille passord kun for egen avdeling» kan derfor ikke bygges som en custom role. Det må løses som AU + innebygd Password Administrator eller Helpdesk Administrator, med P1 for administratoren, og med den ekstra begrensningen at passordtilbakestilling under AU-scope kun gjelder mot ikke-administratorbrukere.

Lisenskrav for custom roles: P1 per bruker med tildeling.

Regnestykket

For å gi tolv teamledere og fire servicedeskmedarbeidere avgrenset, tidsbegrenset og godkjenningsstyrt tilgang trenger du: P1 for hver av de seksten (AU-scope og custom roles), P2 eller Governance for godkjenningsflyt i PIM, P1 for hvert dynamiske AU-medlem hvis du vil slippe å vedlikeholde statiske lister, og deretter en oppsettsjobb med AU-er, rolletildelinger og PIM-policyer per avdeling — som må vedlikeholdes hver gang organisasjonen endres. Listeprisen alene, P2 + Governance, er USD 17 per bruker per måned med årsbinding.

Og etter alt dette er de seksten fortsatt administratorer i tekniske forstand. De har bare fått mindre rekkevidde.

Hva dette betyr for Entra Logic

Entra Logic angriper problemet fra motsatt kant. I stedet for å gi ikke-tekniske roller en avgrenset administratorrolle, gir det dem ingen administratorrolle overhodet. Servicedesk, HR og linjeledere arbeider i administrasjonsportalen, ser boet, og sender endringsforespørsler. Utførelsesmotoren kjører mot Microsoft Graph på vegne av godkjenningen — ikke på vegne av brukerens rettigheter.

Det gjør delegeringen til et konfigurasjonsspørsmål i portalen i stedet for et lisens- og rolledesignprosjekt i Entra, og det gjør granulariteten uavhengig av hvilke rettigheter Microsoft har gjort tilgjengelig for custom roles. Der Entras egne mekanismer er avgrenset til det Microsoft har eksponert, er ordreflyten avgrenset til det organisasjonen faktisk har bestemt.

Kilder

• Microsoft Learn — What is Privileged Identity Management?
• Microsoft Learn — PIM for Groups
• Microsoft Learn — Administrative units
• Microsoft Learn — Restricted management administrative units
• Microsoft Learn — Custom roles overview
• Microsoft Learn — User permissions for custom roles
• Microsoft Learn — ID Governance licensing fundamentals
• Microsoft — Microsoft Entra pricing