next up previous contents
Next: Gruppenarten und Arbeiten mit Up: Lösungsideen und Alternativen Previous: Anmerkung zu OpenAFS &   Contents

Benutzerverwaltung

Ein Benutzerobjekt in einer Domäne kann natürlich über das GUI eines Domaincontrollers unter dem MMC "`Active Directory Benutzer und Computer"' angelegt werden. Da im Rahmen dieser Arbeit einerseits aber hunderte beziehungsweise mehrere Tausend solcher Nutzerobjekte gepflegt werden sollen, die andererseits wieder nicht mit Werkzeugen des Active Directorys sondern in der MoUSE verwaltet und nur in die Sphären des Active Directorys übernommen werden sollen, muss diese Übernahme natürlich automatisiert und sicher erfolgen, um den Betreuungsaufwand zu minimieren.

Neben dem genannten GUI gibt es verschiedene Wege auf das AD zuzugreifen, die bereits im Theorieteil angesprochen wurden. Dabei ist zu beachten, dass die LDAP-Schnittstelle nicht mächtig genug ist, da sicherheitsrelevante Attribute, wie etwa das Passwort, in der Verwaltung des SAMs (Security Account Manager) stehen und der Zugriff auf solche Elemente verweigert wird.
Somit blieb nur die Betrachtung mittels der "`ds"'-Werkzeuge auf der Kommandozeile oder mittels VB-Scripte. Die "`ds"'-Werkzeuge, also $dsadd$, $dsmod$, $dsquery$ und $dsdel$, erlauben die Manipulation vom Objekten des Directory Services (daher sicher auch das "`ds"' in den Namen). Aber in der Implementierung der Werkzeuge ist nicht nur die Auswahl der Objekte, sondern dann auch wiederum deren Auswahl an Attributen festgelegt, die bearbeitet werden können. Da ein Attribut des Benutzerobjektes benötigt wird, welches nicht in der Standardauswahl der "`ds"'-Werkzeuge enthalten ist, nämlich die Zuordnung eines Kerberos-Prinzipals, ist auch deren Einsatz zum Datenabgleich mit den Daten der MoUSE nicht möglich.
Dem entsprechend bleibt nur der Einsatz eines VB-Scripts, welches den Zugriff auf alle notwendigen Benutzerattribute gewährt und die Daten aus einer definierten Quelle einliest.

Die Liste der Attribute eines Benutzerobjektes kann dem Schema der jeweiligen Gesamtstruktur entnommen werden. Dort muss auch eine entsprechende Anpassung stattfinden, sollten weitere Attribute, neue Objekte oder strukturelle Anpassungen des Schemas gewünscht werden. Eine Auflistung der Standardobjekte findet sich unter anderem aber auch zusammengetragen von Sakari Kouti und Mika Seitsonen für ihr Buch "`Inside Active Directory"' auf [Act01]. An dieser Stelle sei nur eine Liste der notwendigen, für sinnvoll aus der Quelle MoUSE ermittelbaren und derzeit nicht sinnvoll zentral bereitstellbaren Attribute genannt:

Ausgehend von dieser Zusammenstellung wurde mit Hilfe von [Wel05] und [All03] ein Entwurf gemacht, wie eine Datenübernahme von Daten der MoUSE in das Active Directory eines Domaincontrollers automatisiert erfolgen kann. Inspiration lieferte dazu neben [Coo03], [Tul04] und [Act05] auch [it-03]. Jedoch waren dies alles grundlegende Aktionen, die auf die Notwendigkeiten der lokalen Umgebung anzupassen waren. Somit entstand das Skript, welches im Anhang B.1 zu finden ist.

Dabei werden anfangs 2 Textdateien eingelesen, wobei von der ersten, mit der Konstanten $LOKNUTZER$ verknüpften effektiv nur die letzte Zeile mit Auswirkungen genutzt wird. Diese Zeile soll eine kommaseparierte Liste aller Nutzerkennzeichen enthalten, die in die in $DOMAIN$ festgelegte Domäne aufgenommen werden sollen. Somit kann das Skript auch in Subdomänen genutzt werden und dort auch die Auswahl der Nutzer einschränken. Auf Grund der Skriptstruktur werden alle anderen Zeilen der Datei ignoriert. Eine besondere Wirkung hat das Wort "`all"', welches allein auf der letzten Zeile stehen sollte und damit alle Nutzerkennzeichen zur Integration vorsieht. Die zweite Datei, welche mit der Konstanten $NUTZER$ verknüpft ist, wird zeilenweise eingelesen und ausgewertet und enthält eine Auflistung aller Nutzer mit den entsprechenden Attributen. Erwartet wird eine Textdatei, die pro Zeile einen Nutzer in der Struktur $NKZ:Nachname:Vorname:Titel:Struktur:Mail:Telefon:Fax:Raum:Gruppe$ enthält. Wie ersichtlich, wird der Doppelpunkt als Separator zwischen den Feldern genutzt. Unter "`NKZ"' versteht sich das Nutzerkennzeichen, welches dem User-Bestandteil des Kerberosprinzipals entspricht und in der MoUSE in der Relation $nutzerkennzeichen$ abgelegt ist. "`Vor-"' und "`Nachname"' sollten sich selbst erklären, Titel ist ein eventueller Titel der Person, welcher in der $person$-Relation zu finden ist. Unter "`Struktur"' wäre ein kommaseparierter String der Strukturnamen aus der $struktur$-Relation und einer rekursiven Auswertung des $struktur\_parent$-Attributes, vergleichbar der Verwendung der Struktur-Anzeige bei [MoU05], sinnvoll. Das Feld "`Mail"' enthält den primären Mailalias des Nutzers aus den Relationen $mailalias$ und $mailadr$. Die Felder "`Telefon"', "`Fax"' und "`Raum"' können entsprechend der Datenbereitstellung durch die MoUSE bei Mitarbeitern die entsprechenden Informationen enthalten. Eine Bereitstellung dieser Daten ist angesichts der starken Integration des Active Directorys in das Windows-System sicher sinnvoll, da beispielsweise die Suchfunktion jedes Domänen-Rechners darüber die Suche nach Personen zuläßt und diese mit echtem Mehrwert für den Windowsnutzer eingesetzt werden kann. Somit kann ein Windows-Mailprogramm, wie Outlook, seine Adreßbücher pflegen oder ein Student seinen Dozenten ohne Umweg auf dessen Homepage finden. Die entsprechenden Daten sind in der $person$-Relation abgelegt. Ihre Aktualität sollte sich vor allem im Kontext der VoIP-Einführung erhöhen lassen.
Das Feld "`Gruppe"' wird durch das Skript auf eine OU-Hierarchie innerhalb des Active Directorys abgebildet. Dabei ist die Hierarchie innerhalb des Feldes von der Wurzel zum Blatt abgebildet und wird durch "`_"' separiert. Also "`Studenten_Informatik"' wird auf eine OU "`Informatik"' abgebildet, welche in einer OU "`Studenten"' liegt, die Bestandteil der Domäne ist. Diese OUs müssen bestehen, werden also nicht durch das angefügte Skript erzeugt. Sicher läßt sich durch einfaches Erweitern der Skriptfunktionalität solches erreichen. Dazu müsste der DN des Zielobjektes zerlegt werden und die letzte existente Hierarchie-Ebene als Container connectet und darin die entsprechend nächste Ebene als OU-Objekt erzeugt werden. Dies gibt das aktuelle Skript nicht her, verhindert damit aber wildes Wachstum des Baumes beispielsweise durch Tippfehler.

Für jede Zeile dieser zweiten Datei findet nun ein Abgleich statt, ob der Nutzer dieser Zeile in die Domäne integriert werden soll. Ist dies der Fall, wird in der Domäne nach dem Nutzer gesucht, um zu entscheiden, ob er neu angelegt oder nur gegebenenfalls aktualisiert werden muss. Ist er neu in der Domain, wird er mit seinen Attributen und einigen Standardwerten angelegt. Dabei ist zu beachten, dass ein Nutzerkennzeichen, Vor- und Nachname erwartet werden und bei Fehlen zu Abbrüchen des Skripts führen, während alle anderen Attribute optional sind. Hier wäre nötigenfalls eine weitere Verbesserung des Skripts vorzunehmen - allerdings sollten diese Informationen eines jeden Nutzers vorhanden sein. Einige Attribute sind auskommentiert, ließen aber beispielsweise Standardwerte eintragen, was mit dem Gedanken einer universitätsübergreifenden Nutzung der Daten in Zukunft interessant werden könnte. Auch wird derzeit ein festes Passwort für alle Accounts eingetragen, was nicht sicher ist und verbessert werden sollte - beispielsweise durch einen Passwortgenerator. Ein Beispiel, wie ein solcher Generator in VBScript aussehen könnte, wird auch auf [faq05] vorgestellt, aber hier wäre beispielsweise auch ein externes Generieren und eine Übergabe in der $NUTZER$-Datei denkbar. Gebraucht wird das Passwort nicht, da ja gegen Kerberos zu authentifizieren ist. Außerdem werden noch einige Attribute gesetzt, die mit der Alterung des Passworts in Zusammenhang stehen, welches bei Windows per default eingestellt ist.
Ein Attribut, welches noch interessant sein könnte, hier aber noch nicht einfloss, ist "`accountExpires"', welches ein Ablaufdatum für den Account enthält. Dessen Nutzung setzt aber eine 64Bit-LongInt Zahl als Ablaufdatum voraus, deren Verwendung auf [ADT06] erklärt wird. Solange die Gültigkeit der Kerberos-Einträge beschränkt ist, wirkt sich dies indirekt auch auf die Windows-Einträge aus. Es wäre auch denkbar, zu löschende Einträge im $NUTZER$-File einzuführen und zu verarbeiten. Alternativ ist vorstellbar, während der Abarbeitung die durch die Files für die Domäne vorgesehenen Accounts in einem String zu vermerken und diesen am Ende des Skripts mit dem tatsächlichen Bestand aller Accounts in der Domäne abzugleichen und gegebenenfalls "`ÜberschÃ14ssige"' zu löschen. Dies sollte in der Folge der Arbeit genauer betrachtet werden.
Ist hingegen der Nutzer bereits in der Domain gefunden worden, wird als erstes ein Abgleich hinsichtlich des Objektortes gemacht, was beispielsweise bei einem Studiengangwechsel oder dem Übergang vom Studentendasein in ein Mitarbeiterverhältnis denkbar wäre. Stimmt der bisherige Ort nicht mit dem erwarteten überein, wird das Objekt verschoben und an den erwarteten gebracht. Ist das Objekt am erwarteten Ort im Verzeichnis, werden die übergegebenen Attribute mit den derzeit im Objekt abgelegten verglichen und gegebenenfalls aktualisiert. Die mit Standardwerten bei der Einrichtung der Nutzer belegten bleiben außen vor, da deren Änderung nicht automatisch erfolgen sollte. Wird ein Attribut aus dem $NUTZER$-File entfernt, wird es im AD mit einem einzelnen Leerzeichen ersetzt, da es keine adäquate Löschfunktion für Objektattribute gibt.

Mittels des angefügten Skripts wurden in der Domäne der Teststellung 10000 Nutzer angelegt, was eine Ausführungsdauer von circa 28 Minuten mit sich brachte. Die spätere Aktualisierung beliebiger dieser 10000 Nutzeraccounts mittels des Skriptes erfolgte in weniger als 5 Minuten je Durchlauf. Also sowohl die einmalige Einrichtung aller Nutzeraccounts als auch ein tägliches oder noch häufigeres Update des Datenbestands ist in vertretbarer Zeit mit dem Skript realisierbar.


next up previous contents
Next: Gruppenarten und Arbeiten mit Up: Lösungsideen und Alternativen Previous: Anmerkung zu OpenAFS &   Contents
Marko Damaschke 2006-03-25