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.