Der Directory Server 389

Anders als relationale Datenbank-Systeme (RDBMS) mit flachen Strukturen arbeitet ein Directory-Server mit einem hierarchisch aufgebautem Baum. Dieser ist auch als Directory Information Tree (DIT) ( Abbildung 1 ) bekannt. Innerhalb dieser Struktur befinden sich Attribute, denen der Anwender einen oder mehrere Werte zuordnen kann. Welche davon zulässig sind und welche Attribute man zusammen verwenden kann, definiert ein Schema. Relationale Datenbank-Systeme sind üblicherweise für schnelle Schreiboperationen optimiert, bei einem Directory-Server geht man von eher von einer großen Anzahl lesender Zugriffe aus. Auch in den Protokollen unterscheiden sich die beiden Systeme. Während bei Datenbanken der Zugriff über ODBC oder JDBC geschieht und kein definiertes Netzwerkprotokoll existiert, findet man im Directory-Server-Umfeld das LDAP-Protokoll (Lightweight Directory Access Protocol) im Layer-7 des Netzwerkstacks vor. Hierbei handelt es sich um ein in den RFCs 2251-2256 und 4511 definiertes Protokoll, das auf dem Standard ISO X.500 aufsetzt. Aktuell ist Version 3, die in allen aktuellen LDAP-Anwendungen zur Verfügung steht.

Abbildung 1: Der LDAP-Baum ähnelt einer hierarchischen Baumstruktur.

Der 389-Directory Server (389-DS) [1] arbeitet naürlich ebenfalls mit der aktuellen LDAP Version 3, ist allerdings auch mit älteren Versionen kompatibel. Neben der Fähigkeit bis zu vier Master-Server zu betreiben, also vier Server die eine Schreib-/Lese-Kopie der LDAP-Datenbank vorhalten, sticht besonders die Möglichkeit der Synchronisation mit Windows-Active-Directory-Servern hervor. Daneben unterstützt der Server auch multiple Berkley-Datenbank-Dateien zur Speicherung der LDAP-Daten, SSL/TLS-geschützte Kommunikation, SASL (Simple Authentication and Security Layer), Attribut-Verschlüsselung und eine umfangreiche Account- und Passwort-Policy. Einsetzen lässt sich der Server auf aktuellen Fedora-, Red-Hat-Enterprise- und vielen anderen Linux-Systemen wie beispielsweise Debian oder Gentoo. Im Rest der Unix-Welt läuft der Server problemlos auf HP-UX- und Solaris-Maschinen.

Vor der Installation des Servers sind einige Voraussetzungen zu erfüllen. So benötigt der 389-DS einen Apache2-Webserver und eine aktuelle Java-Laufzeit-Umgebung (JRE) wie beispielsweise OpenJDK. Beide Pakete sind über das Standard-Fedora-Repository verfügbar. Die Installation der Pakete gelingt so sehr bequem über das Paket-Management und mit Hilfe von Yum:

yum install httpd java-1.6.0-openjdk

Der 389-DS selbst besteht dabei aus drei Komponenten:

• Core-Directory-Server: Er bildet das Herzstück des Directory-Serves. Er ist LDAPv3-kompatibel und bietet eine ganze Reihe von Kommandozeilentools und Skripten zur Administration an.
• Administrations-Server: Er stellt die Management Plattform für den Core Server dar. Die komplette Administration des Core-Servers ist wahlweise über die grafische Java-Konsole oder ein Webinterface möglich.
• Directory-Server-Konsole: Sie ist das grafische Frontend zur Administration der Admin- und Core-Server. Die Konsole ist komplett in Java geschrieben. Ein aktuelles JRE ist deshalb zur Installation der Konsole notwendig.

Ein System kann ohne weiteres aus mehreren Directory-Server-Instanzen bestehen. Zwingend notwendig ist pro System jedoch nur ein einzelner Administrations-Server. Über die Java-Konsole ist dann die Administration mehrerer Directory- und Administrations-Server-Instanzen möglich. Die Installation der drei Komponenten erfolgt im einfachsten Fall wieder mit Hilfe von Yum:

yum install 389-ds 389-admin 389-console

Nach erfolgreicher Installation ruft man die Setup-Prozedur über das Perl-Skript »setup-ds-admin.pl« auf. Das Tool erzeugt dann eine Directory- und Administrations-Server-Instanz auf dem System. Alle notwendigen Konfigurationsoptionen lassen sich entweder interaktiv oder über eine Inf-Datei an das Setup-Tool übergeben. Sie enthält drei Abschnitte (General, Admin, Slapd). Hierüber ist ein komplettes Setup der beiden Server-Komponenten möglich. Diese Vorgehensweise ist sehr praktisch, da sich die Server so sehr einfach automatisiert als Teil der System-Installation aufsetzen und direkt konfigurieren lassen. Eine Beschreibung aller Setup-Optionen findet sich unter [2] .

setup-ds-admin.pl -s -f setup.inf

[General]
FullMachineName = foo.example.com
AdminDomain = example.com
SuiteSpotGroup = nobody
SuiteSpotUserID = nobody
ConfigDirectoryLdapURL = ldap://foo.example.com:389/o=NetscapeRoot
ConfigDirectoryAdminID = admin
ConfigDirectoryAdminPwd = redhat
[admin]
ServerAdminID = admin
ServerAdminPwd = redhat
SysUser = nobody
Port = 9830
[slapd]
ServerIdentifier = foo
Suffix = dc=example,dc=com
ServerPort = 389
RootDN = cn=Directory Manager
RootDNPwd = redhat123
AddOrgEntries = No
InstallLdifFile = none
AddSampleEntries = No
SlapdConfigForMC = yes
UseExistingMC = 0

Abbildung 2: Über eine Setup-Datei lässt sich der 389-Directory-Server komplett automatisiert installieren.

Jede Directory-Server Instanz verfügt im Verzeichnis »/etc/dirsrv« über ein eigenes Konfigurationsverzeichnis. In diesem befindet sich eine Datei mit dem Namen »dse.ldif« . Über diese Datei findet die komplette Konfiguration des Servers statt. Da der Directory-Server seine Konfiguration auch im LDAP-Baum selbst ablegt, ist es möglich, sämtliche Konfigurationsänderungen auch direkt über die LDAP-Datenbank vorzunehmen. Diese befindet wiederum in einem eigenen Verzeichnis unterhalb von »/var/lib/dirsrv« , wo auch die Logs liegen.

Im Anschluss an die Installation sollten auf dem System zwei neue Prozesse laufen. Diese lauschen auf den beiden Netzwerkports 389 ( »ns-slapd« ) und 9830 ( »httpd.worker« ) auf eingehende Anfragen. Zu diesem Zeitpunkt ist auch bereits ein Zugriff auf die beiden Server möglich. Im einfachsten Fall stellt man über die grafische Konsole eine Verbindung zum Administrations-Server auf dem Port 9830 her. Ein Zugriff über Kommandozeilen-Tools wie beispielsweise »ldapsearch« funktioniert ebenfalls.

Bis zu diesem Schritt befinden sich in der LDAP-Datenbank jedoch lediglich Konfigurationsdaten. Unterhalb von »cn=config« liegen die Konfigurationseinstellungen des Directory-Servers (aus der Datei »dse.ldif« ), der Suffix »o=NetscapeRoot« enthält die Daten des Administration-Servers. Für deren Abfrage ist ein administratives Konto notwendig. Sucht man beispielsweise nach dem Netzwerkport des Servers, so lässt sich dieser aus der LDAP-Konfiguration auslesen. Das entsprechende LDAP-Attribut in dem der Port gespeichert ist, heißt »nsslapd-port« :

ldapsearch -x -s base -LLL -b cn=config -D ↩
"cn=Directory Manager" -w redhat123 nsslapd-↩
port
dn: cn=config
nsslapd-port: 389

Bei dem Account »cn=Directory Manager« handelt es sich um den Administrator beider Server. Für dieses Konto gelten keine Zugriffskontrollen, es hat kompletten Zugriff auf sämtliche Daten der Server. Anstatt die Daten einfach nur auszulesen kann dieser Benutzer über den Aufruf von »ldapmodify« auch Attribute verändern.

Abbildung 3: Die grafische Console bietet eine elegante Umgebung zur Konfiguration des Administration- und Directory-Servers an.

Die Benutzerdatenbank hat in diesem Beispiel das Suffix »dc=example,dc=com« . Bevor man diese mit Daten füllt, sollte man sich erst einmal Gedanken über die Struktur des eigenen LDAP-Baums machen. Unterhalb der Wurzel »dc=example,dc=com« könnte man beispielsweise einen Container für Benutzer anlegen. Objekten in diesem Container lassen sich dann bestimmte Attribute zuordnen. Je nach Einsatzzweck des Direktories kann es sich hierbei um Daten für ein Adressbuch handeln, aber auch um Login-Daten. Lezteres ist dann notwendig, wenn der Directory-Server als zentraler Authentifizierungs-Dienst dienen soll. Dazu später mehr.

Im Beispiel gehen wir von einem Container für Benutzer- und einem für Gruppen-Informationen aus. Um diese anzulegen kann der Admin auf die grafische Konsole zurückgreifen, oder er schreibt eine entsprechende LDIF-Datei (LDAP Data Interchange Format) und importiert sie dann in den Server. Listing 2 zeigt ein Beispiel für eine solche LDIF-Datei. Beim Erstellen der Datei ist es besonders wichtig, auf die Zusammensetzung der einzelnen Objkte zu achten. Welche Objekte welche Attribute erfordern und welche Attribute welche Daten aufnehmen können, ist im bereits angesprochenen LDAP-Schema definiert. Dieses befindet sich im Konfigurationsverzeichnis des Servers im einem dedizierten Schema-Ordner. Möchte man dieses erweitern, so sind die neuen Schema-Daten in diesen Ordner zu kopieren und der Server im Anschluss neu zu starten. Ohne Downtime geht es mit dem Tool »schema-reload.pl« aus dem Verzeichnis »/var/lib/dirsrv/slapd-foo« . Hier liegen einige nützliche Skripte zur Administration des Servers. Existiert bereits ein alter OpenLDAP-Server, ist es jedoch nicht möglich, dessen Schema-Dateien einfach zu übernehmen: Der 389-DS erwartet die Daten im RFC-2252-Format. Sollen die alten Schematas auch unter dem neuen Directory-Server zum Einsatz kommen, so sind diese zuerst zu konvertieren. Hierfür existieren entsprechende Migrationsskripte wie beispielsweise »ol-schema-migrate.pl« [12] .

# Wurzel des LDAP-Suffixes
dn: dc=example,dc=com
objectClass: organization
objectClass: dcObject
o: Example, Inc.
dc: example
# Container für Benutzer
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: people
# Container für Gruppen
dn: ou=Group,dc=example,dc=com
objectClass: organizationalUnit
ou: group
# Ein beispielhafter Eintrag für einen Benutzer
dn: cn=Foo Bar,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
cn: Foo Bar
sn: Scherf
mail: foobar@example.com
telephonenumber: 0123-7654321
l: Foo Town
postalcode: 12345
streetadress: Tuxstreet 22

Den Import der Daten in den Directory-Server übernimmt »ldapadd« ( Listing 3 )

$ ldapadd -x -f /tmp/base.ldif -D "cn=Directory Manager" -w redhat123
adding new entry "dc=example,dc=com"
adding new entry "ou=people,dc=example,dc=com"
adding new entry "ou=group,dc=example,dc=com"
adding new entry "cn=Thorsten Scherf,ou=people,dc=example,dc=com"

Ein anschließender Aufruf von »ldapsearch« sollte bestätigen, dass der Import der Daten geklappt hat. Eine verbreitete Anwendung ist es, bestehende User-Konten aus der Datei »/etc/passwd« zu importieren, sodass eine zentrale Anmeldung an LDAP-Server möglich wird. Dies ist nicht weiter schwierig. Im Fedora-Software-Repository existiert hierfür das Paket »migrationtools« , das sich mit Yum installieren lässt. Bei dem Tool handelt es sich um eine Sammlung von Perl- und Shell-Skripten die die bestehenden Benutzer- und Gruppen-Konten in eine LDIF-Datei konvertieren. Anschließend kann der Administrator die Datei dann, wie schon weiter oben gezeigt, mit »ldapadd« dem Server hinzufügen. Die hieraus resultierenden LDAP-Objekte besitzen dann bereits alle notwendigen POSIX-Attribute die für ein Login auf einer Linux-Maschine notwendig sind. Der Aufruf von »ldapsearch« in Listing 4 zeigt ein durch »migrate_passwd.pl« erzeugtes LDAP-Objekt .

# ldapsearch -x -LLL -b "dc=example,dc=com" -D "cn=Directory Manager" -w redhat123 uid=tscherf
dn: uid=tscherf,ou=People,dc=example,dc=com
uid: tscherf
cn: Thorsten Scherf
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 14523
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/tscherf
gecos: Thorsten Scherf
userPassword:: e2NyeXB0aSQxJHhPZn1kUjNFJE5xVUdpNktrZUpsWktRWXF6L3pldDA=

Um bei der Anmeldung am System auf dieses Konto zurückgreifen zu können, ist auf dem System das NSS- und PAM-Subsystem zu konfigurieren. Im einfachsten Fall geschieht dies auf einem Fedora-System durch den Aufruf von »system-config-authentication« ( Abbildung 4 ). Das Tool passt die Konfigurationsdateien der beiden Subsysteme anhand der übergebenen Informationen entsprechend an. Im einzelnen handelt es sich dabei um die folgenden Konfigurationsdateien:

• »/etc/nsswitch.conf« (NSS)
• »/etc/ldap.conf« (NSS/PAM)
• »/etc/pam.d/system-auth« (PAM)

Abbildung 4: Über das Tool system-config-authentication lassen sich die beiden Subsysteme NSS und PAM für eine LDAP-basierte Benutzerauthentifizierung konfigurieren.

Nun sollte der Login auch dann funktionieren, wenn das angegebene Konto nicht in der lokalen Datei »/etc/passwd« existiert. Das ist sehr bequem, da nun die einzelnen Konten nicht mehr auf jeder Maschine zu erzeugen sind. Stattdessen erzeugt der Administrator diese einmal zentral im Directory-Server und konfiguriert die Clients entsprechend für den Zugriff hierauf. Trotzdem gibt es hier zwei Nachteile. Zum einen ist dafür zu sorgen, dass die Home-Verzeichnisse der Benutzer zwischen den einzelnen Maschinen synchronisiert sind, oder besser, zentral vorliegen und über den Automounter jeweils an die Maschine exportiert werden, an dem sich der betreffende Benutzer gerade anmeldet.

Ein größeres Problem ist jedoch, dass bei einer Anmeldung via LDAP die Benutzerdaten im Klartext über das Netzwerk fließen, also auch das Passwort. Somit hat jeder, der das Netzwerk abhören kann, Zugriff auf diese Daten. Das Problem lässt sich dadurch lösen, dass sich Client und Server über einen durch TLS gesicherten Kanal miteinander unterhalten. Dazu braucht der Directory-Server ein X.509-Zertifikat.

Der 389-DS basiert auf den Network Security Services (NSS) [3] , das heißt, anders als beispielsweise bei OpenSSL existiert zur Verwaltung von X.509-Zertifikaten ein eigenes Datenbank-Backend in Form der Dateien »cert8.db« , »key3.db« und »secmod.db« . Diese liegen unterhalb von »/etc/dirsrv/admin-serv« für den Admin-Server beziehungsweise »/etc/dirsrc/slapd-hostname« für den Director-Server. Mit Hilfe des Tools »certutil« kann der dann für beide Server ein Zertifikatsrequest oder ein selbstsigniertes Zertifikat erzeugen. Den dafür notwendigen Aufruf zeigt Listing 5 .

# certutil -Ra -s "cn=foo.example.com" -o foo-ldap.xsr -d /etc/dirsrv/slapd-foo/
Enter Password or Pin for "NSS Certificate DB":
A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.
To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
Continue typing until the progress meter is full:
|************************************************************|
Finished.  Press enter to continue:
Generating key.  This may take a few moments...
# cat foo-ldap.csr
Certificate request generated by Netscape certutil
Phone: (not specified)
Common Name: foo.example.com
Email: (not specified)
Organization: (not specified)
State: (not specified)
Country: (not specified)
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBWjCBxAIBADAbMRkwFwYDVQQDExB0aWZmeS50dXhnZWVrLmRlMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDV1a+bnypcdoLhmS9XT1v+tcAq8Q8fn0me9LCb
aOFvBUD7qEbpXgDajglVrHfFuRyqcoJ19xWoxKA+95+LIWG3l6/UMa38n9XVW9+R
xWkYR+cdKphEr4iteWsdjqSl+OfUZrOa0wr1VCiIGwG3k/4aD8IbLhegLZL0dAV7
DSb07wIDAQABoAAwDQYJKoZIhvcNAQEFBQADgYEACDshh6KpKiYXQEVi5p9GLNM7
ryC83gxWMGJeE01Owa0WGeFdNIbuBLJHPcAYaTmbGAUcvFPqinMRZYzjvjZvNaa5
SToMe6rp+0n95fpzlE6LzIW59vjDiF/tuFrKAvOzeh61gS6cPkWMxd8iLztX+znx
cl1VS58ExGKVI5R9bzU=
-----END NEW CERTIFICATE REQUEST-----

Den so erzeugten Zertifikatsrequest kann der Administrator zur Signierung an eine Zertifikatsstelle (CA) senden und das zurückerhaltene Zertifikat zusammen mit dem Zertifikat der CA, in die NSS-Datenbank des Admin- und Directory-Servers importieren. Für den Import in die Directory-Server-Datenbank sieht der Aufruf von »certutil« wie folgt aus:

# certutil -A -n "CA Certificate" -t "CT,,↩
" -i ca.crt -d /etc/dirsrv/slapd-foo/
# certutil -A -n "ldap-server-cert" -t "u,u,↩
u" -i ldap.crt -d /etc/dirsrv/slapd-foo/

Der Import des Admin-Server-Zertifikats funktioniert entsprechend. Natürlich ist abschließend noch die eigentliche Server-Konfiguration anzupassen. Da die komplette Konfiguration im LDAP-Baum liegt, lassen sich die notwendigen Modifikationen leicht mit »ldapmodify« vornehmen ( Listing 6 ). Natürlich funktionieren die Anpassungen genauso über die grafische Konsole. Eine entsprechende Anleitung hierfür findet sich unter [4] .

# ldapmodify -x -h foo.example.com -p 389 -D "cn=Directory Manager" -W <<__EOF
dn: cn=config
changetype: modify
add: nsslapd-security
nsslapd-security: on
-
replace: nsslapd-ssl-check-hostname
nsslapd-ssl-check-hostname: off
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: on
-
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
-
add: nsSSL3Ciphers
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,
 +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,
 +fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,
 +tls_rsa_export1024_with_des_cbc_sha
dn: cn=RSA,cn=encryption,cn=config
changetype: add
objectclass: top
objectclass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: ldap-server-cert
nsSSLToken: internal (software)
nsSSLActivation: on
__EOF

Das Tool »certutil« bestätigt schließlich, dass der Import der beiden Zertifikate geklappt hat ( Listing 7 ).

# certutil -d /etc/dirsrv/slapd-foo/ -L
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
CA Certificate                                               CT,,
ldap-server-cert                                             u,u,u

Nach einem Neustart des Servers ist dieser nun in der Lage, sich über SSL/TLS gesichert zu verbinden. Damit sowohl die LDAP-Client-Tools wie auch PAM zur Authentifizierung auf diesen geschützen Kanal zurückgreifen, gibt man bei der Konfiguration von PAM über das Tool »system-config-authentication« die URL an, von wo man das CA-Zertifikat beziehen kann. Dieses ist zur Überprüfung des Server-Zertifikates notwendig. Alternativ kopiert der Administrator das CA-Zertifikat einfach in das Verzeichnis »/etc/openldap/cacerts« . Abschließend ist dann aber noch dieses Verzeichnis durch »cacertdir_rehash« zu indizieren. Ob die SSL-/TLS-Kommunikation zum Server funktioniert, testet man am besten über den Aufruf von »ldapsearch« mit der Option »-ZZZ« . Diese erzwingt die Verwendung eines geschützten Kommunikationskanals. Sollte die Verbindung nicht klappen, ist die Fehlerquelle häufig eine falsch gehende Uhr oder ein Fehler im Cn-Feld des Server-Zertifikates. Hier muss zwingend der Rechnername des LDAP-Servers stehen, sonst verweigert »ldapsearch« seine Arbeit mit einem "Verifikationsfehler" des Zertifikates.

Ein weiteres interessantes Feature des 389-Directory-Servers ist seine Fähigkeit, LDAP-Daten zwischen mehreren Servern zu replizieren. Dabei gibt es verschiedene Szenarien: Die Replikation mit einem Server, der über eine Nur-Lese Kopie der LDAP-Datenbank verfügt (Consumer) oder mit einem Server, der eine beschreibbare Kopie der Datenbank besitzt (Supplier). Die erste Variante bezeichnet man als Single-Master-Replikation, letztere als Multi-Master-Replikation (MMR). Hier ist dann eine Synchronisation zwischen maximal vier Suppliern möglich.

Zum Einsatz kommt diese immer dann, wenn man zwingend mehrere schreibbare Kopien der LDAP-Datenbank benötigt, beispielsweise aus Gründen der Ausfallsicherheit oder wegen einer großen Anzahl von Clients, die Änderungen an der Datenbank durchführen und ein einzelner Server mit dieser Aufgabe überlastet wäre. Auch die geografische Aufteilung eines Directory-Server-Setups kann ein Grund sein, eine MMR durchzuführen. Man denke dabei nur an ein Unternehmen mit mehreren Standorten, das den Directory-Server zur Benutzer-Authentifizierung einsetzt. Hier möchte man nicht für jede Änderung an der Datenbank eine WAN-Verbindung zu dem Standort aufbauen, an dem sich der einzige Master-Server mit einer Schreibkopie der LDAP-Datenbank befindet.

Abbildung 5: Eine Replikation lässt sich sowohl über LDIF als auch über die grafische Konsole einrichten.

Im folgenden ist die Konfiguration für eine Single-Master-Replikation mit einem einzelnen Replica-Server dargestellt. Mit Hilfe der grafischen Konsole ist die Konfiguration recht einfach ( Abbildung 5 ). Hier zeigen wir wieder den Weg der Konfiguration über die Kommandozeile. Das ist besser, wenn man solche Abläufe automatisieren will. Das Setup besteht aus mehreren Schritten. Da der 389-Directory-Server auf der Push-Technologie basiert, muss auf dem Consumer-Server ein Benutzerkonto existieren. Der Master verwendet es, um um sich am Replica anzumelden, wenn es auf dem Supplier-Server Änderungen an der LDAP-Datenbank gibt. Anschließend lässt sich auf diesem Server dessen Rolle als Consumer definieren, also mit einer Lese-Kopie der LDAP-Datenbank. Die notwendigen LDIF-Daten für diese Konfiguration zeigt Listing 8 . Die Datei importiert der bereits vertraute »ldapadd« -Aufruf:

ldapadd -x -f /tmp/consumer.ldif -D "cn=↩
Directory Manager" -w redhat123

### LDIF-Daten zum Erzeugen eines Benutzer-Kontos auf dem Consumer-Server
dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM
userPassword: password
passwordExpirationTime: 20380119031407Z
### LDIF-Daten zur Konfiguration des Consumer-Servers
dn: cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: dc=example,dc=com
nsds5replicatype: 2
nsds5ReplicaBindDN: cn=replication manager,cn=config
nsds5flags: 0

Auf dem Master ist die Konfiguration kaum aufwändiger. Hier muss der Admin einen Eintrag für das spätere Changelog vornehmen. Diese Datei enthält sämtliche Änderungen der LDAP-Datenbank, die nun auf den Consumer zu übertragen sind. Zum Schluss ist natürlich auch diesem Rechner die Rolle mitzuteilen, die er einnehmen soll, in diesem Fall also die des Master-Servers mit einer Schreib-Kopie der LDAP-Datenbank. Die notwendigen LDIF-Daten für ein »ldapadd« zeigt Listing 9 .

### LDIF-Daten zum Anlegen des Changelogs auf dem Supplier-Server
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-foo/changelogdb
nsslapd-changelogmaxage: 10d
dn: cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: dc=example,dc=com
nsds5replicaid: 7
nsds5replicatype: 3
nsds5flags: 1
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaBindDN: cn=replication manager,cn=config

Nach diesen Vorarbeiten ist es Zeit für das eigentliche "Replication Agreement" zwischen dem Master- und seinem Slave-Server. Hierbei handelt es sich um eine Art Regelwerk, das festlegt, zwichen welchen Rechnern und mit welchen Eigenschaften eine Replikation der LDAP-Daten ablaufen soll. Ein beispielhaftes Agreement zeigt Listing 10 .

dn: cn=ExampleFooAgreement,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replicationagreement
cn: ExampleAgreement
nsds5replicahost: foobar-consumer
nsds5replicaport: 389
nsds5ReplicaBindDN: cn=replication manager
nsds5replicabindmethod: SIMPLE
nsds5replicaroot: dc=example,dc=com
description: agreement between supplier foo and consumer foobar
nsds5replicacredentials: {DES}UXRbhvozeN9LWdueOEbPeQ==
nsds5BeginReplicaRefresh: start

Nach einem Import des Replication Agreement auf dem Supplier-Server startet die Replikation der LDAP-Daten unmittelbar. Verantwortlich hierfür ist das Attribut »nsds5BeginReplicaRefresh« .

Die MMR-Replikation läuft ganz ähnlich ab. Der Unterscheid hier besteht darin, dass jeder Server gleichzeitig Supplier und Consumer sein muss. Eine Beschreibung alle Attribute, die für das Einrichten einer Repliation interessant sind, findet man im Administrations-Guide des Red Hat Enterprise Directory Servers, dem kommerziellen Gegenstück zum 389-DS [5] .

Replikation mit Active Directory

Die Synchronisation mit einem Windows Active Directory Server (ADS) bringt den Vorteil, dass in einer Microsoft-Umgebung die Verwaltung sämtlicher Benutzerkonten auf dem Windows-ADS stattfinden kann. Das Andocken von Linux-Clients an einen Windows-Rechner bringt jedoch oft Probleme mit sich. Schöner wäre es, wenn man den Linux-Clients einen nativen Weg zur Benutzeranmeldung zur Verfügung stellen könnte. Genau dies ist mit einer synchronisierten LDAP-Datenbank aus dem Windows-ADS möglich. Linux-Clients greifen dann einfach mit Hilfe von LDAP auf den 389-DS zurück. Sämtliche Konten aus dem Windows ADS stehen nach einer Synchronisation auch hier zur Verfügung. Auf dem 389-DS muss der Admin dafür wiederum ein Replication Agreement zum Windows ADS konfigurieren ( Listing 11 ).

Windows Domain Name: winad.com
Windows Subtree: cn=Users,dc=winad,dc=com
DS Subtree: ou=people,dc=example,dc=com
Domain Controller Host: bar.winad.com
Port Number: 636
Bind as: cn=Administrator,cn=Users,dc=winad,dc=com

Abbildung 6: Auch die Konfiguration der Synchronisation mit einem Windows Active-Directory Server ist über die Konsole sehr leicht möglich.

Alternativ ist die Konfiguration auch über die Konsole möglich. Auf der Windows-Seite muss der Adminstrator das Tool PassSync installieren. Es kümmert sich darum, Änderungen an Benutzern und deren Passwörter auf den 389-DS zu übertragen. Das Tool steht als MSI-Paket unter [6] für 32-Bit Systeme oder [7] für 64-Bit Syteme zum Download bereit. Da Windows natürlich auch Passwort-Änderungen der Benutzer synchronisiert, ist zwingend der Einsatz von SSL/TLS zwischen dem 389-DS und dem Windows-ADS notwendig.

Existiert auf der Linux-Seite bereits eine Zertifizierungsstelle (CA), so lässt sich auf dem Windows-Rechner mit Hilfe des Tools »certreq« einfach eine Zertifikatsanfrage erzeugen. Diese sendet der Administrator dann an die Linux-CA und kopiert das resultierende Zertifikat zurück auf den Windows-Rechner. Mit Hilfe des MMC-Snap-Ins zum Zertifikats-Management lässt sich sich dieses dann zusammen mit dem CA-Zertifikat in den Zertifikats-Speicher des Rechners laden. Ein Technet-Artikel beschreibt den genauen Ablauf [8] . Eine genaue Anleitung zum Replikations-Setup zwischen 389-DS und Windows AD findet sich auch unter [9] .

Fazit

Der 389-Directory Server bietet eine Menge sehr interessanter Features, von denen dieser Artikel nur die wichtigsten vorstellen konnte. Wer Lust auf mehr bekommen hat, dem sei das sehr ausführliche Wiki [10] empfohlen. Hier ist eine aktive Community am Werk die sehr viel an Dokumentation zur Verfügung stellt. Auch die Mailinglisten der Entwickler und Benutzer des 389-DS [11] sind immer eine gute Anlaufstelle wenn man einmal nicht weiter kommt und Fragen hat. Ansonsten lohnt sich natürlich auch ein Blick die in Dokumentation des Red Hat Directory Servers [13] , um an weitere Hilfe zu gelangen.