LDAP-Directory-Server 389 Verzeichnisdienst

Transkript

1 Kian Hwi Lim, 123RF, 123RF LDAP-Directory-Server 389 Verzeichnisdienst Mit dem gibt es seit einiger Zeit eine Alternative zu dem guten alten Open LDAP. Der aus dem Fedora-Projekt stammende Server verfügt über einige besondere Fähigkeiten, die dieser Artikel näher vorstellt. Thorsten Scherf Anders als relationale Datenbanksysteme (RDBMS) mit flachen Strukturen, arbeitet ein Directory-Server mit einem hierarchisch aufgebautem Baum. Der 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 der Benutzer zusammen verwenden kann, definiert ein Schema. Relationale Datenbanksysteme sind üblicherweise für schnelle Schreiboperationen optimiert, bei einem Directory-Server geht man 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, liegt im Directory-Server-Umfeld das LDAP-Protokoll (Lightweight Directory Access Protocol) im Layer 7 des Netzwerkstacks vor. Es handelt sich um ein in den RFCs 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. Der (389-DS, [1]) arbeitet natürlich ebenfalls mit der aktuellen LDAP-Version 3, ist allerdings auch mit älteren Versionen kompatibel. Neben der Fähigkeit, bis zu vier Masterserver 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/ TLSgeschü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 etwa 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 Apache-2- Webserver und eine aktuelle Java-Laufzeitumgebung (JRE) wie beispielsweise Open JDK. Beide Pakete sind über das Standard-Fedora-Repository verfügbar. 72 Ausgabe Admin

2 Netzwerk lich. 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. Admin-Account Abbildung 1: Der LDAP-Baum ähnelt einer hierarchischen Baumstruktur. Die Installation der Pakete gelingt so bequem über das Paketmanagement mit Hilfe von Yum: yum install httpd java openjdk Der 389-DS selbst besteht aus drei Komponenten: n Core-Directory-Server: Er bildet das Herzstück des Directory-Servers. Er ist LDAP-3-kompatibel und bietet Kommandozeilen-Tools und Skripte zur Administration an. n Administrations-Server: Er stellt die Managementplattform für den Core- Server dar. Die komplette Administration des Core-Servers ist wahlweise über die grafische Java-Konsole oder ein Webinterface möglich. n 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 Directoryund 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 Serverkomponenten möglich. Dieses Vorgehen ist sehr praktisch, da sich die Server so sehr einfach automatisiert als Teil der Systeminstallation aufsetzen und direkt konfigurieren lassen (eine Beschreibung aller Setup-Optionen gibt [2]): setup ds admin.pl s f setup.inf 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 sich 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ög- 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«), das Suffix»o=NetscapeRoot«enthält die Daten des Administrations-Servers. Für deren Abfrage ist ein administratives Konto notwendig. Sucht man beispielsweise nach dem Netzwerkport des Servers, 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 U "cn=directory Manager" w redhat123 nsslapd U port dn: cn=config nsslapd port: 389 Listing 1:»setup.inf«01 [General] 02 FullMachineName = foo.example.com 03 AdminDomain = example.com 04 SuiteSpotGroup = nobody 05 SuiteSpotUserID = nobody 06 ConfigDirectoryLdapURL = ldap://foo.example.com:389/ o=netscaperoot 07 ConfigDirectoryAdminID = admin 08 ConfigDirectoryAdminPwd = redhat [admin] 11 ServerAdminID = admin 12 ServerAdminPwd = redhat 13 SysUser = nobody 14 Port = [slapd] 17 ServerIdentifier = foo 18 Suffix = dc=example,dc=com 19 ServerPort = RootDN = cn=directory Manager 21 RootDNPwd = redhat AddOrgEntries = No 23 InstallLdifFile = none 24 AddSampleEntries = No 25 SlapdConfigForMC = yes 26 UseExistingMC = 0 Admin Ausgabe

3 Bei dem Account»cn=Directory Manager«handelt es sich um den Administrator beider Server. Für dieses Konto gelten keine Zugriffskontrollen, es hat vollständigen Zugriff auf sämtliche Daten der Server. Statt die Daten einfach nur auszulesen, kann dieser Benutzer über den Listing 2:»/tmp/base.ldif«01 # Wurzel des LDAP Suffixes 02 dn: dc=example,dc=com 03 objectclass: organization 04 objectclass: dcobject 05 o: Example, Inc. 06 dc: example # Container für Benutzer 09 dn: ou=people,dc=example,dc=com 10 objectclass: organizationalunit 11 ou: people # Container für Gruppen 14 dn: ou=group,dc=example,dc=com 15 objectclass: organizationalunit 16 ou: group # Ein beispielhafter Eintrag für einen Benutzer 19 dn: cn=foo Bar,ou=people,dc=example,dc=com 20 objectclass: inetorgperson 21 cn: Foo Bar 22 sn: Scherf 23 mail: foobar@example.com 24 telephonenumber: l: Foo Town 26 postalcode: Abbildung 2: Über eine Setup-Datei kann der Administrator den komplett automatisiert installieren. 27 streetadress: Tuxstreet 22 Aufruf von»ldapmodify«auch Attribute verändern. Die Benutzerdatenbank hat im Beispiel das Suffix»dc=example, dc= com«. Wer diese mit Daten füllen will, sollte sich erst einmal Gedanken über die Struktur des eigenen LDAP-Baums machen. Unterhalb der Wurzel»dc=example,dc=com«ließe sich beispielsweise ein Container für Benutzer anlegen. Den Objekten in diesem Container sind dann bestimmte Attribute zuzuordnen. Je nach Einsatzzweck des Direktory kann es sich hierbei um Daten für ein Adressbuch handeln, aber auch um Log in- Daten. Letzteres ist dann notwendig, wenn der Directory-Server als zentraler Authentifizierungs-Dienst dienen soll. Dazu später mehr. LDIF zum Austausch Das Beispiel geht 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 Objekte zu achten. Welche Objekte welche Attribute erfordern und welche Attribute welche Daten aufnehmen können, das ist im bereits angesprochenen LDAP-Schema definiert. Es steht im Konfigurationsverzeichnis des Servers in einem dedizierten Schema- Ordner. Wer es erweitern möchte, kopiert die neuen Schema-Daten in diesen Ordner und startet den Server im Anschluss neu. 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 Open-LDAP- 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 Schemata auch unter dem neuen Directory- Server zum Einsatz kommen, sind sie zuerst zu konvertieren. Hierfür gibt es entsprechende Migrationsskripte wie»ol schema migrate.pl«[12]. Den Import der Daten in den Directory- Server übernimmt»ldapadd«(listing 3). Ein anschließender Aufruf von»ldapsearch«sollte bestätigen, dass der Im- Listing 3:»ldapadd«01 $ ldapadd x f /tmp/base.ldif D "cn=directory Manager" w redhat adding new entry "dc=example,dc=com" 03 adding new entry "ou=people,dc=example,dc=com" 04 adding new entry "ou=group,dc=example,dc=com" 05 adding new entry "cn=thorsten Scherf,ou=people,dc=ex ample,dc=com" Abbildung 3: Die grafische Konsole bietet eine elegante Umgebung für die Konfiguration des Administrationsund Directory-Servers an. 74 Ausgabe Admin

4 Netzwerk Abbildung 4: Über das Tool»system config authentication«lassen sich die beiden Subsysteme NSS und PAM für eine LDAP-basierte Benutzerauthentifizierung konfigurieren. port der Daten geklappt hat. Eine verbreitete Anwendung ist es, bestehende Userkonten aus der Datei»/etc/passwd«zu importieren, sodass eine zentrale Anmeldung am LDAP-Server möglich wird. Das 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 POSIX-Attribute, die für ein Login auf einer Linux-Maschine notwendig sind. Der Aufruf von»ldapsearch«in Listing 4 zeigt ein mit»migrate_passwd. pl«erzeugtes LDAP- Objekt. LDAP-Login 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: n»/etc/nsswitch.conf«(nss) n»/etc/ldap.conf«(nss/ PAM) n»/etc/pam.d/system auth«(pam) Nun sollte ein Login auch dann funktionieren, wenn das angegebene Konto nicht in der lokalen Datei»/etc/passwd«existiert. Das ist sehr bequem, da nun Listing 4:»ldapsearch«01 # ldapsearch x LLL b "dc=example,dc=com" D "cn=directory Manager" w redhat123 uid=tscherf 02 dn: uid=tscherf,ou=people,dc=example,dc=com 03 uid: tscherf 04 cn: Thorsten Scherf 05 objectclass: account 06 objectclass: posixaccount 07 objectclass: top 08 objectclass: shadowaccount 09 shadowlastchange: shadowmax: shadowwarning: 7 12 loginshell: /bin/bash 13 uidnumber: gidnumber: homedirectory: /home/tscherf 16 gecos: Thorsten Scherf 17 userpassword:: e2nyexb0asqxjhhpzn1kujnfje5xvudpnktr ZUpsWktRWXF6L3pldDA= 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. Aber es gibt dabei zwei Nachteile: Zum einen ist dafür zu sorgen, dass die Homeverzeichnisse der Benutzer zwischen den einzelnen Maschinen synchronisiert sind, oder besser, dass sie zentral vorliegen und über den Automounter jeweils an die Maschine exportiert werden, an der sich der betreffende Benutzer gerade anmeldet. Listing 5: Zertifikat erzeugen 01 # certutil Ra s "cn=foo.example.com" o foo ldap.xsr d /etc/dirsrv/ slapd foo/ 02 Enter Password or Pin for "NSS Certificate DB": A random seed must be generated that will be used in the 05 creation of your key. One of the easiest ways to create a 06 random seed is to use the timing of keystrokes on a keyboard To begin, type keys on the keyboard until this progress meter 09 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 24 Phone: (not specified) Common Name: foo.example.com 27 (not specified) 28 Organization: (not specified) 29 State: (not specified) 30 Country: (not specified) 31 BEGIN NEW CERTIFICATE REQUEST 32 MIIBWjCBxAIBADAbMRkwFwYDVQQDExB0aWZmeS50dXhnZWVrLmRlMIGfMA0GCSqG 33 SIb3DQEBAQUAA4GNADCBiQKBgQDV1a+bnypcdoLhmS9XT1v+tcAq8Q8fn0me9LCb 34 aofvbud7qebpxgdajglvrhffuryqcoj19xwoxka+95+liwg3l6/uma38n9xvw9+r 35 xwkyr+cdkpher4itewsdjqsl+ofuzroa0wr1vciigwg3k/4ad8iblheglzl0dav7 36 DSb07wIDAQABoAAwDQYJKoZIhvcNAQEFBQADgYEACDshh6KpKiYXQEVi5p9GLNM7 37 ryc83gxwmgjee01owa0wgefdnibubljhpcayatmbgaucvfpqinmrzyzjvjzvnaa5 38 SToMe6rp+0n95fpzlE6LzIW59vjDiF/tuFrKAvOzeh61gS6cPkWMxd8iLztX+znx 39 cl1vs58exgkvi5r9bzu= 40 END NEW CERTIFICATE REQUEST Admin Ausgabe

5 Listing 6:»ldapmodify«01 # ldapmodify x h foo.example.com p 389 D "cn=directory Manager" W << EOF 02 dn: cn=config 03 changetype: modify 04 add: nsslapd security 05 nsslapd security: on replace: nsslapd ssl check hostname 08 nsslapd ssl check hostname: off dn: cn=encryption,cn=config 11 changetype: modify 12 replace: nsssl3 13 nsssl3: on replace: nssslclientauth 16 nssslclientauth: allowed add: nsssl3ciphers 19 nsssl3ciphers: rsa_null_md5,+rsa_rc4_128_md5,+rsa_ rc4_40_md5,+rsa_rc2_40_md5, 20 +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_ fips_3des_sha,+fortezza, 21 +fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_ export1024_with_rc4_56_sha, 22 +tls_rsa_export1024_with_des_cbc_sha dn: cn=rsa,cn=encryption,cn=config 25 changetype: add 26 objectclass: top 27 objectclass: nsencryptionmodule 28 cn: RSA 29 nssslpersonalityssl: ldap server cert 30 nsssltoken: internal (software) 31 nssslactivation: on 32 EOF Ein größeres Problem ist, 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 darauf. Das Problem lässt sich lösen, indem 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, Listing 7:»certutil«01 # certutil d /etc/dirsrv/slapd foo/ L Certificate Nickname Trust Attributes 04 SSL,S/MIME,JAR/XPI 05 CA Certificate CT,, 06 ldap server cert u,u,u Abbildung 5: Eine Replikation lässt sich sowohl über LDIF als auch über die grafische Konsole einrichten. anders als etwa bei Open SSL existiert zur Verwaltung von X.509-Zertifikaten ein eigenes Datenbank-Backend in Form der Dateien»cert8.db«,»key3.db«und»secmod.db«. Sie liegen unterhalb von»/etc/ dirsrv/admin serv«für den Admin-Server beziehungsweise»/etc/dirsrc/slapd hostname«für den Director-Server. Mit dem Tool»certutil«kann der Administrator dann für beide Server einen Zertifikatsrequest oder ein selbst signiertes Zertifikat erzeugen. Den dafür notwendigen Aufruf zeigt Listing 5. Den so erzeugten Zertifikatsrequest kann der Directory-Administrator zum Signieren an eine Zertifizierungsstelle (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 sehen die Aufrufe von»certutil«folgendermaßen aus: # certutil A n "CA Certificate" t "CT,,U " i ca.crt d /etc/dirsrv/slapd foo/ # certutil A n "ldap server cert" t "u,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 Serverkonfiguration anzupassen. Da die komplette Konfiguration im LDAP-Baum liegt, lassen sich die notwendigen Modifikationen sehr 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]. Das Tool»certutil«bestätigt schließlich, dass der Import der beiden Zertifikate geklappt hat (Listing 7). SSL-Test Nach einem Neustart des Servers ist dieser nun in der Lage, SSL/ TLS-gesicherte Verbindungen durchzuführen. Damit nun sowohl die LDAP-Client-Tools als auch PAM zur Authentifizierung auf diesen geschützen Kanal zurückgreifen, gibt der Admin bei der Konfiguration von PAM über das Tool»system config authentication«einfach die URL an, von der er das CA-Zertifikat beziehen kann. Es ist zur Überprüfung des Server-Zertifikats notwendig. Alternativ kopiert er das CA-Zertifikat einfach ins Verzeichnis»/etc/openldap/cacerts«. Abschließend ist noch dieses Verzeichnis durch»cacertdir_rehash«zu indizieren. Ob die SSL-/ TLS-Kommunikation zum Server funktioniert, ist am besten über 76 Ausgabe Admin

6 Netzwerk Listing 8:»/tmp/consumer.ldif«01 ### LDIF Daten zum Erzeugen eines Benutzer Kontos auf dem Consumer Server 02 dn: cn=replication manager,cn=config 03 objectclass: inetorgperson 04 objectclass: person 05 objectclass: top 06 cn: replication manager 07 sn: RM 08 userpassword: password 09 passwordexpirationtime: Z ### LDIF Daten zur Konfiguration des Consumer Servers 12 dn: cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config 13 changetype: add 14 objectclass: top 15 objectclass: nsds5replica 16 objectclass: extensibleobject Abbildung 6: Auch die Konfiguration der Synchronisation mit einem Windows-Active-Directory-Server ist über die Konsole sehr leicht möglich. den Aufruf von»ldapsearch«mit der Option» ZZZ«zu erfahren. Sie 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-Zertifikats. Hier muss zwingend der Rechnername des LDAP-Servers stehen, sonst verweigert»ldapsearch«seine Arbeit mit einem Verifikationsfehler des Zertifikats. Replikation Ein weiteres interessantes Feature des s 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 heißt Single-Master-Replikation, letztere 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. Gründe dafür sind Ausfallsicherheit oder eine große Anzahl von Clients, die Änderungen an der Datenbank durchführen, mit deren Bewältigung ein einzelner Server überlastet wäre. Auch die geografische Aufteilung eines Directory-Server- Setups kann ein Grund dafür sein, eine MMR durchzuführen. Man denke dabei beispielsweise an ein Unternehmen mit mehreren Standorten, das den Directory- Server für die Benutzer-Authentifizierung einsetzt. Hier möchte wohl niemand für jede Änderung an der Datenbank eine WAN-Verbindung zu jenem Standort aufbauen, an dem sich der einzige Masterserver mit einer Schreib-Kopie der LDAP- Datenbank befindet. Master und Slave 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). Das Beispiel zeigt wieder den Weg der Konfiguration über die Kommandozeile. Das ist besser, um solche Abläufe zu automatisieren. Das Setup besteht aus mehreren Schritten. Da der auf der Push-Technologie basiert, muss auf dem Consumer-Server ein Benutzerkonto existieren. Der Master verwendet es, um sich am Replica-Server 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 17 cn: replica 18 nsds5replicaroot: dc=example,dc=com 19 nsds5replicatype: 2 20 nsds5replicabinddn: cn=replication manager,cn=config 21 nsds5flags: 0 Lese-Kopie der LDAP-Datenbank. Die notwendigen LDIF-Daten für diese Konfiguration zeigt Listing 8. Die Datei importiert der vertraute»ldapadd«-aufruf: ldapadd x f /tmp/consumer.ldif D "cn=u Directory Manager" w redhat123 Listing 9:»/tmp/supplier.ldif«01 ### LDIF Daten zum Anlegen des Changelogs auf dem Supplier Server 02 dn: cn=changelog5,cn=config 03 changetype: add 04 objectclass: top 05 objectclass: extensibleobject 06 cn: changelog5 07 nsslapd changelogdir: /var/lib/dirsrv/slapd foo/ changelogdb 08 nsslapd changelogmaxage: 10d dn: cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config 11 changetype: add 12 objectclass: top 13 objectclass: nsds5replica 14 objectclass: extensibleobject 15 cn: replica 16 nsds5replicaroot: dc=example,dc=com 17 nsds5replicaid: 7 18 nsds5replicatype: 3 19 nsds5flags: 1 20 nsds5replicapurgedelay: nsds5replicabinddn: cn=replication manager,cn=config Admin Ausgabe

7 Listing 10:»/tmp/agreement.ldif«01 dn: cn=examplefooagreement,cn=replica,cn= "dc=example,dc=com",cn=mapping tree,cn=config 02 changetype: add 03 objectclass: top 04 x: nsds5replicationagreement 05 cn: ExampleAgreement 06 nsds5replicahost: foobar consumer 07 nsds5replicaport: nsds5replicabinddn: cn=replication manager 09 nsds5replicabindmethod: SIMPLE 10 nsds5replicaroot: dc=example,dc=com 11 description: agreement between supplier foo and consumer foobar 12 nsds5replicacredentials: {DES} UXRbhvozeN9LWdueOEbPeQ== 13 nsds5beginreplicarefresh: start 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 alle Änderungen der LDAP-Datenbank, die nun auf den Consumer zu übertragen sind. Zum Schluss ist auch diesem Rechner die Rolle mitzuteilen, die er einnehmen soll, hier also die des Masterservers mit einer Schreib-Kopie der LDAP-Datenbank. Die notwendigen LDIF-Daten für ein»ldapadd«zeigt Listing 9. Nach diesen Vorarbeiten ist es Zeit für das Replication Agreement zwischen Master und Slave. Hierbei handelt es sich um ein Regelwerk, das festlegt, zwischen welchen Rechnern und mit welchen Eigenschaften eine Replikation der LDAP-Daten ablaufen soll. Ein Beispiel- Agreement zeigt Listing 10. Nach einem Import des Replication Agreement auf dem Supplier-Server startet die Replikation der LDAP-Daten sofort. Verantwortlich hierfür ist das Attribut»nsds5Begin- ReplicaRefresh«. Die MMR-Replikation läuft ganz ähnlich ab. Der Unterschied besteht darin, dass jeder Server gleichzeitig Supplier und Consumer sein muss. Eine Beschreibung aller wichtigen Attribute, steht im Administration-Guide des Red Hat Enterprise Listing 11:»/tmp/winad sync.ldif«01 Windows Domain Name: winad.com 02 Windows Subtree: cn=users,dc=winad,dc=com 03 DS Subtree: ou=people,dc=example,dc=com 04 Domain Controller Host: bar.winad.com 05 Port Number: Bind as: cn=administrator,cn=users,dc=winad,dc=com Directory Servers, dem kommerziellen Gegenstück zum 389-DS [5]. Replikation mit Active Directory Das Anmelden von Linux-Clients über einen Windows-Rechner ist meist etwas problematisch. Besser ist es, den Linux- Clients einen nativen Weg zur Benutzeranmeldung anzubieten. 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). Alternativ ist die Konfiguration auch über die Konsole möglich. Auf der Windows- Seite muss der Administrator 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- oder [7] für 64-Bit-Systeme 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 Linux-Seite bereits eine Zertifizierungsstelle, dann 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-in zum Zertifikats-Management kann er es dann zusammen mit dem CA-Zertifikat in den Zertifikatsspeicher des Rechners laden. Ein Technet-Artikel beschreibt den genauen Ablauf [8]. Eine genaue Anleitung für das Replikations- Setup zwischen 389-DS und Windows- AD liefert [9]. Fazit Der 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 weiterkommt und Fragen hat. Ansonsten lohnt sich auch ein Blick die in Dokumentation von Red Hats Directory Server [13]. (ofr) n Infos [1] : [ directory. fedoraproject. org] [2] Konfigurationsoptionen für das Setup- Programm: [ www. redhat. com/ docs/ manuals/ dir server/ 8. 1/ install/ Installation_Guide Advanced_Configuration Silent. html# Installation_Guide Advanced_Configuration inf File] [3] Projektseite der Network Security Services (NSS) : [ www. mozilla. org/ projects/ security/ pki/ nss/] [4] SSL/ TLS-Konfiguration: [ www. redhat. com/ docs/ manuals/ dir server/ 8. 1/ admin/ Managing_SSL. html] [5] LDAP-Replikation auf der Kommandozeile: [ www. redhat. com/ docs/ manuals/ dir server/ 8. 1/ admin/ Managing_Replication Configuring Replication cmd. html] [6] Pass Sync als MSI-Paket für 32 Bit: [ port389. org/ download/ 389 PassSync i386. msi] [7] Pass Sync als MSI-Paket für 64 Bit: [ port389. org/ download/ 389 PassSync x86_64. msi] [8] How to enable LDAP over SSL with a thirdparty certification authority: [ support. microsoft. com/ default. aspx? scid=kb;en us;321051] [9] Howto zur Replikation mit Windows-ADS: [ directory. fedoraproject. org/ wiki/ Howto:WindowsSync] [10] 389-Wiki: [ directory. fedoraproject. org/ wiki/] [11] 389-Mailinglisten: [ directory. fedoraproject. org/ wiki/ Mailing_Lists] [12] Tool zum Konvertieren von Open-LDAP- Schemadaten ins 389-DS-Format: [ directory. fedoraproject. org/ download/ ol schema migrate. pl] [13] Dokumentation zum Red Hat Directory Server: [ www. redhat. com/ docs/ manuals/ dir server/ 8. 1/] 78 Ausgabe Admin