Novells Netware, IBMs OS/2 Warp Server und Microsofts Windows NT Server, drei an sich vergleichbare, herstellerspezifische Netz-Betriebssysteme, verfolgen jeweils unterschiedliche Konzepte bei der Verwaltung von Ressourcen, Rechten und Benutzerprofilen.
Das wohl technisch ausgereifteste Directory dürfte Banyans "Streettalk" sein. Netzspezialisten zufolge ist es allen vorgenannten Systemen in bezug auf Technik und Administration weit überlegen.
Vom Domain-Konzept, wie es beim OS/2 Warp Server und Windows NT benutzt wird, sind die IT-Spezialisten diesbezüglich nicht so überzeugt. IBM und Microsoft verfolgen damit unterschiedliche, jeweils andere Ansätze als Novell. Unter Domain versteht man grundsätzlich klar voneinander abgegrenzte Verwaltungseinheiten, die aus logisch gruppierten Servern bestehen. Während bei den NDS die User-Accounts Servern zugeordnet sind, werden sie hier pro Domain eingerichtet. Der Benutzer muß sich nur einmal in eine Domain einwählen, dann stehen ihm entsprechend seiner Zugriffsberechtigung alle darin enthaltenen Ressourcen zur Verfügung. Ein zusätzliches Login auf einzelne Server innerhalb einer Domain ist nicht erforderlich.
Der OS/2 Warp Server beispielsweise arbeitet dabei mit kleinen Weiterleitungsprogrammen, sogenannten Aliases. Innerhalb einer Domain muß der Benutzer nur den Dateinamen eingeben - auf welchem Server das File liegt, ist für ihn unerheblich. Seine Anfrage geht an den Alias, der sie an den richtigen Server weiterleitet. Das Prinzip der Aliases kennt Windows NT nicht.
NT-Domains bestehen aus einem Primary Domain Controller (PDC) sowie einem oder mehreren Backup Domain Controllern (BDC). Die einer Domain zugeordneten Server, Clients und Benutzer werden als Accounts bezeichnet. Ein User-Account enthält beispielsweise Informationen über den Benutzer, die Gruppenzugehörigkeit und die Sicherheitspolitik.
Das Domain-Konzept hat unter anderem den Vorteil, daß sich eine komplette Domain wie ein einziger Server administrieren läßt. Der Nachteil liegt jedoch in der starken Abgrenzung der einzelnen Domains untereinander.
Mehrere Domain-Modelle stehen zur Wahl
Jede Domain muß einzeln verwaltet werden, ein Ressourcen-Sharing über die Grenzen der Server-Gruppen hinweg ist umständlich. Bei größeren Netzen kann dieses Sammelsurium an Domains zudem unübersichtlich werden.
Ein Unternehmen kann, in der Regel abhängig von seiner organisatorischen Struktur, zwischen verschiedenen Domain-Strukturen wählen. So wird beim Single-Domain-Modell das gesamte Netz zu einer Domain erklärt. Bei Windows NT 3.51 soll das Fassungsvermögen einer Domain bei bis zu 40000 Accounts liegen. Dieses Konzept bietet sich bei einer zentralen Netzwerk- und Systemadministration an, der die gesamte Ressourcenverwaltung obliegt. Allerdings müßte das Unternehmen hier bereit sein, auf ein ordentliches Namenskonzept zu verzichten, da als einziges Ordnungsmittel Gruppen zur Verfügung stehen. Der Domänenname selbst läßt keine Differenzierung zu.
Eine Sonderform der vorgenannten Variante ist das Single-Master-Domain-Modell. Während die gesamten Anwender weiterhin eine Verwaltungseinheit bleiben, werden für die Server eigene Domains kreiert. So können die lokalen Bereiche ihre Rechner unabhängig voneinander verwalten, die Administration der Benutzer steht jedoch nur der höheren Stelle zu, der Master-Domain. Dies bedeutet: zentrales Management der User, aber dezentrale Verwaltung der Server. Auf der Master-Domain werden nur die Daten der User vorgehalten.
Trusts verbinden einzelne Domains
Es lassen sich nach diesem Konzept auch mehrere Single-Master-Domains nebeneinander errichten, wobei die Master-Domains miteinander kommunizieren: Man spricht dann von einem Multiple-Master-Domain-Modell. Auf diese Weise legt man Master-Domains für einzelne Dienste, etwa den Mail-Service, an. Die Rede ist hierbei von Account- und Resource-Domains mit One-Way-Trusts. Backup-Domain-Controller werden hier zur Sicherung des Login ebenfalls eingesetzt.
Mit dem Multiple-Domain-Modell steht den Unternehmen eine weitere Spielart zur Verfügung. Jede Domain-Gruppierung besitzt einen eigenen Primary- sowie die erforderlichen Backup-Domain-Controller und wird separat administriert. Die Domains haben damit den Status eigener Netze, was bedeutet, daß der Administrator für die User, Server, Geräte etc. "seiner" Domain zuständig ist. Für die Anwender ist es die sogenannte Home-Domain.
Die Verbindung zwischen den einzelnen Domains wird mit Hilfe von Trusts realisiert. Sie regeln die Zugriffe zwischen Master- und Single-Domain sowie auch zwischen den einzelnen Bereichen einer Multiple-Domain-Struktur. Anwender, die einen User-Account für eine Domain besitzen, können so auch in anderen, "vertrauenden" Domains auf für sie freigegebene Ressourcen zugreifen, ohne daß dafür auf der Ziel-Domain ein neuer User-Account einzurichten ist.
Die Konfiguration solcher Trusts ist jedoch arbeitsaufwendig - vor allem, wenn es deren viele sind. Das liegt unter anderem daran, daß Trusts immer nur in eine Richtung wirken, für eine bidirektionale Verbindung also zwei Trusts zu konfigurieren sind. Hinzu kommt, daß eine Domain einer anderen erst einmal die Erlaubnis erteilen muß, ihr zu vertrauen, bevor ein Trust eingerichtet werden kann. Der große Nachteil aber ist, daß Trusts sich nicht vererben lassen. Wenn Domain A der Domain B und B der Domain C traut, bedeutet das noch lange nicht, daß A automatisch auch C traut - diese Verknüpfung muß vielmehr gesondert eingerichtet werden.
Ferner schlägt das Einrichten von Trusts fehl, wenn zum Zeitpunkt der Konfiguration zufällig eine Verbindung (zum Beispiel Share) zwischen den Servern besteht. Das ist um so ärgerlicher, weil das nicht immer zu einem offensichtlichen Fehler führt.
Bei einer Single-Master-Domain-Architektur besteht auch in bezug auf die Trusts eine gewisse zentrale Kontrolle. Anders sieht es dagegen bei den Multiple-Domain-Modellen aus. Man stelle sich vor, ein Unternehmen hat 15 Domains eingerichtet, die über bidirektionale Trust-Verbindungen gekoppelt sind. Jeder Administrator hat also bei einer kompletten Trust-Architektur von seiner Domain aus 14 Trusts zu anderen Domains gelegt. "Das Trust-Management kann zum Alptraum werden", weiß Wolfgang Schlegel, NT-Spezialist bei der Düsseldorfer Networks Unlimited AG. "Werden 210 Trusts manuell konfiguriert, sind dafür 420 Dialogboxen zu öffnen."
Die Kombination mehrerer Domains mit der dabei nahezu unvermeidlich hohen Zahl an Trusts macht die Administration eines so aufgebauten NT-Netzes nicht gerade zum Kinderspiel. Hinzu kommt, daß die Pflege der Gruppen und der Rechte das Zeitbudget eines Administrators kräftig belasten. Vor allem kann nicht davon ausgegangen werden, daß die bei der Einführung von NT implementierte Domain-Struktur auch den Anforderungen der Zukunft gerecht wird.
Für Unternehmen, die mit einem kleinen LAN unter Windows NT 3.51 ihre ersten Gehversuche in der NT-Welt machten, kann die Entscheidung für einen unternehmensweiten Einsatz von NT und MS-Exchange wieder nahezu den völligen Neubeginn bedeuten. Hat man anfangs auf multiple Domains gesetzt, sieht die Situation in Verbindung mit Exchange wieder anders aus. IT-Spezialisten empfehlen bei dieser Konfiguration eine stärker zentralisierte Infrastruktur, also entweder ein Single- oder ein Master-Domain-Modell. "Gehen Sie davon aus, daß Sie mit Exchange einiges über Domain-Planung lernen werden, an das Sie bei der Einführung von NT noch nicht gedacht haben", bemerkt Craig Dupler, DV-Experte bei einem US-Flugzeughersteller, bei einer Diskussion im Internet.
"Jedes Gebäude mit einem Server auszustatten und als eigene Domain zu definieren, würde die Sache sehr kostspielig und kompliziert machen", gibt Robert Greenlee von der Air Force zu bedenken, als er im Internet um Rat fragt, welche Domain-Struktur sich für die in fast 100 Gebäuden verteilten über 5000 künftigen Exchange-Anwender am besten eigne. Sein anfänglicher Plan war eine eigene Exchange-Domain, die mit den Domains, die das Mail-System nutzen, über Trusts kommuniziert. Ähnlich ist es auch im King County, Washington, gelöst. 8000 Anwender sollen hier bis Jahresende mit MS-Exchange ausgestattet werden. Dann will die Behörde die Services auf eine Master-Domain legen.
Fordert schon die tägliche NT-Administration den Verwalter, bereitet ihm die Umstellung der Domains nochmals besondere Mühe, denn die mit NT bereitgestellten Management-Funktionen eignen sich dafür nur bedingt. Zwar bietet die Gates-Company mit diversen Managern für User, Server, WINS und Druck, dem System Policy Editor oder dem Network Monitor eine breite Palette von Administrations-Tools - und wer damit allein nicht zurechtkommt, dem greift auch der integrierte Administration Wizard unter die Arme.
Doch die verbindende Schicht über den einzelnen Komponenten fehlt, für jede Aufgabe muß ein eigenes Tool aufgerufen werden. Hinzu kommt, daß die Netzadministration stark auf Domains ausgerichtet ist. Eine globale Sicht auf das Netz gibt es bei einer Multiple- oder Multiple-Master-Domain-Struktur nicht. Sicherheitsvorgaben, Benutzerprofile etc. werden jeweils nur pro Domain implementiert und überwacht. Einheitliche Vorgaben, etwa in bezug auf die Sicherheit, lassen sich nur mit großem Aufwand einhalten. Doch fehlt die zentrale Kontrolle, könnte praktisch jeder Netzadministrator für seine Domain beispielsweise eigene Benutzerprofile erstellen.
Will der Administrator eine effiziente Netzadministration, bleibt ihm nur der Griff zu Drittprodukten. Derer sind mittlerweile auch einige auf dem Markt, wovon die meisten das klassische Netz-Monitoring unterstützen. Bei speziell für die Administration entwickelten Produkten ist das Angebot dagegen vergleichsweise klein. Neben Microsofts "Directory Manager for Windows NT" und dem auf die Delegation von Administrationsaufgaben spezialisierten "Enterprise Administrator" des US-Herstellers Mission Critical Software findet sich nur noch "Final Enterprise Administration Services" der Networks Unlimited AG, Düsseldorf, auf den Web-Seiten von Microsoft.
Im Gegensatz zu den in Windows NT integrierten Administrations-Tools kann "Final" Informationen aus mehreren Domains lesen und verwerten. Auch in Multiple- oder Multiple-Master-Domains lassen sich so User-Profile, Sicherheitskonzepte etc. über das gesamte Netz hinweg einheitlich implementieren. Außerdem besteht die Möglichkeit, Administrationsaufgaben teilweise zu delegieren, ohne daß dazu die Rechte für die gesamte Domain abgegeben werden. So können die Nachteile einer Single-Domain-Architektur, nämlich die zentrale Administration, ausgeglichen werden. Die Software nutzt für die Management-Aufgaben Scripts, die einem Pascal-Dialekt sehr ähnlich sind. Eine Vielzahl einzelner Funktionen, die eine Aufgabe betreffen, etwa die Migration der Benutzer von einer Multiple- in eine Single-Domain-Architektur, lassen sich mit Hilfe dieser Sprache einfach kombinieren und auf wenige Befehle reduzieren. Der Administrator hat damit auch die Möglichkeit, Scripts für seine eigenen Belange zu erstellen. "Der Verwaltungsaufwand läßt sich so um bis zu 60 Prozent verringern", behauptet Networks Unlimited.
Selbst Microsoft-Geschäftsbereiche wie die Microsoft Consulting Services in Kanada greifen bei NT-Projekten auf Werkzeuge wie das des Düsseldorfer Anbieters zurück, die das Problem eines fehlenden zentralen Directory zwar nicht lösen, aber mildern können. Ein Directory-Service, der dem Vergleich mit Streettalk standhält, ist nicht vor Windows NT, Version 5.0, zu erwarten. Sollte Microsoft seine Ankündigung dann einlösen, bleibt dennoch ein Wermutstropfen: Die Verzeichnisdienste für MS-Exchange werden auch dann nicht integriert sein.
Angeklickt
Zentrales Element von Windows NT ist das Konzept der Domains. Ähnlich wie die Novell Directory Services dienen diese dazu, beispielsweise Zugriffsrechte oder Benutzernamen zu administrieren. Die Koordinierung mehrerer Domains unter NT muß über sogenannte Trusts stattfinden, was sich als sehr kompliziert erweisen kann.
*Stefanie Schneider ist freie Fachjournalistin in München.