Red Hat zündet mit dem Directory Server auf einer Basis aus altem Netscape-Code einen Treibsatz in Richtung Enterprise-Markt. Auch das Fedora-Projekt bekommt in Sachen LDAP-Verzeichnisdienste gut Schub.

Red Hat hatte im September 2004 von AOL die Technologien (und Entwickler) des früheren Netscape Directory Server übernommen. Inzwischen sind mit Red Hat Directory Server [1] und Fedora Directory Server [2] Ergebnisse sichtbar. Die Entscheidung, eine Verzeichnisdienst-Technik zu lizenzieren, dürfte von der Übernahme von Suse durch Novell beeinflusst worden sein.

Novell ist mit seinem E-Directory ([3], [4], [5]) seit Jahren einer der Markt- und Technologieführer in diesem Segment. Da Directories für ein zentrales Sicherheitsmanagement in größeren Netzwerken unverzichtbar sind, musste Red Hat wohl nachziehen. Das Resultat liegt nun als Red Hat Directory Server vor. – zu Preisen ab 14000 Euro. Zusätzlich zu diesem gibt es eine passende PKI-Lösung (siehe Kasten “Red Hat Certificate System”).

Parallel dazu übergaben die Rothüte den Directory Server an das Fedora-Projekt, wo er als Fedora Directory Server firmiert. Doch ist derzeit nur der eigentliche Servercode Open Source. Die fehlenden administrativen Schnittstellen (siehe weiter unten) sollen aber bald folgen. Damit gibt es neben OpenLDAP ein zweites großes Open-Source-Projekt für Directory Server. Novell hat sein E-Directory dagegen bisher nicht zu Open Source gemacht. Nur einige Schnittstellen zum System hatte die Firma unlängst offen gelegt. Eine weiter gehende Befreiung ist kurzfristig kaum zu erwarten.

Eine Enterprise-Mission

Der Directory Server ruht auf dem gleichen technischen Fundament wie der Sun Directory Server, beide entwickeln sich aber seit Jahren auseinander. Red Hat will einen Verzeichnisdienstes für Unternehmen schaffen, den möglichst viele Anwendungen als Speicher für Identitätsdaten und für die Benutzerauthentifizierung einsetzen.

Das Fedora-Projekt nennt die technologische Marktführerschaft bei Zuverlässigkeit und Interoperabilität als Ziel. Red Hat selbst verspricht sogar den “Most scalable and reliable identity store”. Das sind hehre Ziele, an denen sich das Produkt messen lassen muss. Die technische Basis, die von Netscape über AOL nun bei Red Hat ankam, liefert zwar eine gute Grundlage, aber auch die Konkurrenz hat in den letzten Jahren nicht geschlafen. Zunächst ist der Red Hat Directory Server schlicht ein LDAPv3-Server – davon gibt es einige am Markt (weitere Schnittstellen siehe unten).

Die detailliertere Featureliste des Produkts, so viel sei bereits vorab gesagt, bietet im Vergleich mit den anderen führenden Verzeichnisdiensten kaum Highlights, die eine von Red Hat und Fedora kolportierte Alleinstellung des Produkts zu stützen vermag. Dass die wichtigsten LDAP-RFCs sowohl für LDAPv2 als auch für LDAPv3 unterstützt werden, versteht sich wohl von selbst.

Funktionen wie LDAPv3-Referrals, die Anforderungen an andere Verzeichnisse weiterleiten können, sind ebenfalls Standard. Abgesehen davon sind Referrals kein sonderlich effizienter Weg, um Informationen in mehrere Verzeichnisdienste zu integrieren, denn eine solche Weiterleitung hat immer das Verarbeiten von Anfragen auf jedem beteiligten System zur Folge.

Keine Rennmaschine, skaliert aber gut

Die von Red Hat ins Feld geführte hohe Performance konnte ein erster Test nicht nachvollziehen. Die technische Architektur des Produkts, die der des Sun Directory Server ja sehr ähnlich ist, verspricht andererseits eine gute Skalierbarkeit. Die Möglichkeit, Daten über mehrere Server hinweg zu partitionieren, die Unterstützung von SMP-Systemen und die 64-Bit-Plattformen Solaris und HP-UX stützen diese Einschätzung. Überraschend ist allerdings, dass es zumindest in der aktuellen Release noch keine 64-Bit-Unterstützung für Intel- und AMD-Prozessoren unter Linux gibt.

4-Wege-Replikation

Eins der technisch reizvollsten Dinge bei Verzeichnisdiensten ist die Replikation. Der Red Hat Directory Server unterstützt eine Vier-Wege-Multi-Master-Replikation. Das bedeutet im Klartext, dass maximal vier Server Änderungen parallel durchführen – im Gegensatz zu einer n-Wege-Multi-Master-Replikation, wie sie etwa Novells E-Directory, Microsofts Active Directory oder das CA E-Trust Directory beherrschen.

Das ist nicht zwingend eine Einschränkung. Vielerorts reicht ein solches Vier-Server-Konzept aus, das darüber hinaus die selektive Replikation von Teilinformationen unterstützt. Bei Anwendungs- oder Unternehmensverzeichnissen sowie den meisten E-Business-Verzeichnisdiensten gibt es relativ wenige Instanzen der Verzeichnisse, die miteinander zu replizieren sind.

Anders sieht es bei Directories aus, gegen die sich die Benutzer authentifizieren. Hier entehen oft sehr viele Instanzen. In diesem Bereich, in dem beispielsweise das Novell E-Directory seine Stärken hat, stößt das Replikationskonzept des Red Hat Directory Server an Grenzen. Dann wollen die Platzierung von Servern und die Replikation genau geplant sein.

Viele Instanzen, mehrere Schnittstellen

Dass der Red Hat Directory Server mehrere Datenbanken benutzen kann, Änderungen transaktional verarbeitet und mehrere Verzeichnisse auf einem Server anlegt, ist sehr positiv zu werten. Mehrere Verzeichnisse pro Server halten zu können ist bei Anwendungsverzeichnissen wichtig, die gern inflationär viele benutzen. Novells E-Directory wird eine vergleichbare Funktionalität erst mit der derzeit in der Betaphase befindlichen Release 8.8 anbieten.

Auf den Server lässt sich nicht nur per LDAP, sondern auch mit DSMLv2 (Directory Service Markup Language) zugreifen. Der XML-basierte Standard gewinnt immer mehr an Gewicht, weil er in vielen Fällen einfacher zu implementieren ist als LDAP-Zugriffe. Darüber hinaus besitzt der Server mehrere Entwicklerschnittstellen, um zum Beispiel Anwendungen durch Verzeichnisänderungen zu triggern oder alternative Authentifizierungsmechanismen zu etablieren.

Auch die Schnittstellen für das Management, den Zugriff und die Erweiterung des Systems konnten im Test überzeugen: Der Red Hat Directory Server unterstützt SNMP für die Weiterleitung von Management-Informationen ebenso wie umfassende eigene Logs.

Abbildung 1: Red Hat liefert den Directory Server als RPM-Package. Das eigentliche Setup erfolgt nach der Installation des Pakets.

Windows-Integration

Hervorzuheben sind die Schnittstellen zu Microsofts Active Directory sowie zu den Benutzerkonten-Datenbanken (SAM, Security Account Management) von NT-Domänen. Über sie sind Änderungen aus dem Red Hat Directory in das AD oder die NT-Domänen übertragbar. Hierbei gelingt sogar die sehr komplexe bidirektionale Kennwortsynchronisation.

Dabei ist die Replikation von Kennwortänderungen, die im Red Hat Directory Server erfolgt sind, vergleichsweise trivial. Der Server speichert die Passwörter typischerweise reversibel verschlüsselt, die er dann vor der Synchronisation nur entschlüsseln muss. Ein Active Directory legt dagegen die Hashes der Kennwörter ab. Das ließe sich zwar durch eine einfache Konfigurationseinstellung ändern, ist aber unüblich.

In der Konsequenz muss der Windows-Server jede Kennwortänderung, die ein Windows-Client im Active Directory verursacht, abfangen, bevor der Hash erzeugt wird. Dafür stellt das Active Directory definierte Hooks bereit, Red Hat liefert eine DLL mit, die der Admin auf den Domänencontrollern installiert. Sie fängt an diesem Hook die Änderung ab und leitet die Kennwortdaten an den Red Hat Directory Server weiter.

Das Ganze hilft dabei, den Red-Hat-Server eng in Windows-Umgebungen zu integrieren, bis hin zur Steuerung des Active Directory von einem Red Hat Directory Server aus. Die Implementation weist jedoch Schwächen auf. So ermittelt der Red-Hat-Server Änderungen im Active Directory über periodische Suchen – es gäbe intelligentere Varianten.

Installieren und Setup

Für den Test lag eine Evaluationsversion für Red Hat Enterprise Linux 4 vor. Die Installation ist auf dieser Distribution einfach, da sie nicht wie für die anderen unterstützten Betriebssysteme – HP-UX 11i, Solaris 9 und Red Hat Enterprise Linux 3 – gepatcht werden muss (Abbildung 1). Das Setup des ersten Servers war innerhalb weniger Minuten bewerkstelligt, wobei die gute und umfassende Dokumentation hilfreich war.

Die Administration erfolgt über Konfigurationsdateien, die Befehlszeile oder grafisch. Basis ist der Administration Server, der mit der Konfigurationsschnittstelle des Directory Server kommuniziert. Auf dem grafischen Java-Frontend finden sich im Register »Tasks« einige Standardaufgaben wie Datensicherung, ein Neustart des Directory Server oder der Import von LDIF-Daten.

Im Register »Configuration« passt der Admin Datenbankeinstellungen, Backups, die Replikation, Logs und Plugins an (Abbildung 2). Die Schnittstelle ist übersichtlich gestaltet und für Administratoren, die mit Verzeichnisdiensten vertraut sind, ohne große Einarbeitung nutzbar. Zum Management der Basisstrukturen von Verzeichnissen ist hilfreich, dass man von der grafischen Konsole auch auf das Verzeichnis selbst zugreifen darf (siehe Abbildung 3). Schließlich bildet das Tool Statusinformationen zum Directory Server ab.

Neben der grafischen Oberfläche überzeugten im Test auch die anderen Schnittstellen. Bei ihnen wird deutlich, dass der Red Hat/Fedora Directory Server kein neues Produkt ist, sondern eine über Jahre gereifte Lösung, die Red Hat mit neuem Schwung vorantreibt. So kann die Installation auch unbeaufsichtigt laufen, wenn der Admin die Parameter in einer Konfigurationsdatei abgelegt hat.

Gut, aber nicht herausragend

Zum aktuellen Stand ist der Red Hat Directory Server ein gutes Produkt mit zum größten Teil zeitgemäßen Features. Echte Highligts, die die Konkurrenz (siehe Kasten “Alternativen”) vor Neid erblassen ließen, sucht man aber vergebens. Trotzdem besitzt er alle Voraussetzungen für den produktiven Einsatz, das Attribut “Enterprise ready” kann dieser erste Test verdient vergeben.

Mit dem Red Hat Directory Server gibt es ab sofort einen interessanten Verzeichnisdienst mehr. Dem freien, technisch ansonsten gleichwertigen Fedora Directory Server fehlen zurzeit ein paar Schnittstellen, was sich aber wohl ändern wird. Insgesamt verbessert Red Hat seine Position gegenüber Novell, womit sich das getätigte Investment (vielleicht) indirekt rechnet. Denn mit Directories allein lässt sich nur noch selten das große Geld verdienen. Meist sind sie eine Commodity, die mit Betriebssystemen oder Anwendungen mitkommt. (jk)

Abbildung 2: Die Konfiguration der Replikationseinstellungen, beispielsweise des Change-Log als Änderungsprotokoll, passiert in der grafischen Konsole.

Abbildung 3: Das Schema, also die Datenstruktur des Verzeichnisses, kann der Administrator praktischerweise direkt über die Konsole modifizieren.