next up previous contents
Next: Anmerkungen zum Schema Up: Fazit Previous: Fazit   Contents

Allgemeines

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.



Subsections
next up previous contents
Next: Anmerkungen zum Schema Up: Fazit Previous: Fazit   Contents
Marko Damaschke 2006-03-25