Alle artikelen

Leaver-toegang direct afsluiten: trek refresh tokens in

Ruben van der Graaf··7 min lezen

Een account uitschakelen is niet genoeg. Lees waarom je refresh tokens en sessies moet intrekken op de laatste werkdag voor een echte toegangsstop.

Een echte leaver access cutoff die alleen het Entra ID-account uitschakelt, laat een gat achter dat de meeste IT-teams niet doorhebben. Het intrekken van refresh tokens, niet de uitschakel-knop, is wat een lopende sessie daadwerkelijk beëindigt. Zolang dat token niet is ingetrokken, kan iemand met een laptop die al open stond, een telefoon die al ingelogd is, of een gecachte mobiele app, gewoon nog uren doorwerken nadat het account in het admin center al op "uitgeschakeld" staat.

Dit is geen theoretisch randgeval. Zo werkt het tokenmodel van Entra ID nu eenmaal, en het pakt genoeg teams die "account uitschakelen" als eindpunt van de laatste werkdag zien. Dit artikel legt precies uit wat uitschakelen wel en niet doet, hoe je een echte cutoff afdwingt, en waar de resterende gaten zitten zelfs nadat je alles hebt ingetrokken wat Microsoft je laat intrekken.

Waarom uitschakelen niet hetzelfde is als toegang beëindigen

accountEnabled: false is een vlag op directoryniveau. Die zegt tegen Entra ID: wijs elke nieuwe aanmeldpoging voor dit account af. Het doet niets met sessies en tokens die al waren uitgegeven vóórdat je die schakelaar omzette.

Dat onderscheid is belangrijk vanwege hoe moderne authenticatie werkt:

  • Een gebruiker logt één keer in en krijgt een kortlevend access token (meestal ongeveer een uur geldig) en een langerlevend refresh token (vaak 90 dagen of langer geldig, afhankelijk van je configuratie).
  • Elke keer dat het access token verloopt, gebruikt de client stilletjes het refresh token om een nieuwe op te halen, zonder dat de gebruiker het merkt en zonder een nieuw aanmeldmoment dat accountEnabled controleert.
  • Het uitschakelen van het account stopt de volgende interactieve aanmelding. Het stopt niet de stille refresh-cyclus die al in gang is op een apparaat dat al is geauthenticeerd.
In de praktijk betekent dit dat een uitgeschakelde vertrekker gewoon ingelogd kan blijven in Outlook, Teams en SharePoint op een laptop die openstond bij vertrek, soms voor de resterende levensduur van het refresh token, tenzij iets dat token expliciet intrekt.

De oplossing: sessies intrekken, niet alleen het account uitschakelen

Microsoft Graph biedt precies daarom een revokeSignInSessions-actie. Die maakt de refresh tokens van de gebruiker ongeldig (en daarmee ook sessiecookies die eraan gekoppeld zijn), zodat elke client zich opnieuw moet authenticeren zodra zijn access token verloopt. In combinatie met Continuous Access Evaluation (CAE), die Microsoft steeds verder uitbreidt naar meer workloads, kan het effect voor ondersteunde apps bijna real-time zijn: een uitgeschakeld account kan binnen enkele minuten de toegang tot Exchange Online, SharePoint en Teams kwijtraken, in plaats van te wachten tot het access token vanzelf verloopt.

Wat een echte leaver-cutoff moet bevatten

Behandel de laatste werkdag als een reeks, niet als één klik. Vier acties moeten samen gebeuren, in ongeveer deze volgorde:

  1. Account uitschakelen. Stopt direct elke nieuwe interactieve aanmelding.
  2. Refresh tokens en sessies intrekken via Microsoft Graph (revokeSignInSessions) of het bijbehorende PowerShell-commando. Dit is de stap die daadwerkelijk beëindigt wat al openstond.
  3. MFA-methoden resetten of verwijderen. Als een apparaat of authenticator-app gecompromitteerd is of gewoon niet is ingeleverd, voorkomt dit dat het opnieuw gebruikt wordt om in te loggen zodra het account weer wordt ingeschakeld of iemand een wachtwoord reset.
  4. App-wachtwoorden en service principal-credentials intrekken als de vertrekker eigen app-registraties of client secrets had gekoppeld aan zijn identiteit.

Waarom de volgorde ertoe doet

Uitschakelen en sessies intrekken horen bij elkaar, idealiter getriggerd door hetzelfde geautomatiseerde event, want het een zonder het ander laat een duidelijk gat: alleen uitschakelen laat lopende sessies gewoon doordraaien, alleen intrekken zonder uitschakelen betekent dat het account een minuut later gewoon opnieuw kan inloggen. Geen van beide acties op zichzelf is een cutoff. Samen, binnen hetzelfde script of draaiboek, wel.

Waar tokens blijven leven, ook nadat je ze intrekt

Sessies intrekken in Entra ID is noodzakelijk, maar bereikt niet alles. Een paar plekken vragen om aparte aandacht:

Gecachete tokens in mobiele en desktop-apps

Sommige native apps cachen tokens agressiever dan de browser en respecteren een server-side intrekking mogelijk pas bij hun volgende netwerkverzoek. Als de telefoon van een vertrekker nooit is ingeleverd, stopt het intrekken van de sessie nieuwe API-aanroepen, maar een goed getimede offline actie binnen een app die al openstond kan er soms nog doorheen glippen tot de client de volgende keer met de server praat.

On-prem Active Directory: Kerberos vraagt het niet aan Entra ID

Als je vertrekker ook on-prem AD-toegang had, blijft een Kerberos-ticket dat al was uitgegeven vóórdat het account werd uitgeschakeld geldig totdat het verloopt (standaard doorgaans tot 10 uur) of de KDC opdracht krijgt het ongeldig te maken. Het AD-account uitschakelen stopt nieuwe ticket-uitgifte; het roept geen tickets terug die al ergens in cache staan. Voor echt gevoelige accounts sluit het forceren van een Kerberos-ticketvernieuwing, of het resetten van het accountwachtwoord (wat het sleutelmateriaal verandert waarop tickets zijn gebouwd), dit gat.

Conditional access en onthouden apparaten

Als een apparaat gemarkeerd stond als "onthouden" voor MFA, of onder een conditional access-uitzondering valt, controleer dan of het apparaat van de vertrekker geen speciale vertrouwensstatus behoudt die het account zelf overleeft.

De tabel die de meeste teams in hun hoofd hebben (en zouden moeten opschrijven)

SessietypeWat uitschakelen van het account doetWat het daadwerkelijk intrekt
Nieuwe interactieve aanmeldingDirect geblokkeerdN.v.t., al geblokkeerd
Bestaande Entra ID-sessie (access token)Niets tot verloop (~1 uur)Sessies intrekken / CAE
Refresh tokenNiets tot natuurlijk verloop (dagen tot maanden)revokeSignInSessions via Graph
On-prem Kerberos-ticketNiets tot natuurlijk verloop (tot ~10u)Wachtwoordreset / KDC-ticket ongeldig maken
Gecachet mobiel app-tokenVertraagd tot volgende serveraanroepSessie intrekken + app-level uitloggen waar ondersteund
Onthouden MFA-apparaatNiet beïnvloedHandmatig vertrouwen van apparaat verwijderen

De cutoff onderdeel maken van de leaver-trigger, niet een handmatige stap

Het betrouwbaarheidsprobleem met deze hele reeks is niet dat een van de acties moeilijk is. revokeSignInSessions is één Graph-aanroep. Het probleem is eraan denken om het uit te voeren, elke keer, op de daadwerkelijke laatste werkdag, en niet drie dagen later wanneer iemand eindelijk door een tickets-wachtrij heen werkt.

Daarom hoort dit thuis in dezelfde geautomatiseerde trigger als de rest van de leaver-verwerking, niet als handmatige stap op een checklist. Zodra een leaver-event afgaat, of dat nu komt van een HR-statuswijziging of een handmatig gemarkeerd vertrek, zou hetzelfde draaiboek dat het account uitschakelt in één moeite door het endpoint voor sessie-intrekking moeten aanroepen. Dit is een natuurlijke uitbreiding van attribuutgestuurde toegangsautomatisering: als groeps- en rollidmaatschap al automatisch afgebouwd wordt zodra iemands statusattribuut verandert, sluit het intrekken van actieve sessies op datzelfde triggermoment het laatste venster dat "account uitschakelen" openlaat. De ABAC-engine van ServiceChanger regelt de toegangs- en lidmaatschapskant van die automatisering; de uitschakel-en-intrek-actie zelf loopt via je eigen Azure Automation-draaiboek of Graph-script, getriggerd door diezelfde statuswijziging.

Dit in één geautomatiseerde keten krijgen, in plaats van drie losse mensen die drie losse dingen doen op drie losse momenten, is wat "we hebben een offboardingproces" echt omzet in "een vertrekker verliest binnen minuten toegang, elke keer."

FAQ

Beëindigt het uitschakelen van een Entra ID-account een actieve sessie meteen? Nee. Uitschakelen blokkeert nieuwe aanmeldingen, maar maakt een access token of refresh token dat al was uitgegeven vóór het uitschakelen niet ongeldig. Je moet sessies expliciet intrekken om opnieuw authenticeren af te dwingen.

Hoe trek ik de refresh tokens van een gebruiker in Entra ID in? Gebruik de Microsoft Graph-actie revokeSignInSessions (of het bijbehorende Azure AD PowerShell- of Microsoft Graph PowerShell-commando) op het gebruikersobject. Dit maakt de refresh tokens ongeldig en dwingt elke client om opnieuw te authenticeren zodra een access token verloopt.

Beëindigt het intrekken van sessies in Entra ID ook on-prem Active Directory-toegang? Nee. Het intrekken van Entra ID-sessies heeft geen effect op Kerberos-tickets die al zijn uitgegeven door een on-prem domain controller. Daarvoor is een aparte stap nodig, meestal een wachtwoordreset, om het sleutelmateriaal waar tickets op steunen ongeldig te maken.

Kan ServiceChanger sessies en tokens automatisch intrekken? De ABAC-engine van ServiceChanger bouwt automatisch groeps- en rollidmaatschap van een vertrekker af zodra diens statusattribuut verandert, dat is de staande-toegangskant van offboarding. De uitschakel-en-intrek-sessie-actie zelf loopt doorgaans via een Azure Automation-draaiboek of Graph-script, getriggerd door diezelfde statuswijziging, en is geen actie die ServiceChanger zelf rechtstreeks uitvoert.

Een vertrekker op papier afsluiten en in de praktijk afsluiten zijn twee verschillende dingen, en het gat ertussen is precies de levensduur van het refresh token die je nooit hebt gecontroleerd. Maak het intrekken onderdeel van dezelfde geautomatiseerde stap als het uitschakelen van het account, niet een vervolgtaak. Voor meer over het koppelen van leaver-events aan automatische toegangsverwijdering, zie ons overzicht access governance en security compliance, of blader verder over offboarding en Entra ID op de blog.

Volgende stap

Wil je dat de groeps- en rollidmaatschap van een vertrekker automatisch afgebouwd wordt zodra de status verandert, zodat het handmatige deel van offboarding krimpt tot uitschakelen-en-intrekken? Plan een demo of lees de documentatie over toegangsautomatisering.