Microsofts Active Directory endlich flexibel

Windows Server 2003 soll am 13. Februar dieses Jahres in Produktion gehen. Dabei stehen nicht die grossen Innovationen im Mittelpunkt, sondern die vielen Verbesserungen in Details, die grosse Wirkung zeigen können.

Artikel erschienen in Swiss IT Magazine 2003/01

     

Windows Server 2003 soll am 13. Februar dieses Jahres in Produktion gehen. Er ist das, was man in der IT-Welt so gerne als "Major Release" bezeichnet. Dabei stehen aber nicht wie bei der Einführung von Windows 2000 Server die grossen Innovationen wie das Active Directory im Mittelpunkt, sondern die vielen Verbesserungen in Details. Manche dieser "kleinen" Änderungen können aber grosse Wirkung zeigen. Sie zeigen vor allem auch, dass Microsoft in den letzten drei Jahren einen Lernprozess durchgemacht hat. Windows Server 2003 ist von den praktischen Erfahrungen mit der Nutzung von Windows 2000 geprägt und profitiert von diesen.




Besonders deutlich wird das bei den Cross-Forest-Trusts im Active Directory. Mit dem Active Directory hatte Microsoft bei Windows 2000 das Konzept des Forest eingeführt. Ein Forest kann aus mehreren Domänenbäumen oder -strukturen bestehen. Ein Domänenbaum setzt sich wiederum aus einer oder mehreren hierarchisch geordneten Domänen zusammen. So kann es in einem Forest eines Konzerns beispielsweise die Domänenstruktur altefirma.ch und die Domänenstruktur gekauftefirma.ch geben. Die Struktur altefirma.ch kann dann weitere Domänen wie vertrieb.altefirma.ch und produktion.altefirma.ch enthalten. In einem Forest lassen sich damit in der Theorie die vollständigen Strukturen auch von komplexen Konzernen abbilden. Wenn da nur nicht der Unterschied zwischen Theorie und Praxis wäre…


Das Forest-Konzept unter der Lupe

Um diesen und den Sinn von Cross-Forest-Trusts verstehen zu können, muss man sich das Konzept von Forests und Domänen etwas näher betrachten. Die Domäne ist, historisch geprägt, die grundlegende Einheit im Active Directory. In einer Domäne werden Benutzer, Server und andere Objekte verwaltet. Benutzer melden sich an einer Domäne bei Domänencontrollern an und gehören immer genau zu einer Domäne. Wenn nun ein Benutzer - nennen wir ihn Martin - aus vertrieb.altefirma.ch auf Dateien auf einem Server von produktion.altefirma.ch zugreifen möchte, ergibt sich ein Problem. Denn der Benutzer Martin gehört zu vertrieb und nicht zu produktion. Er meldet sich bei vertrieb an. Wenn er nun auf Ressourcen bei produktion zugreifen möchte, muss er einerseits dort Zugriffsrechte haben, und andererseits müssen die Server bei produktion den Domänencontrollern bei vertrieb vertrauen. Sie vertrauen darauf, dass ein Benutzer aus vertrieb, wenn er bestimmte Informationen - sogenannte Tickets - vorweisen kann, sich erfolgreich bei einem dortigen Domänencontroller angemeldet hat. Es gibt also eine Vertrauensstellung zwischen vertrieb.altefirma.ch und produktion.altefirma.ch. Diese Vertrauensstellungen werden innerhalb eines Forest automatisch erstellt. So vertraut produktion dem vertrieb und umgekehrt. Ebenso gibt es eine Vertrauensstellung zwischen vertrieb.altefirma.ch und gekauftefirma.ch. Vertrauensstellungen werden zwischen allen Domänen in einem Forest, auch über die Grenzen von Domänenbäumen hinweg, automatisch erstellt.





Die Krux mit mehreren Forests

Wenn sich alles innerhalb eines Forest abspielt, ist damit unter dem Aspekt der Verwaltung alles in Butter. Nun gibt es aber viele Gründe dafür, dass es nicht nur einen Forest gibt. In vielen Unternehmen sind Netzwerke über Jahre gewachsen. Die Entwicklung hat ihr eigenes Netzwerk und will die Administration nicht aus der Hand geben. In der Finanzindustrie gibt es oft "chinese walls", mit denen eine Trennung begründet wird. Oder es wird ein weiteres Unternehmen hinzugekauft - und dann ist nocheinefirma.ch eben nicht nur eine weitere Domänenstruktur im Forest, sondern zunächst einmal ein weiterer Forest.



Ob es nun politische Gründe oder Mergers sind, das Ergebnis ist immer das gleiche: Es gibt mehr als einen Forest. Und während nun innerhalb eines Forest automatische Vertrauensstellungen erzeugt werden, geht das über die Grenzen von Forests hinweg nicht mehr. Bei Windows 2000 gibt es hier drei Lösungsansätze. Benutzer können mehrfach in verschiedenen Forests angelegt werden. Vertrauensstellungen können manuell zwischen jeweils zwei Domänen unterschiedlicher Forests definiert werden. Oder Informationen aus einem Forest lassen sich aufwendig in einen anderen Forest migrieren. Alle drei Ansätze für Forest-Vertrauensstellungen waren bis jetzt nicht ideal. Sie schaffen entweder einen deutlich höheren Verwaltungsaufwand oder sind nicht praktikabel, weil eben oft der eine, zentrale Forest nicht erwünscht ist.





Die erfreuliche Lösung

Mit den Cross-Forest-Trusts in Windows Server 2003 wird das Problem adressiert. Zwischen zwei Forests lassen sich nun Vertrauensstellungen definieren. Damit können Benutzer aus allen Domänen beispielsweise von altefirma.ch auch auf Ressourcen in nocheinefirma.ch zugreifen - entsprechende Zugriffsrechte vorausgesetzt. Das geht allerdings nur zwischen jeweils zwei Forests. Wenn es also die Forests A, B und C gibt und Forest A dem Forest B sowie Forest B dem Forest C vertraut, dann gibt es immer noch keine Vertrauensstellung zwischen Forest A und Forest C. Diese könnte aber explizit definiert werden.



Die Cross-Forest-Trusts erleichtern die Integration gewachsener Strukturen, ohne dass diese in einem gemeinsamen Forest zusammengeführt werden müssten - und erfüllen damit eine der wichtigsten Forderungen vieler Anwender. Denn in der Praxis gibt es eben oft nicht die zentrale Netzwerkstruktur, die sich in nur einem Forest abbilden lässt.




Interessant ist die Frage, wie es überhaupt zu dem ursprünglichen Forest-Konzept des Active Directory, wie es sich bei Windows 2000 findet, kommen konnte. Hier lassen sich drei Gründe nennen. Der erste ist der theoretische Fokus, den die Version 1.0 eines Produkts oft hat. Der zweite sind die historischen Wurzeln des Produkts. Der dritte ist, dass Microsoft sich beim Design des Active Directory mehr am Wettbewerb als am Anwender orientiert hat.



In der ersten Version des Active Directory fehlten noch die praktischen Erfahrungen. Microsoft selbst als erster Pilotanwender hat aber eine sehr zentralistische Struktur. Und viele der anderen Unternehmen, die schon in der Beta-Phase grosse Active-Directory-Installationen aufgesetzt hatten, waren IT-Unternehmen mit ebenfalls sehr stark zentralisierten Strukturen. Das, was in der Theorie und dem eng begrenzten Ausschnitt der Praxis funktionierte, liess sich aber nicht ohne weiteres auf die breite Masse der Unternehmen übertragen. Hinzu kommt, dass das Domänenkonzept schon gut zehn Jahre alt war, als das Active Directory auf den Markt kam. Aus Kompatibilitätsgründen mussten Ansätze wie die Domänen und Vertrauensstellungen übernommen werden, die überhaupt erst zu den Problemen geführt haben. Am interessantesten ist aber der dritte Grund: Das Active Directory war - und ist - gegen Novells NDS eDirectory positioniert. Da Novell aber 1999 keine Integration verschiedener NDS-Bäume unterstützt hat, findet sie sich auch im Active Directory von Windwos 2000 nicht.



Denn Microsoft hat beim Design des Active Directory weniger aus der Praxis der grossen Netzwerke gelernt als vielmehr von den kleineren LANs. Erst das Feedback der grossen, komplexen Installationen auf Basis von Windows 2000 hat dazu geführt, dass das Active Directory flexibler und praxistauglicher wird.



Artikel kommentieren
Kommentare werden vor der Freischaltung durch die Redaktion geprüft.

Anti-Spam-Frage: Wieviele Zwerge traf Schneewittchen im Wald?
GOLD SPONSOREN
SPONSOREN & PARTNER