Es folgt ein Test, der Funktionalität des
DNS-Servers. Wird sich für das Modell des statischen DNS´ mittels BIND
entschieden, kann der Hinweis zu den abgewiesenen dynamischen Updates
ignoriert werden, wird statt dessen mittels DNS-Forward in der
zentralen Konfiguration gearbeitet, empfiehlt sich die grundlegende
Installation eines neuen Domaincontrollers inklusive des Microsoft
DNS-Servers. Nach Anlegen des Active Directorys und dem Neustart des
Domaincontrollers ist die Domäne verfügbar. Bei diesem Neustart werden
gegebenenfalls auch die Einträge im dynamischen DNS für die Dienste
des Servers erzeugt.
In der Folge können die entsprechenden Nutzer angelegt werden,
entweder per Skript viele automatisiert oder manuell über das
MMC-SnapIn "`Active Directory Benutzer und Computer"', wobei zu
beachten ist, dass die Zuordnung zum entsprechenden Kerberos-Prinzipal
einzurichten ist. Dies ist erst nach Aktivierung der erweiterten
Funktionen im Menüpunkt "`Ansicht"' durch die Aktion
"`Namenszuordnungen"' im Tab "`Kerberos-Namen"' möglich. Das VBScript,
welches in grundlegenden Zügen im Anhang zu finden ist, richtet
Nutzeraccounts mit der entsprechenden Eigenschaftszuordnung im Active
Directory ein. Um dieses Skript sinnvoll nutzen zu können, ist eine
Bereitstellung der -Datei für den Domaincontroller lesbar
notwendig. Denkbar ist hierbei eine Bereitstellung im AFS, wobei dies
wahrscheinlich nur mittels IP-basierter Rechtevergabe sinnvoll möglich
ist. Welche Mechanismen angewandt werden, um eine Aufbereitung der
Daten aus der MoUSE und deren Bereitstellung im AFS zu realisieren,
wird hier nicht weiter betrachtet, da vergleichbare Implementierungen
bereits im URZ vorhanden und im Detail von der Entscheidung abhängig
sind, welche Daten zur Bereitstellung ausgewählt werden. Grundsätzlich
ist denkbar, diese Bereitstellung mittels eines Servers der
MoUSE-Umgebung mittels Cronjob umzusetzen. Auch auf den
Domaincontrollern ist mittels geplantem Task die Ausführung des
VBScripts möglich.
Außerdem sollte die Funktionsebene der Gesamtstruktur beziehungsweise
der Domäne an dieser Stelle festgelegt werden. Da alle Domänen in
diesem Konzept unabhängig sind, aber durch entsprechendes Heraufstufen
der Funktionsebene verbesserte Features der Systeme nutzbar werden,
sollte mindestens die Funktionsebene "`Windows 2000 pur"' gewählt
werden. Damit sind universelle Gruppen verwendbar, aber auch noch
Windows 2000 Domaincontroller einsetzbar. Ist auch dies nicht geplant,
kann beispielsweise durch noch weiteres heraufstufen der
Replikationsaufwand seitens des globalen Katalogs vermindert werden,
da ja unter Windows 2003 nur noch Änderungen propagiert werden.
Um diese Domäne als Dienst zu realisieren, muss weiterhin deren möglichst hohe Verfügbarkeit gesichert werden, um die Authentifizierung der angeschlossenen Clienten-Systeme, aber auch die sonstig durch die Domäne angebotenen Dienste zu gewährleisten. Für die Authentifizierung ist die Verfügbarkeit eines GC-Servers und eines Domaincontrollers der Domäne notwendig, an der sich ein Nutzer anmelden will. Daher ist es empfehlenswert, mehr als einen GC-Server und sowieso mehr als einen Domaincontroller zu betreiben. Der Grund, weshalb standardmäßig nur ein globaler Katalog innerhalb einer AD-Domain eingerichtet wird, kann in dem entstehenden Replikationsaufwand zwischen GC-Servern begründet liegen. Wenn allerdings durch die Sicherstellung einer breitbandigen Anbindung, wenn nicht gar durch die direkte Verbindung zweier Domaincontroller via der Redundanzverkabelung, die Menge des Netzwerkverkehrs zwischen diesen beiden wenig bis keine Rolle spielt, ist es mehr als sinnvoll, mehreren DCs die Funktion des globalen Katalogs zuzusprechen. Dazu muss im MMC-SnapIn "`Active Directory-Standorte und Dienste"' am Standort des Servers, in den NTDS-Settings des entsprechenden Servers der Haken im globalen Katalog gesetzt werden, wie in Abbildung 6.5 zu sehen.