|
|
||||||||||||||||||||||
|
BeschrijvingIn een NDS-directory worden gebruikers geplaatst in containers. In een personen administratie spreek je van afdelingen of groepen. In het programma worden deze indelingen gekoppeld dmv een index van groepnaam naar containernaam. Deze index vormt het eerste scharnierpunt tussen de twee hoofdbronnen. (NDS- en persoonsimport) Het tweede scharnierpunt is de sleutel die elke persoon dient te hebben. Deze sleutel is overgenomen in de directory, speciaal met het doel later personen aan nds-users te kunnen koppelen. In CUG worden de Dit geeft het volgende resultaat
Ook users die verkeerd geplaatst zijn in de nds zijn update-users. Een user is verkeerd geplaatst als wel een corresponderde persoon gevonden wordt, maar de groep/container index naar een andere container wijst dan waar de user zich in bevindt. (Ondersteuning van de zgn 'omzwaaier'-problematiek.)
In het algemeen kan je zeggen dat de lijst reguliere gebruikers zo groot mogelijk moet zijn. Als de andere lijsten - met name update - groot zijn, geeft dit aan dat de nds het persoonsbestand slecht volgt. Niet strikte matchingOnder bijzondere omstandigheden kan zelfs het sleutel-veld voor wijziging worden aangeboden. Als er een nds-user is bij de delete-users die in alles behalve de sleutel lijkt op een create-user (een zgn 'lookalike'), kan deze naar een update-user promoveren. De lijst delete-users wordt dan in feite gebruikt om de lijst create-users zo klein mogelijk te houden; als een soort prullenbak waarin naar believen gegraaid mag worden. CUG doet ahw het voorstel een user te wijzigen in plaats van er een te verwijderen en er een aan te maken. Een persoon in CUG heeft ook een userid attribuut. Het ook mogelijk met deze waarde een nds-user te zoeken die dezelfde object-name heeft. Dit is nuttig als van een groep gebruikers wel de userid bekend is, maar geen administratief nummer. Standaard staan deze werkingen uit. Bij een initialisatie of audit van een systeem kunnen ze echter nuttig zijn. |