Wachtwoordresets en accountstatus: de verborgen tijdvreter

Kijk een week naar de tickets van een gemiddelde IT-servicedesk en er zit een categorie tussen die niemand spannend vindt maar die wel constant terugkomt: "ik kan niet inloggen". De helft daarvan is een vergeten wachtwoord. De andere helft is iets met de accountstatus: geblokkeerd na te veel pogingen, uitgeschakeld terwijl het niet had gemogen, of een account dat is verlopen omdat de einddatum van een contract voorbij is. Los per ticket is het twee minuten werk. Bij elkaar is het een sluipende kostenpost die zelden op een dashboard staat.

TL;DR

• Wachtwoordresets en accountstatus-vragen zijn samen vaak 20 tot 40% van het ticketvolume op een IT-servicedesk.
• Het meeste resetwerk hoeft niet door een mens: self-service password reset (SSPR) in Entra ID vangt het grootste deel weg.
• Accountstatus-tickets komen vaak niet door de gebruiker maar door je eigen proces: verlopen accounts, lockouts, en accounts die te vroeg of te laat worden uitgeschakeld.
• De grootste winst zit in de bron: zorg dat status (actief, geblokkeerd, uitgeschakeld, verlopen) een gevolg is van een regel of een attribuut, niet van handwerk.
• Houd de echte uitzonderingen (verdacht account, geforceerde reset na incident) bewust bij een mens.

Waar het volume echt vandaan komt

Een wachtwoordreset lijkt het simpelste ticket dat er is. De werkelijke kosten zitten niet in de reset zelf, maar in de context eromheen. De gebruiker belt of mailt, de servicedeskmedewerker moet de identiteit vaststellen (want je wilt niet dat iemand het wachtwoord van een ander reset), de reset uitvoeren, een tijdelijk wachtwoord doorgeven via een veilig kanaal, en soms nog uitleggen hoe de gebruiker daarna zelf een nieuw wachtwoord instelt. Reken op vijf tot tien minuten per keer, en dat keer tientallen per week.

Accountstatus-tickets zijn stiekem duurder, omdat de gebruiker meestal niet weet wat er aan de hand is. "Ik kan niet inloggen" kan van alles betekenen:

• Het account is geblokkeerd na te veel foute pogingen (lockout).
• Het account is uitgeschakeld, bijvoorbeeld omdat iemand het bij offboarding heeft aangezet en de persoon toch nog een dag doorwerkt.
• Het account is verlopen omdat de accountExpires- of einddatum van een contract is gepasseerd.
• De gebruiker zit in een MFA-lus en komt er zelf niet uit.

Elk van deze gevallen kost eerst diagnosetijd voordat er überhaupt iets opgelost wordt. En de gebruiker staat intussen stil.

Wachtwoordresets: het grootste deel hoort niet bij de servicedesk

Het overgrote deel van de resetverzoeken is geen incident, het is routine. En routine hoort in self-service. Entra ID heeft hier een kant-en-klare oplossing voor: self-service password reset.

Zet SSPR aan en maak het verplicht

Met SSPR reset een gebruiker zijn eigen wachtwoord na verificatie via een tweede factor. Geen ticket, geen wachttijd, geen servicedeskmedewerker die de identiteit moet vaststellen. De praktische stappen:

1. Zet SSPR aan in Entra ID, eerst voor een pilotgroep, daarna voor iedereen.
2. Verplicht registratie van de verificatiemethoden, zodat mensen niet pas op het moment dat ze buitengesloten zijn ontdekken dat ze niks hebben ingesteld.
3. Zet password writeback aan als je een hybride omgeving hebt, zodat een reset in Entra ID ook doorwerkt naar on-prem Active Directory. Zonder writeback reset iemand wel zijn cloud-wachtwoord maar niet dat waarmee hij op zijn laptop inlogt, en dan bel je alsnog.
4. Communiceer één keer duidelijk waar mensen het zelf doen, en verwijs daar in elk relevant ticket naar.

Dit is geen ServiceChanger-functie en dat hoeft ook niet. SSPR zit in Entra ID P1 en het is de eerste stap die het meeste resetvolume wegneemt. ServiceChanger doet niets aan authenticatie, wachtwoorden of MFA. Dat is bewust: de identity provider hoort dat te doen.

Wat je wel bij de servicedesk houdt

Niet alle resets horen in self-service. Een geforceerde reset na een security-incident, een account waarvan je vermoedt dat het is overgenomen, of een gebruiker die zijn tweede factor kwijt is en zich opnieuw moet registreren: dat zijn de echte uitzonderingen. Die wil je juist wel door een mens laten doen, met de bijbehorende extra verificatie. Het punt is niet om alles te automatiseren, maar om de routine weg te halen zodat er tijd overblijft voor de gevallen die aandacht verdienen.

Accountstatus: het probleem zit meestal in je eigen proces

Wachtwoordresets los je op met een tool die Microsoft al levert. Accountstatus-tickets zijn lastiger, want die ontstaan vaak niet door de gebruiker maar door hoe jouw organisatie accounts beheert. Een paar veelvoorkomende patronen.

Verlopen accounts die niemand zag aankomen

Contractors en tijdelijke medewerkers krijgen vaak een einddatum mee. Dat is goed. Het gaat mis als die einddatum wordt bereikt zonder dat iemand het verwacht: de contractor werkt gewoon door, kan opeens niet meer inloggen, belt de servicedesk, en die zet de datum handmatig een maand vooruit. Vaak zonder te checken of dat wel klopt. Zo verloopt het account elke maand opnieuw, en elke maand kost het een ticket.

De oplossing is niet de datum steeds vooruitschuiven, maar de einddatum koppelen aan de werkelijke contractduur en de verlenging via een expliciete goedkeuring laten lopen. Als een attribuut zoals accountExpires of een einddatumveld gevuld is vanuit een betrouwbare bron, wordt verlopen een voorspelbaar gevolg in plaats van een verrassing.

Accounts die te vroeg of te laat worden uitgeschakeld

Bij offboarding is timing alles. Schakel je een account te vroeg uit, dan zit iemand op zijn laatste werkdag zonder toegang en belt hij de servicedesk. Schakel je het te laat uit, dan blijft er staande toegang open die er niet meer hoort te zijn. Beide zijn een probleem, en beide komen voort uit handmatig timen.

Hier zit wel raakvlak met wat een attribuutgestuurd model kan doen. Als de leaver-status volgt uit een attribuut (laatste werkdag bereikt, dienstverband beëindigd), dan kun je toegang en groepslidmaatschap laten volgen zonder dat iemand de knop op het juiste moment moet indrukken. Let op: het account daadwerkelijk uitschakelen of verwijderen is een aparte stap. ServiceChanger regelt standaard de groeps- en rollidmaatschappen op basis van attributen; het account zelf aanmaken of uitschakelen vanuit een HR-systeem is maatwerk via runbooks, geen out-of-the-box functie. Wees daar eerlijk over richting je organisatie, anders beloof je iets wat de tool niet doet.

Lockouts die eigenlijk symptomen zijn

Een enkele lockout is normaal: iemand typt drie keer verkeerd en het account gaat op slot. Een gebruiker die elke week in een lockout zit, is een signaal. Meestal is er een oud opgeslagen wachtwoord dat ergens blijft proberen in te loggen: een telefoon met een oude mailconfiguratie, een service die met verlopen credentials draait, een gemapte schijf. Een lockout-ticket dat je alleen maar ontgrendelt zonder de bron te zoeken, komt volgende week gewoon terug. Dit is geen automatiseringsvraag, maar een aandachtspunt: log herhaalde lockouts per account, want dat rijtje wijst je naar de echte oorzaak.

Een praktische volgorde

Als je hier grip op wilt krijgen zonder een groot project op te tuigen, is dit een werkbare volgorde:

1. Meet eerst. Tel een maand lang hoeveel tickets over wachtwoordreset en accountstatus gaan. Zonder dat getal weet je niet waar de winst zit.
2. Zet SSPR aan en verplicht registratie. Dit vangt het grootste, saaiste deel weg en is puur Entra ID.
3. Zet password writeback aan als je hybride bent, anders lost SSPR maar de helft op.
4. Maak einddatums betrouwbaar. Koppel het verlopen van contractoraccounts aan echte contractdata en een goedkeuringsstap, niet aan een servicedeskmedewerker die de datum steeds vooruitzet.
5. Laat status volgen uit attributen waar dat kan. Groepslidmaatschap en toegang die meebewegen met dienstverband en rol schelen een hoop losse status-tickets. Het account aan- en uitzetten zelf blijft een bewuste keuze.
6. Houd de echte uitzonderingen bij de mens. Verdachte accounts, geforceerde resets na incidenten en verloren tweede factoren horen niet in self-service.

Tot slot

Wachtwoordresets en accountstatus zijn het soort werk dat nooit op de roadmap komt omdat elk afzonderlijk ticket zo klein is. Precies daarom lopen ze op. De eerste stap kost je niets extra's: zet SSPR aan als dat nog niet zo is, en tel een maand lang hoeveel van je tickets over inloggen gaan. Dat getal maakt meestal in één keer duidelijk of dit een randverschijnsel is of een van je grootste stille kostenposten.