Auch wenn Microsoft für das Active Directory keine Versionsangaben führt - mit dem Windows.Net Server wird der Verzeichnisdienst funktional deutlich erweitert. Der Fokus liegt auf effizienterer Replikation und mehr Flexibilität, aber auch auf besserer Kompatibilität mit anderen Systemen. Das gilt auch für die anderen Infrastrukturdienste wie DNS.
Das Active Directory hat sich schon in seiner ersten Version durch ein durchdachtes Konzept ausgezeichnet und bewährt. Das heisst aber noch lange nicht, dass es nicht noch vieles zu verbessern gibt, und insbesondere gab es auch Schwächen, die sich erst in der breiten praktischen Nutzung zeigten.
Hier sind vor allem drei Punkte zu nennen: Zum einen haben viele Unternehmen Probleme damit, dass Forests Strukturen sind, die kaum integriert werden können. Das betrifft auf der einen Seite Situationen, in denen Unternehmen zugekauft und bestehende Active-Directory-Infrastrukturen miteinander integriert werden. Es betrifft aber auf der anderen Seite auch Situationen, in denen beispielsweise durch Zuständigkeitskonflikte innerhalb der IT-Organisation oder das Fehlen einer solchen zentralen Organisation mehrere Forests in einem Netzwerk entstanden sind, die nun integriert werden sollen.
Der zweite Problembereich ist die Kompatibilität mit anderen LDAP-Verzeichnisdiensten. Hier gibt es eine permanente Entwicklung, an die ein Verzeichnisdienst angepasst werden muss - formal den Kern-RFCs zu folgen, reicht hier nicht.
Der dritte Aspekt ist schliesslich die Replikation. Das beim Active Directory gewählte Konzept ist hier zwar in den meisten Fällen effizient. Insbesondere in sehr grossen Netzwerken haben sich aber auch Schwächen gezeigt. So kann beispielsweise ab rund 100 Standorten eine Replikationstopologie nicht mehr automatisch erzeugt werden. Solche Aspekte werden nun beim Windows.Net Server adressiert.
Das Active Directory arbeitet mit Forests, Domänen und organisatorischen Einheiten, um Netzwerke zu strukturieren. Die Domäne bildet dabei eine wichtige Struktur für Sicherheit und Administration. Berechtigungen vererben sich ebenso wie Gruppenrichtlinien und andere Einstellungen immer nur innerhalb einer Domäne, aber nicht über ihre Grenzen hinweg.
Gleichzeitig definiert die Domäne die Partitionen für die Active-Directory-Replikation. Ein Forest wiederum ist insofern von Bedeutung, als bei Windows 2000 die transitiven Vertrauensstellungen nur innerhalb eines Forest erzeugt werden. Vertrauensstellungen mit anderen Forests können nur direkt zwischen zwei Domänen erstellt werden und sind nicht transitiv.
Das ändert sich beim Windows.Net Server. Dort lassen sich auch Trusts zwischen Forests konfigurieren. Diese müssen explizit eingerichtet werden. Dafür wird die Anwendung Active Directory-Domänen und -Vertrauensstellungen verwendet. Durch einen solchen Trust entstehen transitive Vertrauensstellungen zwischen allen Domänen in beiden Forests. Benutzer der Domäne netzwerk.beratung.test.com können also auf Ressourcen der Domäne vertrieb.beispiel.de zugreifen, auch wenn die domänenbäumetest.com und beispiel.de in zwei getrennten Forests erstellt worden sind.
Allerdings können keine transitiven Trusts über mehrere Forests hinweg erzeugt werden. Wenn es also die Forests test.com, beispiel.de und demo.ch gibt, dann müssen gegebenenfalls drei Forest-Trusts eingerichtet werden.
Forest-Trusts können darüber hinaus einseitig oder zweiseitig definiert werden. Damit kann beispielsweise erreicht werden, dass Administratoren einer Konzernzentrale die Forests von Konzerngesellschaften mit verwalten, ohne dass in die andere Richtung Zugriffe möglich sind.
Für die Anmeldung können sowohl NTLM als auch Kerberos verwendet werden. Kerberos, das bei Windows 2000, Windows XP und beim Windows.Net Server unterstützt wird, ist dabei die effizientere Lösung, da der Kommunikationsaufwand geringer ist.
Die Inter-Forest-Kommunikation gibt Administratoren neue Gestaltungsmöglichkeiten für die Active-Directory-Umgebungen. Das Design des Active Directory wird ebenso erleichtert wie Migrationsprozesse in grösseren Umgebungen mit einer verteilten IT-Administration. Für Unternehmen, die noch nicht auf das Active Directory umgestellt haben, macht es Sinn, diese neuen Optionen in ihre Strukturierungsüberlegungen einzubeziehen.
Auch wenn das Active Directory schon in seiner jetzigen Form durchaus effiziente Replikationsmechanismen aufweist, gibt es doch noch Verbesserungsmöglichkeiten und
-bedarf. Gerade in sehr grossen Netzwerken gibt es einige Punkte, die zu einer relativ hohen Netzlast durch die Replikation führen können, auch wenn sie in kleineren und mittleren Umgebungen mit maximal wenigen tausend Benutzern kaum ins Gewicht fallen.
Ein Aspekt dabei ist die Berechnung der Inter-Site-Replikationstopologie. Beim Active Directory können und sollten Standorte konfiguriert werden, damit sowohl die Replikation des Active Directory als auch andere Dienste wie das DFS (Distributed File System) und der FRS (File Replication Service) WAN-Verbindungen so wenig wie möglich belasten. Das Active Directory berechnet dann über einen bei Windows 2000 als KCC (Knowledge Consistency Checker) bezeichneten Dienst die optimale Replikationstopologie für den Austausch von Active-Directory-Informationen zwischen verschiedenen Standorten. Dieser KCC hat aber den Nachteil, dass die Prozessor- und Speicheranforderungen der verwendeten Algorithmen exponentiell mit der Zahl der Sites steigen. Ab etwa 100 Standorten ist damit keine sinnvolle Berechnung der Replikationstopologie mehr möglich. Diese muss dann manuell konfiguriert werden.
Beim Windows.Net Server verwendet der nun als ISTG (Inter-Site Topology Generator) bezeichnete Dienst überarbeitete Algorithmen, die eine deutlich höhere Skalierbarkeit garantieren. Allerdings werden diese Algorithmen erst verwendet, wenn das komplette Netzwerk auf den Windows.Net Server umgestellt ist. Beim Windows.Net Server gibt es neben dem gemischten und dem einheitlichen Modus noch einen dritten Modus, in dem nur noch Windows.Net Server als Betriebssystem für Domänencontroller eingesetzt wird. Dieser wird derzeit zumeist als "Whistler Mode" bezeichnet, was sich aber noch ändern wird. In der vorliegenden Version kann die Umstellung nur über ntdsutil.exe erfolgen. Auch hier kann man davon ausgehen, dass es bis zur Final-Version noch Anpassungen geben wird.
Für viele Administratoren ist auch interessant, dass der Global Catalog in Domänen im einheitlichen Modus nicht mehr zwingend für die Anmeldung benötigt wird. Bisher musste an jedem Standort ein Global-Catalog-Server eingerichtet werden. Bei sehr grossen Netzwerken mit vielen kleinen Standorten mussten daher an jeden Standort Teilinformationen aller Domänen repliziert werden. Beim Windows.Net Server gibt es dagegen einen Cache für die Mitgliederlisten von universellen Gruppen. Dieser Cache kann auf Domänencontrollern explizit aktiviert werden. Die erforderlichen Informationen werden dann im Rahmen der normalen Replikationsprozesse an diesen Domänencontroller übertragen, so dass er immer auf dem aktuellen Stand ist und die vollständige Authentifizierung ohne Kontakt zu einem Global-Catalog-Server durchführen kann.
Optimiert wurde auch die Replikation von Gruppen. Bisher wird beim Hinzufügen oder Löschen von Mitgliedern in Gruppen die vollständige Liste aller Mitglieder an alle anderen Domänencontroller repliziert. Das führt bei grossen Gruppen mit vielen Mitgliedern zu einer erheblichen Replikationslast - man denke nur an eine Gruppe Domänen-Benutzer in einem Netzwerk, in dem einzelne Domänen schon mehrere tausend Mitglieder haben können. Beim Windows.Net Server werden im reinen "Whistler Mode" nur noch die Änderungen und nicht mehr die vollständigen Mitgliederlisten repliziert.
Reizvoll ist auch, dass bei der Einrichtung des Active Directory nun nicht mehr zwingend eine Vollinstallation erfolgen muss. Wenn dcpromo.exe, der Assistent für die Installation des Active Directory, im erweiterten Modus ausgeführt wird, können die Daten von einer Datensicherung gelesen werden. Diese werden dann im Rahmen der anschliessenden, regulären Replikationsprozesse aktualisiert. Das ist insbesondere für die Einrichtung von Domänencontrollern an entfernten Standorten und in grossen Netzwerken eine Erleichterung, weil bei einer Vollreplikation von grossen Active-Directory-Domänen unter Umständen sehr grosse Datenmengen übertragen werden müssen.
Die meisten Neuerungen bei der Replikation betreffen Details, haben aber dennoch für das Lastverhalten vor allem bei sehr grossen Netzwerken deutlich positive Auswirkungen.
Ebenfalls im Zusammenhang mit der Replikation steht eine weitere Neuerung. Das Active Directory unterstützt beim Windows.Net Server auch sogenannte Anwendungspartitionen. In diesen Partitionen können gezielt Daten von Anwendungen, die das Active Directory verwenden, gespeichert werden. Bisher werden diese Informationen, beispielsweise von einem Microsoft ISA Server oder einem Exchange Server, in den Domänen abgelegt.
Durch Verwendung der Anwendungspartitionen lassen sich die Objekte nun in einer gesonderten Partition speichern. Sie sind damit zum einen sauber getrennt. Zum anderen kann genau konfiguriert werden, auf welche Domänencontroller innerhalb eines Forest - nicht nur innerhalb einer Domäne - diese Informationen repliziert werden sollen.
Der Windows.Net Server wird diese Funktion beispielsweise für DHCP, RAS oder RADIUS unterstützen. Sie kann aber von Entwicklern auch für andere Anwendungen genutzt werden. Die einzige Einschränkung von Anwendungspartitionen ist, dass dort keine Security Principals, also für die Authentifizierung und Autorisierung verwendeten Objekte wie Benutzer, Gruppen und Computer, gespeichert werden können.
Wichtig ist auch, dass das Schema eines Forest weiterhin für die Anwendungen angepasst werden muss, auch wenn deren Informationen in einer gesonderten Anwendungspartition abgelegt werden.
Erweitert wurde auch die Kompatibilität mit anderen LDAP-Implementierungen. Eine wichtige Erweiterung ist dabei die Unterstützung der Klasse inetOrgPerson, die beispielsweise vom iPlanet Directory Server verwendet wird und mittlerweile auch im RFC 2798 definiert ist. Diese Klasse kann nun alternativ zur Klasse user eingesetzt werden. Damit lassen sich Informationen zwischen beispielsweise dem iPlanet Directory Server und dem Active Directory einfacher replizieren.
Unterstützt werden nun auch dynamische Einträge entsprechend dem RFC 2589, denen eine definierte Lebensdauer (TTL, Time to Live) zugewiesen ist. Auch TLS (Transport Layer Security) entsprechend dem RFC 2830, also der geschützte Zugriff auf das Active Directory, ist nun implementiert. Für die Rückgabe von grossen Ergebnislisten wird nun zudem der VLV (Virtual List View) unterstützt. Mit dem VLV kann ein Client Teile der Ergebnisliste anfordern, statt beispielsweise mehrere tausend gefundener Einträge geliefert zu bekommen.
Administratoren werden schliesslich die Speicherung von Abfragen schätzen. Damit können wiederkehrende Selektionen in einem Objekt im Active Directory abgelegt und jederzeit wieder aufgerufen werden.
Bei der DNS-Implementierung des Windows.Net Server wurde insbesondere die Vorgehensweise beim Hinzufügen von Domänen optimiert. Hier erfolgen nun umfassende Analysen, um sicherzustellen, dass neue Domänen korrekt zu DNS hinzugefügt werden können. Eine vergleichbare Unterstützung gibt es auch für das Hinzufügen neuer Computer zu einer Domäne. Falls es hier Probleme mit der DNS-Konfiguration gibt, wird explizit darauf hingewiesen.
Neu ist auch die grundlegende Unterstützung für die DNS-Sicherheitserweiterungen laut RFC 2535. Diese Erweiterungen erlauben es, dass ein DNS-Server auf Basis von Windows.Net Server als sekundärer Server für eine signierte DNS-Zone arbeiten kann. Allerdings kann er nicht als primärer Server für solche Zonen eingesetzt werden, da die Unterstützung des RFC nicht vollständig implementiert ist.
Interessant ist auch das bedingte Forwarding. Damit kann konfiguriert werden, welche DNS-Anfragen an welche DNS-Server weitergeleitet werden sollen. So können Anfragen nach .com an andere Server als solche nach .net geleitet werden. DNS-Strukturen lassen sich damit sehr viel flexibler als bisher gestalten.
Die grösste Bedeutung für Administratoren hat aber, dass DNS-Clients nun über Gruppenrichtlinien konfiguriert werden können. Damit lassen sich viele Einstellungen wie die zur dynamischen Registrierung einfach verwalten. Gleiches gilt auch für die Listen von unterstützten DNS-Suffixen, die auf Clients konfiguriert werden sollen.
Die wichtigste Erweiterung bei DHCP betrifft die Sicherung und Wiederherstellung. DHCP-Datenbanken können nun über eine grafische Oberfläche gesichert und wiederhergestellt werden. Die Sicherung kann auch im laufenden Betrieb erfolgen.
Bei anderen Diensten wie WINS oder dem RAS gibt es keine nennenswerten Erweiterungen. Aber schon die Anpassungen, die beim Active Directory vorgenommen wurden, lassen Vorfreude auf das Release des Windows.Net Server aufkommen, da sie einige zwar kleine Schwachstellen adressieren, die aber grosse Auswirkungen beispielsweise auf die Netzlast haben können.
