next up previous contents
Next: Aufbau von individuellen Domänen/Gesamtstrukturen Up: Strukturdebatte Previous: Namensraum   Contents

Aufbau einer zentralen AD-Gesamtstruktur mit Subdomänen

Ausgehend von der Interpretation der Aufgabe entsteht in der ersten Variante im Universitätsrechenzentrum eine zentrale Windows Struktur die als globale Active Directory Wurzel aller Windows-Domänen dient, die im Campusnetz der TU Chemnitz betrieben werden sollen. In das Verzeichnis dieser Domain werden alle Nutzerkennzeichen des URZs automatisiert mittels des oben entworfenen Skripts und der Datenbereitstellung durch die MoUSE in ein entsprechend strukturiertes Textfile integriert.
Struktureinheiten, die eine eigene Windows-Domain betreiben wollen, integrieren diese als Subdomain in die vorhandene Gesamtstruktur, so dass ein Domänenbaum entsteht, dessen Wurzel die durch das URZ betriebene Domain darstellt. Durch diese Integration in die vorhandene Windows-Struktur entfalten sich über alle beteiligten Domänen Vertrauensstellungen, die einfach aus der Integration implizit entstehen. Zur Verkürzung des Trust-Paths bei der Zusammenarbeit mehrere Substrukturen können explizite Vertrauensstellungen diese Struktur noch untermauern.
Grafisch ist diese Variante nochmal in Abbildung 6.1 dargestellt, wobei die gestrichelten Linien, die impliziten Vertrauensstellungen andeuten.
Figure: Active Directory Baum mit Subdomänen
\resizebox*{0.3\textwidth}{0.4\textheight}{\includegraphics{images/DomBaum}} \resizebox*{0.3\textwidth}{0.35\textheight}{\includegraphics{images/DomBaum.eps}}

Um allerdings, die Bereitstellung der Nutzeraccounts zentral in der Wurzel zufriedenstellend durchführen zu können, wird es notwendig, Erweiterungen am bestehenden externen Kerberos-System vorzunehmen. Dabei sind zwei Wege denkbar, deren Realisierung einer genaueren Untersuchung bedürfen. Der eine wäre eine hausinterne Erweiterung des Heimdal-Servers, mit den Fähigkeiten der TGS-Request-Abarbeitung analog zum MIT-System, also der Zerlegung von Requests in deren Realm-Bestandteile und einer adäquaten Weitervermittlung aller TGS-Requests aus dem Windowsbaum an die Wurzeldomain der Windowsstruktur. Alternativ ist der Aufbau eines MIT-Kerberos als parallelen Dienst denkbar, wobei der Datenabgleich zwischen Heimdal und MIT automatisiert mittels der Werkzeuge beider Systeme erfolgen sollte. Es bliebe zu testen, ob ein Abgleich mittels Export der Kerberos-Datenbank im Heimdal und Import im MIT erfolgen kann, da eine Kommunikation beider Propagation-Daemons nicht funktioniert. Damit bliebe immer eine Verzögerung der Wirksamkeit von Änderungen bis zum nächsten Abgleich. Außerdem muss untersucht werden, ob die beiden Systeme nebeneinander als Server desselben Realms koexistieren können. In dem Falle der "`manuellen"' Abgleichs via Ex- und Import muss sichergestellt werden, dass über die Windows-Clienten keine Passwortänderung stattfindet, da diese auf den MIT ge- und beim nächsten Abgleich überschrieben würde.

Ebenso ist ein wesentlicher Faktor bei diesen Gedanken in dieser Arbeit nur beiläufig betrachtet worden, da es den Rahmen sprengte, und so bliebe es zu untersuchen, welche Auswirkungen entstünden und welche Bedingungen notwendig wären, um Schemata-Erweiterungen oder Änderungen durchzuführen. So ist bereits der Wunsch einer Struktureinheit einen Exchange-Server zu betreiben, damit verbunden, gesamtstrukturweit ein neues Schema durchzusetzen, was einerseits zum Zeitpunkt der Installation der Applikation der Synchronisation bedarf und danach der eventuell notwendigen Anpassungen durch alle Domainadmins.
Ergänzend sei zu erwähnen, dass ein Exchange-Dienst nur einmalig in einer Gesamtstruktur sein darf und dort nur einer Administrationsinstanz unterliegt. Somit sollte dieser Dienst in einer Gesamtstruktur zentral angeboten werden. Allerdings sind individuelle Anpassungen des Systems an Anforderungen der Struktureinheiten in der Folge nur noch in Absprache mit allen Nutzern und durch deren Zustimmung zufriedenstellend durchzusetzen. Aber Exchange dient im Rahmen dieser Arbeit nur als populäres Beispiel für viele andere Anwendungen, die ähnliche Anforderungen stellen. Im Extremfall bliebe es auch bei dieser Konstellation nicht aus, Insellösungen in einem eigenen Namensraum zu schaffen, um derartigen Anforderungen beziehungsweise Wünschen gerecht zu werden.

Als weiterer Aspekt, der einschränkend hinzukommt, sei aufgeführt, dass die Integration weiterer Domänen jeweils den Eingriff eines Domain-Administrators der hierarchisch übergeordneten Domäne erfordert. Dies ist ein einmaliger Aspekt im Rahmen der Einrichtung einer Domäne, sollte aber bedacht werden und wird daher in der Folge auch nochmals erwähnt.
Auch sollte bedacht sein, dass eine Einschränkung des Nutzerkreises eines beliebigen Windowsrechners in der Gesamtstruktur nur mehr physisch möglich ist, da sich auf dem Trust-Path bei der Anmeldung durch die zentrale Bereitstellung der Nutzeraccounts immer eine gültige Nutzerinstanz findet.

Vorteilhaft bei der genannten Konstellation ist allerdings diese einmalige zentrale Bereitstellung und Pflege der Nutzeraccounts, wobei diese dann auch noch durch einen gering gehaltenen Personenkreis mit den entsprechenden Privilegien erfolgt. Die Domain-Administratoren der angegliederten Substrukturen brauchen sich nur noch um die Verwaltung und Rechtevergabe der in ihren Domänen bereitgestellten Ressourcen kümmern. Auch wird dadurch sicher der Aktualität der entsprechenden Einträge besser Rechenschaft getragen.


next up previous contents
Next: Aufbau von individuellen Domänen/Gesamtstrukturen Up: Strukturdebatte Previous: Namensraum   Contents
Marko Damaschke 2006-03-25