Mit dem 389-Directory Server (389-DS) gibt es eine moderne Alternative zum guten alten OpenLDAP. Das aus dem Fedora-Projekt stammende Projekt besitzt einige besondere Fähigkeiten auf, die dieser Artikel näher vorstellt.
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) () 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) 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 .
setup-ds-admin.pl -s -f setup.inf
Listing 1
<C>setup.inf<C>
[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. 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
«
.
Listing 2
<C>/tmp/base.ldif<C>
# 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: [email protected] telephonenumber: 0123-7654321 l: Foo Town postalcode: 12345 streetadress: Tuxstreet 22
Den Import der Daten in den Directory-Server übernimmt »ldapadd
«
()
Listing 3
<C>ldapadd<C>
$ 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 zeigt ein durch »migrate_passwd.pl
«
erzeugtes LDAP-Objekt .
Listing 4
<C>ldapsearch<C>
# 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
«
(). 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) , 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
Zertifikat erzeugen
# 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 (). Natürlich funktionieren die Anpassungen genauso über die grafische Konsole. Eine entsprechende Anleitung hierfür findet sich unter .
Listing 6
<C>ldapmodify<C>
# 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
<C>certutil<C>
# 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 (). 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 . Die Datei importiert der bereits vertraute »ldapadd
«
-Aufruf:
ldapadd -x -f /tmp/consumer.ldif -D "cn=↩ Directory Manager" -w redhat123
Listing 8
<C>/tmp/consumer.ldif<C>
### 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
<C>/tmp/supplier.ldif<C>
### 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
<C>/tmp/agreement.ldif<C>
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 .
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
<C>/tmp/winad-sync.ldif<C>
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 für 32-Bit Systeme oder 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 . Eine genaue Anleitung zum Replikations-Setup zwischen 389-DS und Windows AD findet sich auch unter .
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 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 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 , um an weitere Hilfe zu gelangen.
Infos
- 389-Directory-Server: http://directory.fedoraproject.org
- Konfigurationsoptionen für das Setup-Programm: http://www.redhat.com/docs/manuals/dir-server/8.1/install/Installation_Guide-Advanced_Configuration-Silent.html#Installation_Guide-Advanced_Configuration-inf-File
- Projektseite der Network Security Services (NSS) : http://www.mozilla.org/projects/security/pki/nss/
- SSL/TLS-Konfiguration: http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL.html
- LDAP-Replikation auf der Kommandozeile: http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Configuring-Replication-cmd.html
- PassSync als MSI-Paket für 32 Bit: http://port389.org/download/389-PassSync-1.1.2-i386.msi
- PassSync als MSI-Paket für 64 Bit: http://port389.org/download/389-PassSync-1.1.2-x86_64.msi
- How to enable LDAP over SSL with a third-party certification authority: http://support.microsoft.com/default.aspx?scid=kb;en-us;321051
- Howto zur Replikation mit Windows ADS: http://directory.fedoraproject.org/wiki/Howto:WindowsSync
- 389-Directory Server Wiki: http://directory.fedoraproject.org/wiki/
- 389-Directory Server Mailinglisten: http://directory.fedoraproject.org/wiki/Mailing_Lists
- Tool zum Konvertieren von OpenLDAP-Schema Daten ins 389-DS-Format: http://directory.fedoraproject.org/download/ol-schema-migrate.pl
- Dokumentation zum Red Hat Directory Server: http://www.redhat.com/docs/manuals/dir-server/8.1/
Author: Benjamin Jennings
Last Updated: 1703482321
Views: 1061
Rating: 3.8 / 5 (110 voted)
Reviews: 93% of readers found this page helpful
Name: Benjamin Jennings
Birthday: 1928-05-28
Address: 849 Carpenter Stream, Jonathanborough, VT 51076
Phone: +4557330127549717
Job: Art Director
Hobby: Snowboarding, Playing Chess, Running, Arduino, Golf, Dancing, Telescope Building
Introduction: My name is Benjamin Jennings, I am a artistic, esteemed, unswerving, rare, valuable, clever, tenacious person who loves writing and wants to share my knowledge and understanding with you.