Roltoegang in Entra ID richt je in door per functie of rol een security group aan te maken die de toegang draagt: applicaties, licenties en data koppel je aan de groep, nooit aan de persoon. De groep vul je vervolgens automatisch op basis van HR attributen zoals afdeling en functie, via dynamische membership rules of via provisioning vanuit je HR systeem. In dit artikel lees je hoe je het model ontwerpt, welke keuzes je maakt en hoe je het stap voor stap inricht.

Waarom dit belangrijk is: zolang je rechten per persoon uitdeelt, is elke indiensttreding handwerk, elke functiewisseling een gok en elke uitdiensttreding een risico. Wie na drie functiewisselingen nog steeds bij de personeelsdossiers kan, is geen incident, maar het voorspelbare resultaat van toegang op persoonsniveau.

Quick facts

Van personen naar rollen: het model

Roltoegang betekent dat je de vraag "wat mag Jan?" vervangt door "wat mag een financieel medewerker?". De keten wordt: persoon → rol → groep → rechten. Jan is financieel medewerker, dus lid van de rolgroep Finance-Medewerker, en die groep geeft toegang tot het boekhoudpakket, de juiste Microsoft 365 licentie en de financiële SharePoint-site.

Het ontwerp begint niet in de portal maar in een spreadsheet: zet je functies uit HR in de rijen en je applicaties, licenties en datalocaties in de kolommen. Dat is je autorisatiematrix in wording. Begin met de vijf grootste functiegroepen, die dekken in de praktijk 60 tot 80 procent van je medewerkers. Verfijn daarna.

Rolgroepen en resourcegroepen

Op papier wil je twee lagen: rolgroepen die beschrijven wíé iemand is (ROL-Finance-Medewerker) en resourcegroepen die beschrijven wát iemand krijgt (APP-Exact-Gebruikers, LIC-M365-E3). De rolgroep nest je dan in de resourcegroepen, zodat één lidmaatschap alles regelt.

Hier zit de belangrijkste valkuil van Entra ID: nesting werkt niet voor licenties en app-toewijzing. Alleen directe leden van een groep krijgen de licentie of de applicatie toegewezen; leden van geneste groepen worden genegeerd. De memberOf functie die dit deels oplost is al jaren preview en door Microsoft niet bedoeld voor productie. In de praktijk betekent dit dat je in puur Entra kiest uit twee opties: vlakke rolgroepen die je rechtstreeks aan elke resource koppelt, of tooling die leden automatisch in de juiste resourcegroepen plaatst. Onthoud dit punt, het komt terug.

Dynamisch of assigned?

Dynamische groepen vullen zichzelf op basis van een regel over gebruikersattributen, bijvoorbeeld:

(user.department -eq "Finance") and (user.jobTitle -eq "Medewerker")

(user.department -eq "Finance") and (user.jobTitle -eq "Medewerker")

Dat is de snelste route naar roltoegang, met drie voorwaarden. Eén: je hebt Entra ID P1 nodig voor elke gebruiker die in een dynamische groep zit. Twee: je HR attributen in Entra moeten kloppen en gevuld blijven, want een dynamische regel op een leeg department veld doet niets. Drie: de veiligheid van de groep is zo sterk als de schrijfrechten op de attributen in de regel. Als gebruikers of een slecht beveiligde sync het department-veld kunnen aanpassen, kunnen ze zichzelf toegang geven. Controleer dus wie de attributen mag schrijven, zeker bij attributen die vanuit on-premises AD gesynchroniseerd worden.

Dynamische groepen kennen bovendien geen uitzonderingen: je kunt geen handmatig lid toevoegen aan een dynamische groep. De collega die tijdelijk meedraait bij Finance krijg je er dus niet in zonder de regel te vervuilen of een tweede groep te bouwen.

Assigned groepen geven je die vrijheid wel, maar verplaatsen het probleem: iemand moet het lidmaatschap bijhouden. Zonder automatisering is dat de servicedesk, en dan ben je terug bij handwerk.

Naamgeving: saai maar beslissend

Een conventie als ROL-<Afdeling>-<Functie> en APP-<Applicatie>-<Rechtniveau> lijkt een detail, tot je over twee jaar 400 groepen hebt en niemand meer weet waar "Groep Finance 2 nieuw" voor dient. Spreek de conventie af vóór je de eerste groep aanmaakt en dwing hem af met een naming policy. Geef elke groep een eigenaar en een beschrijving met het doel. Je auditor gaat ernaar vragen.

Waarom je dit in Joinly wilt regelen

Het native model breekt op vier punten zodra je organisatie groeit. De nestingbeperking dwingt je tot vlakke groepen, dus elke nieuwe applicatie betekent alle rolgroepen opnieuw koppelen. Dynamische regels verspreiden je autorisatielogica over tientallen losse groepen zonder centraal overzicht van wie wat krijgt en waarom. De regels werken alleen binnen Entra: je on-premises AD groepen, fileshares en applicaties zonder Entra-koppeling doen niet mee. En de P1-eis maakt dynamische groepen een kostenpost voor precies de organisaties die er het meest aan zouden hebben.

Joinly draait het om: het rollenmodel staat centraal op één plek en wordt gevuld vanuit je HR systeem: AFAS, HR2Day, Visma Raet, YouServe of Workday. Eén business rule "afdeling Finance + functie Medewerker" beheert het lidmaatschap van álle bijbehorende groepen, in Entra ID én on-premises AD, inclusief uitzonderingen met einddatum en een audit trail per mutatie. Functiewisseling in HR? De oude rechten gaan eraf, de nieuwe erop, zonder ticket.

Benieuwd hoe jouw huidige groepenstructuur ervoor staat? Doe de gratis scan op scan.joinly.app en zie binnen tien minuten waar je roltoegangsmodel afwijkt van best practice.

Zo doe je het

Stap 1: Ontwerp je matrix

Maak een spreadsheet met functies (uit HR) in de rijen en resources in de kolommen: applicaties, licenties, SharePoint-sites, fileshares. Vul per cel het rechtniveau in. Laat de betreffende afdelingsmanager meekijken. IT weet niet wat Finance nodig heeft, Finance wel.

Stap 2: Leg je naamconventie vast

Bijvoorbeeld: ROL-Finance-Medewerker, APP-Exact-Gebruiker, LIC-M365-E3. Documenteer de conventie en stel in Entra een group naming policy in (Entra ID → Groups → All groups → Naming policy) zodat afwijkende namen geblokkeerd worden.

Stap 3: Maak de rolgroep aan

1. Ga naar entra.microsoft.com en meld je aan als minimaal Groups Administrator.

2. Navigeer naar Entra ID → Groups → All groups → New group.

3. Kies Group type: Security.

4. Vul de naam volgens je conventie en een duidelijke beschrijving in.

5. Kies bij Membership type: Dynamic User (of Assigned als je de vulling via provisioning-tooling doet).

Stap 4: Bouw de dynamische regel

1. Klik op Add dynamic query.

2. Bouw in de rule builder: property department, operator Equals, value Finance. Voeg een tweede expressie toe voor jobTitle als je per functie wilt differentiëren.

3. Klik op Validate Rules en test met een paar bestaande gebruikers of de regel doet wat je verwacht.

4. Sla op met Save en klik Create.

De regel wordt meestal binnen enkele minuten verwerkt; bij grote tenants kan het tot 24 uur duren. Controleer daarna de membership onder Groups → jouw groep → Members.

Stap 5: Koppel de applicatie aan de groep

1. Ga naar Entra ID → Enterprise applications en open de applicatie.

2. Kies Users and groups → Add user/group.

3. Selecteer je rolgroep en, als de app rollen ondersteunt, de juiste app-rol.

Herhaal dit per applicatie uit je matrix. Let op: dit werkt alleen met directe leden; een geneste groep binnen je rolgroep krijgt géén toegang.

Stap 6: Koppel de licentie aan de groep

1. Ga naar Entra ID → Billing → Licenses → All products.

2. Selecteer de licentie (bijv. Microsoft 365 E3) en kies Assign.

3. Selecteer je rolgroep en schakel eventueel losse serviceplans uit.

Controleer na verwerking op licentiefouten onder de groep. De bekendste oorzaak van mislukte toewijzingen: een ontbrekende usageLocation bij de gebruiker.

Stap 7: Test de keten end-to-end

Wijzig bij een testgebruiker het department-attribuut naar Finance en controleer achtereenvolgens: wordt hij lid van de groep, krijgt hij de licentie, verschijnt de app in myapps.microsoft.com. En net zo belangrijk: verdwijnt alles weer als je het attribuut terugzet?

Alternatief: via PowerShell/Graph

powershell

Connect-MgGraph -Scopes "Group.ReadWrite.All"

New-MgGroup -DisplayName "ROL-Finance-Medewerker" `
  -MailEnabled:$false -MailNickname "rol-finance-medewerker" `
  -SecurityEnabled:$true `
  -GroupTypes @("DynamicMembership") `
  -MembershipRule '(user.department -eq "Finance") and (user.jobTitle -eq "Medewerker")' `
  -MembershipRuleProcessingState "On"

Connect-MgGraph -Scopes "Group.ReadWrite.All"

New-MgGroup -DisplayName "ROL-Finance-Medewerker" `
  -MailEnabled:$false -MailNickname "rol-finance-medewerker" `
  -SecurityEnabled:$true `
  -GroupTypes @("DynamicMembership") `
  -MembershipRule '(user.department -eq "Finance") and (user.jobTitle -eq "Medewerker")' `
  -MembershipRuleProcessingState "On"

Zo doe je dit in Joinly

In Joinly definieer je één business rule op de HR brongegevens: afdeling = Finance én functie = Medewerker. Aan die regel koppel je de gewenste uitkomsten: lidmaatschap van de Entra groepen, de on-premises AD groepen, de licentie en eventuele accounts in applicaties daarbuiten. Uitzonderingen leg je vast met een reden en een einddatum, en elke mutatie is terug te vinden in de audit trail. De dynamische regels, de P1-eis en de nestingbeperking uit dit artikel heb je dan niet meer nodig: het HR systeem is de bron, Joinly voert uit.