Gelukkig heeft de Automatiseringsgids een kritiekloze redactie. Anders had ik moeite om met een column te komen. Maar ook op 5 juni stond er weer een pagina vol met onzin over directoryservices. De auteur presteert het om anno 2009 nog een standaard (X.500) en werkwijze te verdedigen gebaseerd op een concept uit 1988. Het gaat hier met name om eenduidige authenticatie en autorisatie binnen de IT-infrastructuur.

Er zijn een aantal bekende implementaties van een centrale authenticatie en autorisatie. De eerste waar ik mee te maken kreeg was 'Yellow Pages' of YP van Sun. De eerste verwijzing die ik kan vinden is uit 1988. Tegenwoordig heet het Network Information Service (NIS). In 1993 kwam Novell met NDS (het huidige eDirectory). Microsoft kwam als laatste in 1999 met Active Directory (AD). De Open Source Software Samba maakt het mogelijk om andere operating systemen met AD te laten werken.

De belangrijkste onzin betreft het volgende citaat uit het artikel: "Cruciaal bij het ontwerp is de opzet van de hiërarchische structuur". En dat is nou net het probleem. Moderne organisaties zijn helemaal niet hiërarchisch van structuur. Procesmatig werken, projectmatig werken, supply-chains en ad-hocnetwerken zowel binnen de organisatie als tussen organisaties vormen de basis van de moderne bedrijfsvoering. Deze zijn verder niet statisch, maar juist in hoge mate flexibel en zelfs tijdelijk. Een paar voorbeelden.

Ten eerste heb ik net een project afgerond in een ziekenhuis. Dit ziekenhuis heeft een heleboel studenten geneeskunde die meerdere stages (co-assistentschappen) lopen in allerlei specialismen. Ieder specialisme is natuurlijk een aparte afdeling (OU) in de hiërarchie van de directoryservice. Het probleem is echter dat zo'n stage een paar weken duurt en dat deze student daarna naar een andere afdeling gaat. Soms gaat hij even weg en komt daarna weer terug. Een niet aflatende stroom van mutatieverzoeken, blokkeren en deblokkeren van gebruikers is het gevolg. De meest eenvoudige oplossing is - zou kunnen zijn - om een aparte afdeling opleidingen te maken en alle co-assistenten binnen deze afdeling te plaatsen en rechten voor alle specialismen tegelijk te geven.

Ten tweede kent iedereen wel de problemen met de projectdirectories op de 'netwerkschijf' of met projectbestanden in 'Sharepoint', 'Groupwise' of 'Lotus Notes'. Dat hoef ik niet verder uit te leggen, daar heeft iedereen wel eens last van gehad. Een project dat korter is dan een maand is niet mogelijk. Je kan eenvoudigweg binnen die tijd niet correct geautoriseerd worden voor de projectenbestanden.

Ten derde had een projectleider ooit eens bedacht dat ik zijn MS-project plannen moest kunnen lezen en dus moest ik MS-project hebben. Systeembeheer mikte mij daartoe in de juiste 'container' van Active Directory. Het voordeel was dat vanuit Active Directory automatisch MS-project op mijn pc geïnstalleerd werd. Een grote besparing in beheeruren. Als externe projectmedewerker had ik echter geen vaste werkplek in het kantoor. Tevens moest ik op meerdere kantoren in het land werken. Dit betekende dat op iedere pc waar ik inlogde automatisch MS-project geïnstalleerd werd. Zo liet ik een 'broodkruimeltjesspoor' van MS-project installaties achter in de IT-infrastructuur. Dat vertraagde de eerste keer inloggen op een nieuwe pc (á uur x consultanttarief) en had het risico dat teveel voor licenties werd betaald.

Ten slotte ben ik op een paar plaatsen ook nog extern docent voor een enkel vak per jaar. Als niet vast personeelslid moet ik telkens opnieuw toegang krijgen tot onderwijssystemen zoals 'Blackboard' en 'Osiris'. Na de nodige handtekeningen en bezoekjes aan systeembeheer krijg ik op zijn best leesrechten. Mijn gebruikelijke oplossing is om een aantal mailtjes (met de nodige attachments) naar het secretariaat te sturen met het verzoek om deze op de onderwijssystemen te plaatsen.

Dit zijn allemaal voorbeelden van situaties die niet te beheren zijn in een hiërarchische en statische 'boom'. Op zijn best is een DAG (directed acyclic graph) een alternatief. Als individu kan ik dan lid zijn van meerdere organisaties (O's) en meerdere organisatie-eenheden (OU's). Ik zou zo'n DAG echter niet graag willen beheren. De oplossing van Microsoft om een 'forest' van 'trees' aan te leggen in Active Directory is evenmin beheerbaar. Zeker niet wanneer tussen verschillende bedrijven een 'Trust' aangelegd moet worden omdat hun medewerkers moeten samenwerken.

De meest eenvoudige oplossing is om iedere gebruiker nieuw aan te maken in de hiërarchie. Dit betekent dat een individu meerdere identiteiten in de directoryservice heeft. Als gebruiker heb je single sign-on maar het betekent extra beheerproblemen. Verder moet automatische licentie- en softwaremetering snappen dat in de verschillende bomen dezelfde persoon zit en dat de licentie daarom maar één keer meegeteld moet worden. Omdat de directory voor ieder object een Globally Unique Identifier (GUID) aanmaakt is dat niet triviaal tenzij ik de enige "Jan de Vries" ben in de directory. Zonder spelfouten.

Daarom is het hiërarchische organisatiemodel dat ten grondslag ligt aan alle (van X.500 afgeleide) directoryservices achterhaald. Het komt niet overeen met de huidige praktijk in moderne organisaties en is een nachtmerrie om te beheren. In plaats van hogere informatiebeveiliging door eenduidige authenticatie en autorisatie krijgt het beheer te maken met meervoudige identiteiten en het 'bijeensprokkelen' van autorisaties door hetzelfde individu. Als gevolg zijn audit-trails en controle technische functiescheiding niet mogelijk.

Het is daarom terecht dat steeds meer organisaties hun directoryservice negeren.

Rob Mersel