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
, , und , 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 verknüpften effektiv nur die letzte
Zeile mit Auswirkungen genutzt wird. Diese Zeile soll eine
kommaseparierte Liste aller Nutzerkennzeichen enthalten, die in die
in 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 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
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
abgelegt ist. "`Vor-"'
und "`Nachname"' sollten sich selbst erklären, Titel ist ein
eventueller Titel der Person, welcher in der -Relation zu
finden ist. Unter "`Struktur"' wäre ein kommaseparierter String der
Strukturnamen aus der -Relation und einer rekursiven
Auswertung des
-Attributes, vergleichbar der
Verwendung der Struktur-Anzeige bei [MoU05], sinnvoll. Das
Feld "`Mail"' enthält den primären Mailalias des Nutzers aus den
Relationen und . 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 -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
-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 -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 -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.