Het identiteitsbeheer van de gemeente Amsterdam is chaotisch. Nieuwe gemeente-ambtenaren moeten het weken lang stellen zonder account. Ambtenaren die langer in dienst zijn, beschikken daarentegen vaak juist over 'drie of meer' accounts. Daarnaast zijn collega's lastig vindbaar in de Outlook- en Blackberry-adresboeken van de gemeente. Dat blijkt uit het 'Plan van aanpak infrastructuur en applicaties', dat tot doel heeft om het aantal verstoringen in de basis-ict werkplek terug te dringen.
'Er ontbreekt visie en kaders op het identiteitsbeheer en de toegangscontrole', aldus het gemeentedocument. Daardoor worden medewerkers onder meer 'niet uniek geïdentificeerd'.
Accounts voor werkplekken worden binnen de gemeente aangemaakt op basis van een geautomatiseerde koppeling met personeelregistratiesysteem P-Net en identiteitsbeheer-programma I-AM.
'De bedoeling van deze koppeling is het automatisch aanmaken van een account in Basis-ICT, zodra binnen de personeelsregistratie een goedgekeurd contract is opgevoerd. Deze goedkeuring duurt echter zo lang, dat een nieuwe medewerker al weken aan het werk kan zijn zonder account, doordat dit nog niet is goedgekeurd door de leidinggevende of ingevoerd is in het systeem', aldus het plan van aanpak.
Drie of meer accounts
Ambtenaren die langer in dienst zijn beschikken daarentegen vaak juist over 'drie of meer' accounts. 'I-AM zorgt voor volgnummers in het account van een gebruiker. Helaas is het zo dat bij het aanmaken van een account in een bedrijfsapplicatie er een nieuw account wordt aangemaakt met een nieuw volgnummer. Het komt veel voor dat een gebruiker drie of meer I-AM accounts heeft met verschillende volgnummers, in plaats van één account voor alle applicaties en Basis-ICT. Tenslotte krijgt een medewerker ook weer een nieuw account wanneer hij een promotie krijgt of overgeplaatst wordt. Alle historie gaat daarbij verloren.'
Onvindbare contactgegevens
Daarnaast zijn collega's lastig vindbaar in de Outlook- en Blackberry-adresboeken van de gemeente. Dat wordt veroorzaakt door een onjuiste koppeling tussen het personeelsregistratiesysteem en de basiswerkplekken van de gemeente.
'De koppeling met Basis-ICT zorgt er ook voor dat de naamgeving van de gebruiker identiek is aan die in P-Net. Op zich handig, echter zijn niet de juiste velden uit P-Net gekoppeld aan de juiste velden in Basis-ICT. Daardoor wordt er een verkeerd account aangemaakt in Basis-ICT. Bovendien worden er daardoor verkeerde namen getoond in de adreslijsten van e-mail en Blackberry, waardoor gebruikers niet meer of moeilijk te vinden zijn.'
Servicedesk
Om deze reden heeft de gemeente besloten om de koppelingen tussen het personeelsregistratiesysteem en het identiteitsbeheerprogramma te verwijderen. De werkzaamheden daarvoor zijn in volle gang. 'De afdelingen Servicedesk en Beheer zijn druk met het migreren van de historie van de mail en data naar het nieuwe accounts.'
De gemeente verwacht dat door deze maatregelen de ondersteuning van gemeente-ambtenaren zal verbeteren. 'Dit heeft als voordeel dat de Servicedesk weer snel kan handelen bij het opvoeren van nieuwe medewerkers en het optreden van incidenten.'
Ik werk bij een kleine dienst binnen de gemeente en wij beheren alles zelf. Wij hebben dus ook geen problemen en onze kosten per werkplek zijn vele malen lager dan dat we zouden aansluiten bij de “basis-ict werkplek”. Ik zeg gelijk weer opheffen die basis-ict! Ik krijg er een beetje een noord-zuidlijn gevoel van…
Natuurlijk, en daarnaast gewoon weer over op Sneakernet. Hebben we die dure beheerders en netwerkapparatuur ook niet meer nodig…
Dit heeft alles te maken met Visie, Strategie en Discipline. Identiteitsbeheer moet niet gezien worden als een pure “IT Verantwoordelijkheid”.
Bij een goede koppeling tussen persooneelsadministratie en de basis ICT (waarbij een op orde zijnde personeelsadministratie een hele belangrijke randvoorwaarde is), zouden deze problemen niet hoeven te onstaan. Nu lijken de maatregelen echter meer op het blussen van brandjesdan het oplossen van de oorzaken.
Tuurlijk kunnen nu per individuele afdeling gezien de kosten per werkplek lager zijn dan voor het geheel. Echter bij een goed geïmplementeerde identiteitenbeheer zijn de kosten per werklek voor de het geheel altijd lager dan die van de individuele afdeling bij elkaar opgeteld.
Hoe groter het aantal systemen waarin medewerker en organisatiegegevens gemuteerd moeten worden. Dat vraagt om fouten. Beter is het om per soort gegevens één bronsysteem aan te wijzen en van daaruit alles te synchroniseren.
Laatst zag ik hier een mooi open source product voor, zie http://www.openkop.nl/
Tja, dit soort dingen is in vrijwel iedere grotere organisatie een puinhoop. NDS was wat dat betreft luguber. AD biedt gelukkig nog wat restricties, maar kun je desondanks op oneindig veel manieren verkeerd inrichten. Sommige deskundigen denken dat het lood om oud ijzer is, dat je òf door de kat òf door hond gebeten gaat worden, maar dat hoeft helemaal niet het geval te zijn.
Het begint met aan de organisatie duidelijk maken wat het verschil is tussen forests, domeinen, sites, organisational units, security- distributution- en exclusiongroepen.
In je o.u.’s komen je pc’s, je users en je groepen, maar users en pc’s NOOIT binnen dezelfde hierarchie, ook NOOIT site-gegevens in je user-hierarchie maar vastleggen in sites. De organisatorische hierarchie bevat al je users, de geografische bevat al je devices (pc’s, servers, printers). Dus geen sprongen in dezelfde hierarchie (bijvoorbeeld: Groningen: secretariaat/advocaten/boekhouding. Assen: secretariaat/advocaten/enz.
Aan ieder object en container kun je verder user defined item-classes i.c. items toevoegen. Bijvoorbeeld een geboortedatum of datum-indiensttreding aan een user, de foldermap-naam van het team van de user, of een qualifier van de printergroep van de lokatie van de pc, enz. O.a. middels het door mijn bedrijfje in 2001 ontwikkelde group-policy gedreven loginscript (met bijbehorende adm-file), kunnen dan omgevingsvariabelen worden gezet, ini-bestanden van legacy-applicaties worden gemodificeerd of registry-keys gezet (het laatste in aanvulling op de manier waarop grouppolicies dit van zichzelf al doen).
Applicaties (bijvoorbeeld HRM) kunnen via een interface of desnoods een synchronisatie-slag gebruik maken van alle user defined items. Eigen applicaties kunnen middels een type-library op exact dezelfde manier policy-driven worden gemaakt zoals MS-Office, Windows en Internet Explorer.
Alle gegevens worden automatisch gedistribueerd over al je domein-controllers, er is volledig rechtenbeheer op van toepassing en het integreert je systeemgegevenbeheer voor applicaties transparant met je platformsysteembeheer. Restore je domeincontroller en alles is er weer.
Daarna kun je pas problematiek zoals in dit artikel efficiènt oplossen.
Voor mij onbegrijpelijk dat dit niet werkt. Al langer dan 4jaar geleden, toen ik nog bij de gemeente werkte is men hier mee begonnen. Voor “weinig” geld kon men Novell licenties kopen, alleen kreeg en krijgt niemand dit goed geïmplementeerd. Nu ben ik bij de gemeente Rotterdam in dienst en die hebben het binnen 6 maanden werkend. Inclusief HR koppeling, AD en adresboek. Software functionaliteit en beleid zijn bij Amsterdam niet flexibel genoeg dit op te lossen. Hoe moeilijk het voor sommige zal zijn, maar ga eens kijken bij gemeente Rotterdam.
De gemeente Rotterdam doet Identiteitsbeheer binnen 1 dag. Is zelfs een casestudy van: http://www.tools4ever.com/files/cases/gemeente_rotterdam.pdf