Ausgehend von dem im vorherigen Kapitel beschriebenen Erfahrungen läßt
sich kurz bereits anfänglich sagen, dass es leider keine Lösung im Sinne
einer Beschreibung gibt, wie die Systemumgebung eingerichtet werden
muss, um ein Active Directory als Dienst anzubieten wie es in der
Intension der Aufgabenstellung liegt.
Wie im vorherigen Kapitel angesprochen, sind viele Punkte des
Vorhabens ein Active Directory als Dienst ohne massive Änderungen der
gegebenen Struktur erfüllbar, aber leider nicht alle.
Wie in der in 6.2 folgenden Diskussion klar werden soll, gibt es mehrere Varianten sich dem Ziel zum Einsatz eines Active Directorys zu nähern, wobei keine nachteilsfrei ist und somit es in diesem Kapitel um die Unterbreitung einer Diskussionsgrundlage geht, welche dann im URZ zu einer politischen Entscheidung führen soll, ob und wenn ja auf welchem Weg das Ziel verfolgt werden soll.
Es ist möglich, eine Einbindung des DNS in die vorhandene
BIND-Konfiguration vorzunehmen, sogar auf die Notwendigkeit eines
dynamischen Updates zu verzichten. Grundlage dafür sind die
Anmerkungen aus 5.5 und die Notwendigkeit durch eine
konsistente Konfiguration, die Abbildung zwischen Diensten, Servern
und Clienten sowie den jeweiligen IPs sicher zu stellen. Auf Grund
dessen konnten auch keinerlei Einschränkungen hinsichtlich des
Einsatzes von DHCP bisher ausfindig gemacht worden. Die Dienste werden
grundsätzlich auf Servernamen abgebildet und solange die Abbildung
zwischen Rechnernamen und IP-Nummern konsistent zur Vergabe mittels
DHCP bleibt, sprachen auch die Versuche nicht gegen einen Einsatz von
dynamisch zugewiesenen IPs. Besonderes Augenmerk sollte dabei aber
auch den "`forwarders"'- und "`NS"'-Einträgen in der
BIND-Konfiguration gewidmet werden.
Es ist ebenfalls möglich, eine Windows Active Directory Domain an
einen externen Kerberos-Dienst zu binden, solange in dieser Domäne für
die Bereitstellung entsprechend zugeordneter Nutzerobjekte Sorge
getragen wird. Dies funktioniert dank Cross-Realm-Trusts
beziehungsweise, wie es bei Windows genannt wird, Vertrauensstellungen
und einigen wenigen Einstellungen auf den Clientensystemen mit Windows
XP, Windows 2000 Professional und Windows 2003 als Betriebssystemen.
Ebenso funktioniert durch die Einrichtung expliziter oder impliziter
Vertrauensstellungen der domänenübergreifende Zugriff auf Ressourcen
fremder Dienstanbieter. Implizite Vertrauensstellungen entstehen
beispielsweise, wenn eine Domain in eine existierende Gesamtstruktur
eingegliedert wird, explizite werden im MMC-SnapIn "`Active Directory
Domänen und Vertrauensstellungen"' eingerichtet, so auch die zu einem
externen Kerberos-Realm.
Hingegen gibt es, wie bereits erwähnt, Einschränkungen beim Einsatz von
Heimdal-Kerberos als externen KDC. Darauf soll in der Folge des
Kapitels noch eingegangen werden.
Weiterhin stellen Gruppenrichtlinien und die Delegierung der
Einrichtung solcher an einfache Nutzeraccounts eine gute,
hierarchische Möglichkeit der Rechnerverwaltung und auch
Softwareverteilung zumindest einiger grundlegender Software, wie etwa
des OpenAFS-Clienten, welche dadurch unabhängig von ihrem eigenen
Dienst wird. Auch läßt sich vorstellen, kleineren Struktureinheiten
damit einen guten Mittelweg zur Systemadministration anbieten zu
können, indem die Clientenrechner grundlegend in der Verwaltung des
URZ verbleiben, aber zur spezialisierten Anpassung an Anforderungen
der Struktureinheit an einen versierten Nutzer dieser vermittelt
werden können. Dabei ist die Einrichtung einer OU denkbar, in der die
Rechneraccounts abgelegt werden und in der ein Nutzer der
Struktureinheit die entsprechenden Rechte zur Verwaltung erhält. Auch
dies soll in der Folge noch angesprochen werden.
Ebenso kann in Hinblick auf den Einsatz eines Active Directorys als Verzeichnisdienst mit LDAP-Schnittstelle ein positives Votum abgegeben werden. Einzig ist der Einsatz dahingehend zu bedenken, dass eine Erweiterung der Attribute eines Objekttypes die Erweiterung des Active Directory Schemas nach sich zieht. Dazu sei auf 6.1.1 verwiesen. Außerdem muss bedacht werden, dass eben nicht der Standardport für LDAP genutzt wird, sondern der des globalen Katalogs, was aber gegebenenfalls auch durch den Einsatz einer geschickten Firewallkonfiguration umgangen werden kann. So wäre denkbar, dass für einen Alias "`ldap.tu-chemnitz.de"' eine transparente Portumleitung von Port 389 auf Port 3268 erfolgt.