Identity Management: medewerker gaat uit dienst
Bij Identity Management spreken we vaak over 3 scenario’s: instroom, doorstroom en uitstroom. De prioriteit en nadruk komt vrijwel altijd te liggen bij het instroom scenario, omdat daar het belang zit om een nieuwe medewerker snel productief te laten zijn. Doorstroom krijgt vaak een lagere prioriteit en hangt af van de volwassenheid van de organisatie op het gebied van security en rollen.
Uitstroom is echter ook zeer belangrijk, met name als het gaat om security, licentiekosten en vervuiling van de IT omgevingen. De noodzaak om accounts dicht te zetten en rechten te ontnemen kan hoog zijn wanneer medewerkers op minder plezierige manier afscheid hebben moeten nemen. We zien echter wel een verschil in prioriteit tussen het meteen dichtzetten van accounts en het uiteindelijk opruimen van de resources.
Een belangrijk punt om in het achterhoofd te houden is het moment waarop iemand uit dienst gaat. Dit staat vrijwel altijd opgeslagen in een HRM systeem of salarisverwerkingspakket, aangezien de organisatie het salaris niet zal laten doorlopen. Deze gegevens vinden echter maar zelden hun weg naar de IT en komt het veel voor dat de IT afdeling op eigen initiatief opschoningsacties op touw zet op basis van eigen onderzoek (laatste login op het netwerk).
Een aantal voorbeelden van scenario’s die ik voor klanten heb ontwikkeld zijn:
Voordat iemand uit dienst gaat:
- Waarschuwing 2 weken vantevoren naar de medewerker en de leidinggevende per e-mail, waarin wordt aangegeven wat de actie is en per wanneer de accounts en rechten worden geblokkeerd.
- Extra waarschuwing de laatste 2 dagen.
De dag dat iemand uit dienst gaat:
- Blokkade inlog in Active Directory (disable). Het is ook mogelijk om het account actief te laten maar bijvoorbeeld alleen inloggen op een niet bestaand werkstation mogelijk te maken. Hiermee blijft bijvoorbeeld de Exchange mailbox nog benaderbaar.
- Verplaatsen account naar speciale OU.
- Ontnemen groepen behalve distributiegroepen (ter voorkomen van NDR’s naar distributiegroepen).
- Optioneel een x aantal dagen wachten voor de blokkade indien medewerkers nog extra tijd krijgen.
- Overdracht van rechten op mail en data naar bijvoorbeeld een leidinggevende. Dit kan via het uitdelen/overschrijven van rechten of het volledig kopieren van deze resources naar de omgeving van de leindinggevende.
- Aanmaken closed call in TOPdesk met omschrijving van de blokkade.
- Downstream provisioning: blokkade van de gebruiker in applicatie X.
Na een bepaalde blokkade-periode:
- Verwijderen van het account.
- Verplaatsen van data (home-directory, profiel, terminal server home-directory en/of profielen) naar een archiefmap.
- Extractie van de Exchange mailbox naar PST en opslaan op een archief server.
- Optioneel volledig verwijderen van alle mail en data.
Bovenstaande scenario’s zijn geautomatiseerd en gefaseerd uit te voeren, delen van het scenario kunnen echter ook via een electronisch formulier worden gestart. Het is bijvoorbeeld gebruikelijk om de waarschuwing en blokkade automatisch te laten doen, maar het definitief verwijderen “achter een knop” te plaatsen.
Geschreven door:
Arnout van der Vorst
Maak kennis met Arnout van der Vorst, de inspirerende Identity Management Architect bij Tools4ever sinds het jaar 2000. Na zijn studie Hogere Informatica aan de Hogeschool van Utrecht is hij begonnen als Supportmedewerker bij Tools4ever. Daarna heeft Arnout zich opgewerkt tot een sleutelfiguur in het bedrijf. Zijn bijdragen strekken zich uit van klantondersteuning tot strategische pre-sales activiteiten, en hij deelt zijn kennis via webinars en artikelen.
Anderen bekeken ook
Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)
14 oktober 2010