Kort antwoord: liever niet. AGDLP (Accounts → Global groups → Domain Local groups → Permissions) is een concept uit het tijdperk van handmatig beheer. De hele nestingconstructie bestaat om één reden: een mens moest met zo min mogelijk muisklikken rechten kunnen uitdelen. Zodra een agent de groepslidmaatschappen rechtstreeks toewijst op basis van HR data, vervalt die reden en blijft alleen de complexiteit over. In een hybride omgeving werkt die complexiteit bovendien actief tegen je, want Entra ID negeert nesting bij licenties en app assignment volledig.

In dit artikel lees je hoe AGDLP werkt en waarom het ooit slim was, waar het in een hybride omgeving stukloopt, en hoe het moderne alternatief eruitziet: directe lidmaatschappen, beheerd door automatisering.

Quick facts

Waarom AGDLP ooit slim was

AGDLP lost een probleem op dat serieus was toen beheer handwerk was. Rechten rechtstreeks op personen zetten schaalt niet, dus kwam er een tussenlaag: de rolgroep beschrijft wie iemand is, de resourcegroep beschrijft wat er mag, en één nesting koppelt de twee. Wisselt iemand van functie, dan wijzig je één lidmaatschap en volgen alle rechten. Voor een beheerder met een muis en een to-do lijst was dat pure winst.

Let op wat hier de aanname is: er is een mens die lidmaatschappen bijhoudt, en die mens moet zo min mogelijk plekken hoeven aanraken. De hele architectuur is geoptimaliseerd voor de beperkingen van handmatig beheer.

Waar het model stukloopt

De aanname is vervallen

Zodra provisioning geautomatiseerd is, is "zo min mogelijk plekken aanraken" geen argument meer. Een agent die vanuit het HR systeem werkt, wijzigt net zo makkelijk twintig directe lidmaatschappen als één nesting, foutloos en gelogd. De indirectie levert dan niets meer op, maar kost nog steeds hetzelfde: een extra laag groepen die je moet documenteren, uitleggen aan elke nieuwe collega, en meenemen in elke audit ("via welke nesting heeft deze persoon ook alweer toegang?").

In de cloud werkt het simpelweg niet

Entra ID kent geen groepsscopes en negeert nesting waar het er het meest toe doet: licentietoewijzing en app assignment kijken uitsluitend naar directe leden. Een AGDLP structuur die je doortrekt naar de cloud produceert groepen die eruitzien alsof ze werken maar niets doen. En andersom: cloudgroepen die je via Entra Cloud Sync naar AD provisiont, nemen hun geneste leden niet mee. Het model dat on-premises consistentie beloofde, garandeert in een hybride omgeving juist inconsistentie.

Troubleshooting wordt archeologie

Elke laag indirectie maakt de vraag "waarom heeft deze persoon toegang?" duurder om te beantwoorden. Bij directe lidmaatschappen is het antwoord één query. Bij AGDLP is het een speurtocht door nestingen, en bij AGUDLP (met de universal variant ertussen) nog een laag dieper. Auditors rekenen die uren gewoon door.

Het alternatief: directe toewijzing door een agent

Het moderne model is plat: één resourcegroep per recht (de share, de applicatie, de licentie), en de leden daarvan worden rechtstreeks toegewezen en onderhouden door automatisering. De rol bestaat nog steeds, maar niet als groep in AD; hij leeft als business rule in de provisioninglaag: "afdeling Finance, functie Medewerker" betekent lidmaatschap van DATA-Finance-RW, APP-Exact-Gebruiker en LIC-M365-E3. Rechtstreeks, zonder tussenlaag.

Wat je daarmee wint: de cloudbeperking is irrelevant geworden (directe leden werken overal, on-premises én in Entra), de vraag "wie heeft toegang en waarom" is per groep direct te beantwoorden, en er bestaat geen verschil meer tussen hoe je on-premises en cloudtoegang modelleert. Eén model, beide werelden.

De eerlijke voorwaarde: dit werkt alleen met een agent die de lidmaatschappen ook echt betrouwbaar bijhoudt. Directe toewijzing zónder automatisering is terug naar handwerk, en dan is AGDLP alsnog de betere keuze. Het concept is niet dom, het is achterhaald: verouderd door het wegvallen van de aanname waarop het gebouwd was.

Waarom je dit met Joinly doet

De Joinly AD agent wijst groepslidmaatschappen rechtstreeks toe, in on-premises AD en Entra ID, vanuit de business rules die op je HR data draaien. Indiensttreding, functiewisseling en uitdiensttreding muteren de directe lidmaatschappen automatisch; uitzonderingen leg je vast met reden en einddatum, en elke mutatie staat in de audit trail. De rollenlaag die AGDLP in geneste groepen probeerde te vangen, leeft in Joinly waar hij hoort: als regel die je kunt lezen, wijzigen en aantonen, niet als nestingstructuur die je moet reconstrueren.

Draai je nu nog AGDLP? Prima startpunt: de scan op scan.joinly.app laat zien hoe je huidige groepsstructuur ervoor staat en wat directe toewijzing voor jouw omgeving betekent.

Installation guide

Route A: je hebt (nog) geen provisioning agent

Dan is AGDLP nog steeds de juiste keuze; handmatig beheer zonder structuur is erger. In het kort:

1. Rolgroepen per functie: New-ADGroup -Name "ROL-Finance-Medewerker" -GroupScope Global -GroupCategory Security

2. Resourcegroepen per recht: New-ADGroup -Name "DATA-Finance-RW" -GroupScope DomainLocal -GroupCategory Security

3. Nesting: Add-ADGroupMember -Identity "DATA-Finance-RW" -Members "ROL-Finance-Medewerker"

4. NTFS rechten uitsluitend op de resourcegroepen, nooit op rolgroepen of personen.

5. Sync alleen de rolgroepen naar Entra en koppel ze daar rechtstreeks (zonder nesting) aan apps en licenties.

Zie dit als een tussenstation, niet als eindstation.

Route B: directe toewijzing met de Joinly AD agent

1. Inventariseer je resourcegroepen. Eén groep per recht: shares, applicaties, licenties. De bestaande domain local groepen met NTFS rechten kun je meestal gewoon hergebruiken.

2. Leg de rollen vast als business rules in Joinly. Per functie of afdeling uit het HR systeem definieer je welke resourcegroepen erbij horen. Dit is je autorisatiematrix, maar dan uitvoerbaar.

3. Koppel de Joinly AD agent. De agent draait tegen je on-premises AD en voert de lidmaatschapsmutaties rechtstreeks uit; de Entra kant loopt via de cloudkoppeling. Vanaf dit moment is het HR systeem de bron.

4. Migreer rol voor rol. Kies één rolgroep, laat Joinly de leden van de onderliggende resourcegroepen direct toewijzen, verifieer, en haal daarna de nesting weg. Herhaal per rol. Big bang is nergens voor nodig; beide modellen kunnen tijdens de migratie naast elkaar bestaan.

5. Ruim de rolgroepen op. Zodra een rolgroep nergens meer genest is en geen rechten meer draagt, kan hij weg. Elke verwijderde laag is minder documentatie, minder audituitleg en minder verrassingen.

6. Test de keten. Voer een functiewisseling door in HR bij een testpersoon en controleer dat de directe lidmaatschappen aan beide kanten meebewegen, inclusief het intrekken van de oude rechten.