CUG als hulpmiddel voor systeem-administratie

Inhoudsopgave

Inleiding
Doelgroep

Inleiding

Iedere organisatie heeft tegenwoordig persoonlijke email voor alle medewerkers. Achter deze eenvoudige zin gaan voor menig systeembeheerder heel wat hoofdbrekens schuil. Hoe komt hij er achter wie alle medewerkers zijn? Hoe vaak wil hij het gebruikersbestand bijwerken? Moet een nieuwe medewerker ook op andere systemen worden aangemaakt? etc. Meestal is het afdoende om een enkelvoudige aanvraag zorgvuldig te verwerken, maar naarmate het aantal gebruikers en het aantal variaties op het systeem groeit, wordt het beheren lastiger. Welke stappen zijn er nodig om een gebruiker netjes af te voeren? Moeten er misschien gegevens gewijzigd worden? etc.

De systeembeheerder zorgt voor primaire toegang tot de IT-voorzieningen. De medewerker wordt dan gebruiker van mail-, file-, print- en applicatiediensten. Daarnaast is ook binnen applicaties steeds vaker sprake van persoonsgebonden toegang. Het is de taak van een applicatiebeheerder om nieuwe personen met de juiste rechten als user aan te melden. Hiervoor heeft hij grofweg dezelfde gegevens nodig als de systeembeheerder, maar dan voor een speciale groep.

In de meeste organisaties is een afdeling personeelszaken verantwoordelijk voor de juistheid van deze gegevens. Voor ander soort gebruikers kan deze registratie ook door andere afdelingen gedaan worden; bijvoorbeeld een verkoop-afdeling in een e-business opzet, of een afdeling studentregistratie op een school. Het is in ieder geval zo dat het beheer van mail- en applicatie-accounts gekoppeld is aan een registratie van personen. Een systeem- of applicatie-beheerder maakt het niet veel uit wie deze registratie doet, als het maar duidelijk is wat met welke gegevens moet gebeuren. Vaak is het ook wenselijk dat gegevens in een bepaald formaat worden aangeleverd.

Ideaal gesproken verloopt het registreren van personen en het aanmaken/verwijderen van systeem-toegang in een vloeiend proces. In de praktijk is dit proces echter lastig in te richten. De verschillende partijen hebben sterk uiteenlopende werkwijzen en de taken waar het om gaat (registratie-nummers kopiƫren e.d.) horen vaak tot de minst interessante voor de betrokken medewerkers. Een andere complicerende factor is het voortdurend uitbreiden van applicaties die gebruik maken van persoonsgebonden toegang. Dit geeft aanleiding tot allerlei sub-protocollen en vage aftakkingen (' ... als dat gedaan is, moet je wachten tot je hoort van die en die voordat je verder gaat met...').

Wat zo simpel leek: iedereen een persoonlijke systeem-account geven, is gaandeweg onoverzichtelijk geworden.

CUG dient als hulpmiddel om deze complexiteit beheersbaar te houden. Het doet dit door:

  1. De verhouding tussen een account-bestand en een personen-bestand te reguleren

    CUG maakt het mogelijk periodiek een vergelijking van deze bestanden te doen. Als de bestanden compleet worden aangeboden komt dan in de CUG-database een actuele momentopname te staan van welke persoon bij welke gebruiker hoort. Ook zijn er CREATE/DELETE/UPDATE sets aangemaakt.

    Het is de bedoeling hiermee het account-bestand te wijzigen. Het personen-bestand leidt het account-bestand. Het account-bestand waar het hier om gaat, is het primaire account-bestand (enterprise directory). Het kan op zijn beurt weer andere (applicatie) account-bestanden leiden. CUG is gemaakt voor een omgeving met een NDS als primair account-bestand.

  2. Zinvolle selecties mogelijk te maken op de gegevens uit deze bestanden.

    Denk bijvoorbeeld aan: 'alle nieuwe gebruikers uit die en die afdeling'; 'alle te verwijderen gebruikers voor die en die container' etc.

  3. Flexibele rapportages te bieden op deze selecties.

    Hiermee worden onder andere tekst-tabellen met verschillende kolomvolgorden bedoeld.

Belangrijk

CUG gaat er van uit dat het gemakkelijk is om een totaal-overzicht op te vragen van de accounts en de persoonsregistraties.

CUG is ontwikkeld met het idee dat het niet mogelijk is de complexiteit van dit proces geheel en al op te heffen (no silver bullet). Het mag echter niet zo zijn dat het opvragen van consistente gegevens uit beide bestanden een struikelblok wordt. Men moet zich kunnen concentreren op het vaststellen van protocollen cq maken van afspraken. CUG levert een solide koppeling tussen persoon en account die dit gemakkelijker maakt.

Figuur 1. Koppeling persoon / account

In dit diagram zijn de basis-attributen van beide entiteiten afgebeeld. De koppeling is aangegeven met pijlen; een stippellijn geeft aan dat er een regel gehanteerd wordt voor de koppeling; bijvoorbeeld de regel 'eerste twee voorletters en vier letters van de achternaam' om een CN[1] te maken van de naam van een persoon.

CUG is bedoeld als bouwsteen om een proces te ondersteunen. CUG wordt geconfigureerd en kan dan zonder verdere tussenkomst van een gebruiker de momentopname periodiek bijwerken. Om die reden is er geen prioriteit gegeven aan een grafische user interface bij CUG. Voor statische instellingen wordt gebruik gemaakt van java properties-files.

Meer dynamische situatie-gebonden instellingen zoals regels die gehanteerd worden voor de inrichting van het systeem (de NDS) en de manier waarop CUG de input-data verwerkt dienen per organisatie in java gecodeerd te worden.

Om flexibel te blijven moet CUG open en uitbreidbaar zijn, met name aan de rapportagekant. In eerste instantie gebruik je hiervoor weer java, CUG is dan zoiets als een gereedschapskist voor accountbeheer.



[1] CN is een afkorting voor common name. Hiermee wordt de 1ste systeemnaam van een persoon bedoeld, ook wel de loginnaam of userid. In een NDS is dit een woord zonder spaties.

Een DN (distinguished name) is een concatenatie van de CN en de container-naam. Een DN is de unieke aanduiding van elke user in een directory.