Én tenant eller femten? Identitetsarkitektur for interkommunale IKT-selskaper

Alle disse samarbeidene har på et tidspunkt tatt et valg som de færreste har dokumentert begrunnelsen for: skal deltakerne ligge i én felles Microsoft Entra-tenant, eller i hver sin?

Valget ble ofte tatt av en løsningsarkitekt i et migreringsprosjekt for åtte år siden. Det binder driften i ti år, og det avgjør hvor vanskelig hver eneste revisjon, hver innsynsbegjæring og hver ny deltaker blir.

Her er det ærlige svaret: begge modellene fungerer, og begge har en pris. Prisen er bare synlig på forskjellige steder.

Modell A: én felles tenant

Alle deltakerkommunene ligger i samme Entra-tenant. Hver kommune har sitt eget verifiserte domene, så en ansatt i Kommune A logger på som navn@kommunea.no.

Dette blir enkelt

Én administrasjonsflate. Servicedesk jobber i ett miljø. Innlemmelse av en ny kommune er å legge til et domene og importere brukere, ikke å bygge opp et nytt miljø.

Ett sett betingede tilgangsregler. Skal alle deltakere ha samme krav til flerfaktorautentisering, skrives regelen én gang.

Ett revisjonsspor. Skal noen svare på hvem som gjorde hva i mars, finnes svaret ett sted.

Samhandling er innebygd. Ansatte på tvers av kommunene kan finne hverandre, dele filer og møtes i Teams uten gjestekontoer.

Lisenskostnaden er lavere per administrator. Færre administratorer trengs totalt.

Dette blir vanskelig

Dataadskillelsen er logisk, ikke fysisk. Kommune A og Kommune B ligger i samme katalog. Adskillelsen håndheves av tilgangsstyring — ikke av at dataene ligger på hver sin plass. Det er en fullt akseptabel modell, men den må dokumenteres og forsvares.

En kompromittert høyprivilegert konto treffer alle. Global Administrator i en felles tenant er Global Administrator i femten kommuner.

Å tre ut av samarbeidet er en migrering. En kommune som melder seg ut, skal ta med seg identiteter, postkasser, filer og Teams-innhold. Det er et prosjekt på flere måneder, ikke en oppsigelse.

Ansvarsdelingen etter personvernforordningen blir vanskeligere å beskrive. Femten behandlingsansvarlige i ett datasett krever at rollene faktisk er gjennomtenkt. Vi går gjennom det i artikkelen om databehandler eller felles behandlingsansvarlig.

Mekanikken: administrative enheter

Verktøyet Microsoft tilbyr for å avgrense administrasjon innenfor én tenant er administrative enheter. En administrator kan tildeles en rolle som bare gjelder objektene i én enhet, i stedet for hele katalogen.

Det virker. Men begrensningene betyr mye i akkurat dette scenariet, og de fremheves sjelden:

• En administrativ enhet kan bare inneholde tre objekttyper: brukere, grupper og enheter. Ingenting annet.
• De kan ikke nøstes. Du kan ikke ha «Kommune A» med «Kommune A / Helse» under.
• Legger du en gruppe i en enhet, kommer gruppen selv under avgrensningen — ikke gruppens medlemmer. En administrator avgrenset til Kommune A kan styre gruppen og medlemskapet i den, men ikke nødvendigvis medlemmenes egne brukerobjekter, med mindre de også ligger i enheten.
• De virker aldri på tvers av tenanter. De er strengt tenant-interne.
• En administrator som tildeles en rolle uten avgrensning, får den for hele tenanten. Feilen er lett å gjøre og vanskelig å oppdage.

Lisensmessig: å opprette administrative enheter går på gratisnivået, men hver administrator med en avgrenset rolle krever Entra ID P1. Bruker du dynamiske medlemskapsregler i enhetene, kreves P1 per omfattet medlem — altså per ansatt, ikke per administrator.

Det siste er det tallet som overrasker folk i budsjettmøtet.

Modell B: én tenant per deltaker

Hver kommune har sin egen tenant. IKT-selskapet drifter dem alle.

Dette blir enkelt

Dataadskillelsen er absolutt. Ingen diskusjon om logisk avgrensning, fordi det ikke er samme katalog.

Uttreden er en overlevering, ikke en migrering. Kommunen tar med seg tenanten sin.

Ansvarsdelingen er lettere å beskrive. Én kommune, én tenant, én behandlingsansvarlig.

Hendelser er avgrenset. En kompromittering rammer én kommune.

Dette blir vanskelig

Og her er det tekniske faktumet som avgjør mest, og som ofte oppdages først etter at valget er tatt:

Microsoft Entra ID har ingen innebygd mekanisme for at én tenant administrerer en annen tenants Entra ID.

Det finnes verktøy i nærheten, men de dekker ikke dette:

• Azure Lighthouse er en flertenant-tjeneste for Azure-ressurser — abonnement, ressursgrupper, Azure Policy, Microsoft Sentinel, Azure Arc. Den dekker ikke administrasjon av Entra ID eller Microsoft 365. Dette er den vanligste misforståelsen på området.
• Microsoft 365 Lighthouse er en annen tjeneste med et annet formål: innlemmelse, overvåking og administrasjon av Microsoft 365-kunder i skala, primært rettet mot tjenesteleverandører.
• GDAP (granulære delegerte administratorrettigheter) er en partnermekanisme i Partner Center. Den gir tidsbegrenset, avgrenset tilgang til kundetenanter, og krever kundens uttrykkelige godkjenning. Begrensning verdt å kjenne: maksimalt 100 sikkerhetsgrupper per kunde ved tildeling av Entra-roller gjennom GDAP.
• B2B-samarbeid og synkronisering på tvers av tenanter løser samhandling mellom brukere. Ikke administrasjon.

Konsekvensen i praksis er at femten tenanter gir femten sett med administratorkontoer, femten sett med betingede tilgangsregler som skal holdes like, femten revisjonsspor, og femten ganger så mange steder en feilkonfigurasjon kan gjemme seg.

Erfaringen fra IT-driftsselskaper som drifter mange kundetenanter er entydig på ett punkt: det som svikter, er ikke det som er vanskelig. Det er det som er repetitivt. Regel nummer fjorten blir litt annerledes enn de tretten andre, og ingen oppdager det før noe skjer.

De fire testene

Ikke velg modell på prinsipp. Velg den på disse fire svarene.

Test 1: uttredentesten

Hva skjer hvis den nest største deltakeren melder seg ut om tre år?

Kan dere ikke beskrive prosessen på én side, har dere ikke tatt valget — dere har utsatt det. Dette er den viktigste testen, fordi den er den eneste som tvinger fram et konkret svar.

For interkommunale samarbeid som akkurat nå diskuterer sammenslåing til større enheter, er dette dessuten ikke et hypotetisk spørsmål.

Test 2: revisjonstesten

Kontrollutvalget i én av deltakerkommunene bestiller en forvaltningsrevisjon av tilgangsstyring. Hvor mange dager tar det å hente ut svaret for akkurat den kommunen, uten å eksponere data fra de fjorten andre?

I én felles tenant er dette et filtreringsspørsmål, og det avhenger helt av om administrative enheter faktisk er i bruk. I separate tenanter er det trivielt for én kommune og tungt hvis flere spør samtidig.

Test 3: ansvarstesten

Hvem er behandlingsansvarlig for katalogen, og kan den parten faktisk se hva som skjer i den — uten å be noen om det?

En kommune som er behandlingsansvarlig, men som må sende en e-post til IKT-selskapet for å få vite hvem som ga en tilgang, kan ikke påvise etterlevelse etter artikkel 5 nr. 2. Dette er uavhengig av modell, og det er den vanligste svakheten i begge.

Test 4: den repetitive testen

Hvor mange steder må en endring gjøres for at den skal gjelde alle deltakerne?

Er svaret femten, kommer nummer fjorten til å bli glemt. Ikke fordi noen er uforsiktig, men fordi det er slik femten manuelle repetisjoner alltid ender.

Hva vi vil anbefale, med forbehold

For et interkommunalt IKT-selskap som drifter deltakere av lik type og lik størrelse, med felles tjenestekatalog og felles innkjøp, er én felles tenant med disiplinert bruk av administrative enheter som regel riktig. Prisen er lisenskostnaden for P1 og at uttreden blir tung, og begge deler er kjent på forhånd.

For et selskap som drifter deltakere med svært ulike behov, ulike fagsystemporteføljer eller ulik grad av tilknytning — eller der utskifting i deltakermassen er sannsynlig — er separate tenanter riktig, forutsatt at det finnes et administrasjonslag over dem. Uten et slikt lag betaler dere for adskillelsen med driftskvalitet.

Forbeholdet: dette er en vurdering, ikke en regel. Vi har ikke sett deres miljø. Den som forteller deg hvilken modell som er riktig uten å ha spurt om uttredenscenariet og deltakersammensetningen, selger noe.

Det tredje alternativet ingen nevner

Det finnes en tredje modell: separate tenanter for identitet og data, med ett felles administrasjons- og utførelseslag som ligger over dem.

Den bevarer dataadskillelsen og uttredenmuligheten fra modell B, og gir én arbeidsflate og ett spor som i modell A. Det er den modellen Entra Logic er bygget for — tenant-velgeren ligger i den globale headeren, og hver modul konfigureres per tenant.

Vi sier det åpent fordi det er en interessekonflikt: vi tjener penger på at noen velger modell B og trenger et lag over den. Vurderingen over står likevel som den står. En kommune som skal ha én tenant, skal ha én tenant, og da trenger dere oss mindre.

Fem spørsmål å ta med i neste arkitekturmøte

1. Hvor mange verifiserte domener har tenanten i dag, og hvem eier hvert av dem formelt?

2. Er administrative enheter i bruk, eller har alle administratorer tenant-omfattende roller?

3. Hvor mange kontoer har Global Administrator, og hvor mange av dem er personlige kontoer i daglig bruk?

4. Hvordan varsles en deltakerkommune om at det er gjort en endring i hennes egne brukere?

5. Hvis dere skulle innlemme én kommune til i morgen — hvor mange arbeidsdager, og hvem gjør det?

Entra Logic er norsk programvare for styrt administrasjon av Microsoft Entra ID, bygget for mange tenanter fra første linje kode. Hver modul konfigureres per tenant, revisjonssporet er avgrenset per deltaker, og kostnads- og lisensrapportering fordeles per selskap og kommune. Vi tilbyr en gratis tilgangsgjennomgang av Entra ID-miljøet, med skriftlig rapport og konkrete funn. Vi endrer ingenting underveis.

Start gratis → · Les mer om Entra Logic for kommune og interkommunalt IT →

Kilder

• Microsoft: Administrative units in Microsoft Entra ID (learn.microsoft.com/entra/identity/role-based-access-control/administrative-units), hentet 19.08.2026
• Microsoft: What is Azure Lighthouse? (learn.microsoft.com/azure/lighthouse/overview), hentet 19.08.2026
• Microsoft: Introduction to granular delegated admin privileges (GDAP) (learn.microsoft.com/partner-center/gdap-introduction), hentet 19.08.2026
• Microsoft: Microsoft Entra ID licensing (learn.microsoft.com/entra/fundamentals/licensing), hentet 19.08.2026
• Samfunnsbedriftene: IKS-undersøkelsen (antall interkommunale selskaper)
• Kartverket og regjeringen.no: kommune- og fylkesinndeling
• Personvernforordningen artikkel 5 nr. 2