Red Hat hat im letzten Jahr einen zweistelligen Millionenbetrag investiert, um Netscape Enterprise Solutions samt ihrem Directory Server zu übernehmen. Knapp ein Jahr lang hat Red Hat die Software überarbeitet, bevor man Anfang Juni das fertige Produkt unter dem Namen Red Hat Directory Server vorgestellt hat. Und die Investition hat sich gelohnt.
Bereits vor dem Einstieg von Red Hat war der Directory-Server-Markt äusserst vielfältig durchsetzt. Zu den etablierten Anbietern gehören vor allem Novell, Microsoft, Sun, Siemens, IBM und CA. Diese haben bereits vor einigen Jahren durch das freie OpenLDAP eine gewichtige Konkurrenz erhalten, die vor allem im Low-End-Bereich grosse Erfolge für sich verbuchen kann. OpenLDAP basiert zwar auf der gleichen technischen Grundlage wie die Produkte von Sun und Red Hat. Diese haben sich aber bereits vor einigen Jahren voneinander weg bewegt. Während die meisten Linux-Distributionen auf das freie OpenLDAP setzen, gehen nun ausgerechnet die beiden grössten Distributoren andere Wege. Bei Novell war dies nicht anders zu erwarten, da mit dem eDirectory eine eigene Technologie im Haus existiert, die sowohl von der installierten Basis als auch von ihrer Funktionalität her eine führende Rolle am Markt einnimmt. Die Orientierung von Red Hat verwundert demgegenüber auf den ersten Blick einigermassen.
Der Einstieg von Novell als einem Anbieter aus dem Directory-Umfeld in den Open-Source-Bereich konnte an Red Hat nicht spurlos vorüber gehen. Die Relevanz von Verzeichnisdiensten für IT-Infrastrukturen rückte damit auch bei den Linux-Distributionen stärker ins Blickfeld. Red Hat nennt zwar offiziell keine Gründe. Intern werden aber Aspekte wie Release-Zyklen, die Administrationsschnittstellen, die Replikationsfunktionen, Performance und Skalierbarkeit als wichtige Aspekte genannt, warum sich Red Hat für das Investment in den neuen Directory Server und gegen das OpenLDAP-Projekt als Basis für die eigenen Bemühungen im Identity Management-Bereich entschieden hat. Dass man aber trotzdem auf die Stärken von Open Source nicht verzichten möchte, beweisst Red Hat, indem der Code komplett an das Fedora Projekt übergeben wurde, das bereits die Endanwender-Distribution von Red Hat (siehe Kasten «Ein Directory Server, zwei Namen») pflegt.
Das wichtigste nicht-technische Argument für die Entscheidung von Red Hat gegen OpenLDAP dürften die Release-Zyklen gewesen sein. Ein Blick auf die OpenLDAP-Roadmap zeigt, dass diese von den Anforderungen der professionellen IT weit entfernt ist. Schon die im Juni 2002 freigegebene Version 2.1 wird nicht mehr aktiv gepflegt – und über die für Ende 2005 geplante Version 2.4 hinaus werden keine Aussagen zur Fortentwicklung geliefert. Release-Zyklen von nur drei Jahren sind aber in Umgebungen, in denen Software auf Servern oft sieben bis zehn Jahre im Einsatz ist – wie derzeit gut an der immer noch grossen Windows-NT-Basis zu erkennen – nicht tragbar, ebenso wenig wie eine fehlende langfristige Release-Planung. Red Hat ist bei seinen Linux-Distributionen daher schon seit einiger Zeit dazu übergegangen, längere Zyklen für Updates und lange Support-Zyklen zu garantieren. Dieses Prinzip möchte man nun auch auf den Directory Server übertragen, was bei einem Produkt, das man selbst kontrolliert, wie es bei dem zweigeteilten Ansatz des Red Hat Directory Servers und entsprechender Unterstützung des Fedora-Projekts der Fall ist, wesentlich einfacher ist, als wenn die Kontrolle beim OpenLDAP-Projekt liegt.
Wenn man sich auf die technische Ebene begibt, zeigen sich deutliche Unterschiede zwischen dem Produkt von Red Hat und OpenLDAP. Das beginnt bei den Administrationsschnittstellen. Hier bietet der Red Hat Directory Server wesentlich mehr Möglichkeiten, weil er auch über eine grafische Administrationskomponente verfügt – neben Schnittstellen wie der Befehlszeile und der Nutzung von LDIF-Dateien. Solche Schnittstellen, die gerade auch für die Überwachung oder komplexere Aufgabenstellungen wie das Schema-Management wichtig sind, vermisst man bei OpenLDAP.
Gravierender sind aber zwei andere Unterschiede. Da sind zunächst die ACLs. Diese werden bei OpenLDAP in externen Textdateien verwaltet, während sie beim Red Hat Directory Server im Verzeichnis gehalten werden. Letzteres ist konsistenter und tendenziell auch sicherer, weil es ein «self contained»-Ansatz ist. Ausserdem ist der gewählte Ansatz über Makros effizienter als die OpenLDAP-Variante. Die relativ geringe historische Relevanz von ACLs bei OpenLDAP wird auch bei der Dokumentation deutlich, die das Thema sicher nicht in der gebührenden Tiefe abhandelt.
Die wohl wichtigste Einschränkung sind aber die Replikationsmechanismen. OpenLDAP unterstützt nur Client-initiierte und Master-Slave-Ansätze. Das reicht für viele praktische Anforderungen, bei denen oft schon aus Gründen der Verfügbarkeit mehrere Master vorhanden sein müssen, nicht aus. Für den Einsatz für das Benutzermanagement in lokalen Netzwerken mit mehreren Standorten und sehr vielen Abfragen ist das Konzept noch weniger geeignet, weil hier eben oft an mehreren Stellen administriert wird und häufig mehrere jeweils aktuelle Server für die Bearbeitung von Benutzeranforderungen erforderlich sind.
Der Red Hat Directory Server nutzt dagegen eine 4-Wege-Replikation. Das bedeutet, dass bis zu vier Master-Server konfiguriert werden können, an denen Änderungen durchgeführt werden. Diese werden auf die angeschlossenen Server – also die anderen Master und eine beliebige Zahl von «Slaves» – übernommen.
Ein weiterer Vorteil des Red Hat Directory Server ist die als Windows Sync bezeichnete Funktionalität, mit der Änderungen zwischen dem Red Hat Directory Server, dem Microsoft Active Directory und Windows-NT-Domänen bidirektional synchronisiert werden können. Es wird auch die Synchronisation von Kennwörtern unterstützt, was allerdings lokale Komponenten – sogenannte Password-Filter – auf den Windows-Domänencontrollern voraussetzt.
Auch sonst kann der Red Hat Directory Server durch eine beachtliche Fülle an Funktionen überzeugen, obwohl die Weiterentwicklung in den letzten Jahren sicher nicht so intensiv vorangetrieben wurde, wie es jetzt wieder der Fall sein wird.
Ohne OpenLDAP schlecht machen zu wollen – das Produkt hat als isoliertes Backend für einzelne Anwendungen und in kleinen Umgebungen durchaus seine Berechtigung – ist der Red Hat Directory Server eindeutig der bessere Open-Source-Verzeichnisdienst. Sowohl die technischen Funktionen als auch die Fokussierung auf den professionellen Markt sprechen für diese Lösung.
Red Hat sieht seine Wettbewerber denn auch eher im professionellen Markt, also bei Anbietern wie Novell, Sun und anderen. Hier hat man eine gute Basis geschaffen, die ihre Verwandschaft zu Produkten wie dem Sun Directory Server nicht verleugnen kann und damit für die Administratoren, die mit den Sun-, Netscape- oder iPlanet-Produkten vertraut sind, auch einfach zu beherrschen ist. Inwieweit es Red Hat aber gelingen wird, ausserhalb seiner etablierten Basis und des Verdrängungswettbewerbs gegen OpenLDAP im Markt der Verzeichnisdienste zu reüssieren, bleibt abzuwarten. Denn die anderen Anbieter sind schon lange im Markt zugange und haben ihre Produkte auch konsequent weiterentwickelt.
Red Hat geht bei ihrem Directory Server wie auch bei ihrer Linux-Distribution zweigleisig vor. Dies bedeutet, dass einerseits eine kommerzielle Version existiert, die unter dem Red-Hat-Brand mit Support und einigen anderen Service-Erweiterungen angeboten wird. Dies ist der Red Hat Directory Server. Andererseits ist unter dem Deckmantel des Fedora-Projekts, das bereits die Endanwender-Distribution von Red Hat betreut und einen Teil der Entwicklungsarbeit für den Enterprise Server leistet, eine Version des Directory Servers erhältlich, die unter
der GNU GPL steht. Dies ist dann
der Fedora Directory Server.
Die beiden Produkte unterscheiden abgesehen von den kommerziellen Services kaum. Einzig einige Komponenten wie die Administrationsschnittstellen sind
derzeit noch nicht Open Source.
Diese sollen aber auch noch freigegeben werden.
Natürlich gibt es neben Microsoft und Novell noch etliche andere Anbieter von Verzeichnisdiensten – einige wurden eingangs schon genannt. Microsoft und Novell sind aber insofern interessant, als ihr historischer Fokus die Authentifizierung von Clients in Netzwerken ist, einerseits im Windows- und andererseits im NetWare-Umfeld mit Windows-Clients. Daher bietet sich auch ein Seitenblick auf die Lösungen dieser Hersteller und deren Funktionalität an.
Sowohl das Microsoft Active Directory als auch Novells eDirectory unterstützen eine Multi-Master-Replikation mit einer beliebigen Zahl an Mastern. Damit lassen sich auch sehr komplexe Anforderungen unterstützen. Der Entwicklungsaufwand für solche Verfahren ist aber immens. Beide Systeme überzeugen auch durch eine Vielzahl an unterstützten, eng integrierten Authentifizierungsmechanismen, wobei Novell mit den NMAS (Novell Modular Authentication Services) insgesamt die weitreichendere Lösung zu bieten hat – vor allem auch, weil dort ebenfalls bald eine vollständige Kerberos-Unterstützung wie heute schon beim Active Directory verfügbar sein soll.
Auch die Sicherheitsfunktionen und Administrationsschnittstellen können überzeugen. Beide Verzeichnisdienste nutzen intensiv Vererbungskonzepte, um den Administrationsaufwand zu minimieren. Die Messlatte liegt damit hoch – vor allem beim eDirectory mit seiner breiten Plattformunterstützung und der Integration mit dem OES (Open Enterprise Server), der auch mit Suse Linux Enterprise Server (SLES) als Betriebssystem erhältlich ist.
