389 Directory Server
# 389 Directory Server

389 Directory Server (389 DS, früher Fedora Directory Server) ist ein freier LDAP-Server. Es ist eine Weiterentwicklung des Netscape Directory Servers, eines LDAP-Servers, den das Unternehmen Red Hat 2004 von AOL kaufte. Davor gehörte die Software dem Unternehmen Netscape Communications. Seit dem Beginn an der Universität Michigan im Jahr 1996 wurde die Software ständig weiterentwickelt. 389 Directory Server steht als freie Software unter der GNU General Public License.

## Funktionalität und Eigenschaften

389 Directory Server unterstützt:
* Multi-Masterreplikation
* Active-Directory-Abgleich
* sichere Authentifizierungssysteme (SSL/TLS und SASL)
* LDAP Version 3
* Berechtigungen (ACI = Access Control Information)
* Rollen
Ab Version 1.1:
* Automatischer Benutzer- und Gruppennummerngenerator (UID/GID number generator)
* LDAP-Direktverbindungen (LDAPI)
Weiterhin bietet der Server eine grafische, auf Java basierende Konsole, die zum eigentlichen Verzeichnisserver noch einen eigenen Adminserver benötigt. Das plattformunabhängige Programm erlaubt das Anlegen und Löschen von Servern, das Starten und Stoppen, die Konfiguration dieser und noch vieles mehr. Es gibt eine umfangreiche Dokumentation des Servers: Online-Hilfe in der Konsole, PDF-Bücher von Red Hat, HowTos und die Wikis auf der Projekt-Website.

## Das Projekt

Red Hat verfolgt mit diesem Projekt eine ähnliche Strategie wie bei Fedora, der bekannten Linux-Distribution. Es gibt den unter der GPL stehenden 389/Fedora Directory Server und den unter kommerziellem Support stehenden Red Hat Directory Server. Die beiden Produkte unterscheiden sich vor allem durch eine etwas einfachere Installation und der professionellen Unterstützung der geschäftlichen Variante. Red Hat stellt wie bei RHEL seine Anleitungstexte für alle gratis auf die Webseite, da sie sich fast vollständig auf die Fedora-Variante übertragen lassen.
Zur gesamten früheren Netscape Enterprise Suite gehörten unter anderem ein Mail-, ein Applikations- und ein Kalenderserver. Diese wurden bis jetzt noch nicht freigegeben. 2005 kündigte Red Hat an, weitere Produkte öffnen zu wollen. Ob dies zum Beispiel für den Applikationsserver passiert, ist ungewiss: Red Hat unterstützt WildFly und Sun Microsystems entwickelt ihn bereits unter dem Projekt GlassFish weiter. Der Zertifizierungsdienst wird mit dem eigenen Projekt Dogtag Certificate System betreut.

## Versionen

Die erste Release 7.1 (Versionsnummer noch von der Netscape-Zeit her) bildete die Basis für den Red Hat Directory Server 7.
Nach der ersten vollständig offenen Version 1.0.0, die nur mit Zeitbegrenzung lief (120 Tage), wurden die Versionen 1.0.1 bis 1.0.4 mit kleineren Fehlerkorrekturen und Verbesserungen (z. B. mehr unterstützte Kennwortverschlüsselungstechniken) herausgegeben. Man passte sie jeweils den neu erschienenen Distributionen Fedora und Red Hat Enterprise Linux an und packte sie dafür.
Ab dem Jahr 2007 mit Version 1.1 sind die Installationspakete nur noch über das Fedora Extra Repository bzw. einem eigenen Directory Server Repository mittels YUM verfügbar. Die inzwischen fertiggestellte Version 1.1 beinhaltet:
* Selektive Auswahl der zu installierenden Komponenten durch mehrere Pakete
* FHS Speicherorte im System
* Verbesserte Installation
* Einfache Migration von 1.0.x
* Init-Skripte
* Verbesserungen in der Interoperabilität mit Samba (vor allem Version 4)
* Fehlerbehebungen in der Konsole und Entfernen alter Komponenten des Adminservers
Es werden Fedora 6 bis 10 und RHEL 5 ab Service Level 1 als Plattformen unterstützt. Parallel dazu gibt es jetzt Red Hat Directory Server 8.

## Kompatibilität/Interoperabilität

Aus einem Zweig des Projekts entstand 2001 der ebenfalls populäre Sun Java System Directory Server aus der damaligen iPlanet-Allianz zwischen Netscape und Sun. So konnten sowohl der 389- und der Sun-Server, als auch ältere Netscape-Server-Varianten zu Replikationszwecken verbunden werden. Inzwischen wurde der Sun-Server durch Oracles Java-basiertem Oracle Unified Directory (OUD) ersetzt, wodurch diese Lösungen hinfällig wurden.
Bei Active Directory und NT4 von Microsoft wird die Synchronisation der Benutzerdaten unterstützt.
Bei OpenLDAP kann eine einseitige Replikation per slurpd zum 389-Server hin erfolgen. Sinnvollerweise sollte Letzterer dann für nur lesende Zugriffe freigegeben werden. Umgekehrt, aber wiederum nur in eine Richtung, sollte dies theoretisch auch möglich sein, die Vorgehensweise wurde jedoch noch nicht dokumentiert.
Anders bei Novell eDirectory: dort gibt es (außer dem LDAP-Protokoll) keine Interoperabilität.
389 ist Teil von Red Hats FreeIPA (Identitäten, Richtlinien, Überwachung), welches neben dem Verzeichnis noch vieles mehr bietet (Kerberos (Protokoll), Richtlinien, bequemere Oberfläche …). FreeIPAs Einsatz ist dem des 389 meist vorzuziehen, da es bereits ein vollständiges Identitätsmanagement (IDM) bietet.