Schaut man sich OpenLDAP und denFedora Directory Server (FDS) an,so finden sich jede Menge Gemein-

samkeiten. Dies ist nicht weiter verwun-derlich, basieren doch beide auf demMitte der Neunzigerjahre entstandenenslapd-Projekt der Universität Michigan.Dessen ursprüngliche Entwickler fandensich damals jedoch schnell auf der Ge-haltsliste von Netscape wieder, weshalbdas slapd unter dem Namen „NetscapeDirectory Server“ größere Bekanntheiterlangte. Im Sommer 2005 gingen dieRechte hierfür an Red Hat über. Seitdemsind die Quellen der Software offen, undmit dem jetzt in „389 Directory Server“(389DS) umbenannten FDS existiert ei-ne Community-Version des kommer-ziellen Red Hat Directory Server.

Zwar entwickelte sich OpenLDAPauch stetig weiter, jedoch lässt es vieleFunktionen des 389DS vermissen. Mul-ti-Master-Betrieb kennt dieser schon seitden Anfangstagen, OpenLDAP führtedie Funktion erst mit der Release-Reihe2.4.x ein. Das dynamische Verwalten

der Konfiguration über LDAPs Direc-tory Information Tree (DIT) ist eben-falls erst seit Version 2.3 Teil derOpenLDAP-Quellen.

Im Bereich Usability hat 389DSebenfalls die Nase vorn: So gehörenzum Lieferumfang nicht nur ein Web-Frontend, über das man mit dem Serverkommunizieren kann, auch eine Java-basierte grafische Konsole zur Admi-nistration ist mit an Bord. Für einenahtlose Integration in eine bestehendeActive-Directory(AD)-Domäne existiertebenfalls eine Lösung. Über klassischeReplikationsrichtlinien lassen sich Ob-jekte zwischen beiden Welten austau-schen, das schließt den Austausch vonPasswörtern mit ein. Dank WinSync las-sen sich diese auf der Windows-Seiteabfangen und an einen 389DS senden,bevor sie als nicht reversibler Hash aufdem Dateisystem des Domänen-Con-trollers landen.

Viele Administratoren älterer Open-LDAP-Installationen fragen sich somitzu Recht, ob eine Migration zu einer ak-tuellen OpenLDAP-Version überhauptnoch sinnvoll ist oder ob es nicht loh-nender wäre, direkt auf den 389DS zuwechseln. Dieser Artikel zeigt potenziel-le Migrationswege auf.

Ein wenig Vorarbeit muss seinAuf einem Fedora-10-System erfolgt dieInstallation des Verzeichnisdienstes undder grafischen Konsole einfach via yuminstall fedora-ds fedora-idm-console ausdem Standard Fedora Software-Reposi-tory heraus. Der 389DS besteht aus dreiKomponenten: Das Herzstück ist derCore-Server. Er ist LDAPv3-kompatibelund bietet unterhalb von /usr/lib/dirsrv/slapd-hostname/ eine Menge Komman-dozeilen-Tools zur Administration an.Die dazugehörige Managementplatt-form ist der Administrationsserver. Überdessen grafisches Frontend, die Direc-tory-Server-Konsole, erfolgen sämtlicheadministrativen Aufgaben für den Core-

122 iX 6/2009

x-TRACTl OpenLDAP und der 389 Directory Server haben als gemeinsame Wurzel das slapd-

Projekt der Universität Michigan.

l Neben einem grafischen Administrations-GUI bietet 389DS auch Tools zum Daten-abgleich mit Active-Directory-Servern.

l Ein Umzug der Daten kann wahlweise via Replikation oder per LDIF-Datenimporterfolgen.

Umzug von OpenLDAP zum 389 Directory Server

MigrationshilfeThorsten Scherf

Bei hierarchischen Open-Source-Datenbanken denkenAnwender oft zunächst an OpenLDAP. Mit dem 389 DirectoryServer aus dem Fedora Projekt existiert jedoch seit einiger Zeiteine Alternative, die nicht nur wegen des grafischenKonfigurations-Tools eine Datenmigration rechtfertigen würde.

PRAXIS Verzeichnisdienste

Server. Da sie komplett in Java ge-schrieben ist, benötigt die Installationein aktuelles JRE.

Über ein Perl-Skript (setup-ds-ad-min.pl) stößt man die eigentliche Instal-lationsroutine an. Alle notwendigenKonfigurationsoptionen lassen sich ent-weder interaktiv oder über eine *.inf-Datei an das Setup-Tool übergeben. Die*.inf-Datei enthält drei Abschnitte (Ge-neral, Admin, slapd), über die sich so-wohl der Core- als auch der Admin-Ser-ver konfigurieren lassen; Listing 1 zeigtein Beispiel. Eine Beschreibung derOptionen findet sich in der Onlinedoku-mentation (siehe „Onlinequellen“, [b]“.

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

Hat die Installation geklappt, starten imAnschluss der Admin- und der Direc-tory-Server, wie die Ausgabe von net-stat belegt:

# netstat -ntlp |grep -e 9830 -e 389tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN —

1813/httpd.workertcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN —

2427/ns-slapd

Über die Konsole lässt sich dann viahttp://fds.local:9830 eine erste Verbin-dung zum Admin-Server herstellen(Abbildungˇ1). Dieser lässt sich, eben-so wie der Directoy-Server, bequemüber die Konsole verwalten. Über denMenüpunkt „Import Database“ kannman beispielsweise eine exportierteOpenLDAP-Datenbank in den 389DSeinlesen. Jedoch funktioniert dies nichtauf Anhieb, da beide Dienste unter-schiedliche Schemata verwenden. Dazuspäter mehr.

Läuft die Konsole auf der eigenenArbeitsstation, möchte man sicherlichseine Daten per SSL/TLS schützen, be-vor sie über das Netz wandern. Sowohlder Admin- als auch der Directory-Ser-ver lassen sich für eine SSL/TLS-Kom-munikation konfigurieren. 389DS ba-siert auf den Network Security Services(NSS) [c], das heißt, anders als bei-spielsweise bei OpenSSL, existiert zurVerwaltung von X.509-Zertifikaten eineigenes Datenbank-Backend in Formder beiden Dateien cert8.db und key3.db. Beim 389DS liegen diese unterhalbvon /etc/dirsrv/admin-serv/ für denAdmin- beziehungsweise /etc/dirsrc/slapd-hostname/ für den Directory-Ser-ver. Mit certutil kann man für beideServer einen Zertifikats-Request erstel-len und anschließend in die Datenbankimportieren. Dies funktioniert natürlichauch reibungslos über die grafischeKonsole, jedoch erfolgt gerade in gro-

ßen Umgebungen die Konfiguration oftauf der Kommandozeile, da sich so dieArbeit mit Skripten automatisierenlässt. Listing 2 beschreibt im Detail,wie sich ein Zertifikats-Request erzeu-gen lässt.

Eine so erzeugte Zertifikatsanfragekann man nun zum Signieren an eineZertifikatsstelle (CA) senden und daszurückerhaltene Zertifikat, zusammenmit dem Zertifikat der CA, in die Da-tenbank des Admin- und Directory-Ser-vers importieren. Für den Import in dieDirectory-Server-Datenbank sieht derAufruf von certutil wie folgt aus:

certutil -A -n "CA Certificate" -t "CT,," -i myca.crt -d —/etc/dirsrv/slapd-tiffy/

certutil -A -n "ldap.cert" -t "p,p,p" -i ldap.crt -d —/etc/dirsrv/slapd-tiffy/

Nun ist noch die Server-Konfigurationanzupassen. Da die komplette Konfigu-ration im LDAP-Baum liegt, könnendie Modifikationen wie in Listing 3 be-

schrieben jedoch einfach per ldapmodifyerfolgen.

Sollte ein eventuell vorhandenerOpenLDAP-Server schon über ein Zer-tifikat verfügen, ist dieses zuerst insPKCS#12-Format zu konvertieren, be-vor man es in die NSS-Datenbank des389DS importiert. Die Datei mit demprivaten Schlüssel heißt hier ol.key,das Zertifikat selbst befindet sich inol.crt. Der Aufruf openssl pkcs12 -in-key ol.key -in ol.crt -out ol.pk12 -exportliefert als Ergebnis die PKCS#12-Dateiol.pk12. Diese lässt sich per pk12util -i ol.pk12 -d /etc/dirsrv/slapd-tiffy/ indie NSS-Datenbank importieren.

Das CA-Zertifikat kann man, wieweiter oben gezeigt, via certutil impor-

iX 6/2009 123

Listing 1: setup.inf

[General]AdminDomain = fds.localSuiteSpotGroup = nobodyConfigDirectoryLdapURL =ldap://tiffy.tuxgeek.de:60389/o=NetscapeRootConfigDirectoryAdminID = adminSuiteSpotUserID = nobodyConfigDirectoryAdminPwd = RedHatFullMachineName = tiffy.tuxgeek.de[admin]ServerAdminID = adminServerAdminPwd = RedHatSysUser = nobodyPort = 9830[slapd]InstallLdifFile = suggestServerIdentifier = tiffyServerPort = 60389AddOrgEntries = YesRootDN = cn=Directory ManagerRootDNPwd = RedHatSlapdConfigForMC = yesSuffix = dc=fds,dc=localUseExistingMC = 0AddSampleEntries = No

Über die grafische Konsole lässt sich eine HTTP-Verbindung zum Admin-Serveraufbauen (Abb. 1).

Listing 2: Ablauf zum Erstellen eines Zertifikats-Requests

# certutil -Ra -s "cn=tiffy.tuxgeek.de" -o ldap.req -d /etc/dirsrv/slapd-tiffy/

Enter Password or Pin for "NSS Certificate DB":A random seed must be generated that will be used in thecreation of your key. One of the easiest ways to create arandom seed is to use the timing of keystrokes on a keyboard.To begin, type keys on the keyboard until this progress meteris 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 ldap.req Certificate request generated by Netscape certutilPhone: (not specified)Common Name: tiffy.tuxgeek.deEmail: (not specified)Organization: (not specified)State: (not specified)Country: (not specified)-----BEGIN NEW CERTIFICATE REQUEST-----MIIBWjCBxAIBADAbMRkwFwYDVQQDExB0aWZmeS50dXhnZWVrLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV1a+bnypcdoLhmS9XT1v+tcAq8Q8fn0me9LCbaOFvBUD7qEbpXgDajglVrHfFuRyqcoJ19xWoxKA+95+LIWG3l6/UMa38n9XVW9+RxWkYR+cdKphEr4iteWsdjqSl+OfUZrOa0wr1VCiIGwG3k/4aD8IbLhegLZL0dAV7DSb07wIDAQABoAAwDQYJKoZIhvcNAQEFBQADgYEACDshh6KpKiYXQEVi5p9GLNM7ryC83gxWMGJeE01Owa0WGeFdNIbuBLJHPcAYaTmbGAUcvFPqinMRZYzjvjZvNaa5SToMe6rp+0n95fpzlE6LzIW59vjDiF/tuFrKAvOzeh61gS6cPkWMxd8iLztX+znxcl1VS58ExGKVI5R9bzU=-----END NEW CERTIFICATE REQUEST-----

tieren. Der Aufruf certutil -d /etc/dirsrv/slapd-tiffy/ -L listet die vorhande-nen Zertifikate auf und bestätigt, dassalles geklappt hat:

Certificate Nickname Trust AttributesSSL,S/MIME,JAR/XPI

CA Certificate CT,, OpenLDAP-Cert u,u,u

Ein anschließender Neustart der beidenDienste sorgt dafür, dass diese nun fürverschlüsselte und authentifizierte An-fragen zur Verfügung stehen.

Ein gemeinsames Schema findenAls Nächstes sollte man sich um dasSchema der beiden Dienste kümmern.Ähnlich wie in aktuellen OpenLDAP-Installationen gibt es beim 389DS ei-nen Eintrag cn=schema im LDAP-Baum, in dem das Schema gespeichertist. In älteren OpenLDAP-Versionenfinden sich die Schema-Definitionen,ebenso wie die Access-Control-Listen(ACLs), in /etc/openldap/slapd.conf.Anders als bei OpenLDAP basiert dasSchema beim 389DS auf RFC2252.Glücklicherweise existiert mit ol-sche-ma-migrate.pl [d] ein hilfreiches Toolzur Konvertierung, das das Schemaauch optisch noch etwas aufbereitet:

perl ol-schema-migrate.pl -c -b /etc/openldap/ —schema/samba.schema > /etc/dirsrv/slapd-tiffy/ —

schema/91-samba.ldif

Wichtig bei der Konvertierung ist,dass die neue Schema-Datei keineLeerzeilen enthält, da sonst der Importfehlschlägt. Außerdem unterstützt der389DS in der aktuellen Version man-che Syntax-Beschreibungen von Attri-buten nicht, obwohl RFC2252 diesedefiniert. Im Einzelnen handelt es sichum den Syntax Printable String (OID1.3.6.1.04.1.1466.115.121.1.44) undden Numeric String (OID 1.3.6.1.4.1.1466.115.121.1.36). Als Workaroundhierfür bleibt momentan nur die Ver-wendung einer anderen Syntax-Be-schreibung, die auf Printable Stringoder Numeric String zurückgreift. Inder Praxis hat sich als Ersatz die Syn-tax-Beschreibung Directory String(OID 1.3.6.1.4.1.1466.115.121.1.15)bewährt. Davon abgesehen sollte nacheinem Neustart der 389DS-Instanz dasalte OpenLDAP-Schema auch im neu-en Verzeichnisdienst zur Verfügungstehen. Möchte man die Downtimeseines Dienstes so gering wie möglichhalten, lässt sich das Schema auch dy-namisch, ohne Neustart des Servers,veröffentlichen. Hierfür existiert einkleines Perl-Skript namens schema-re-load.pl:

/usr/lib/dirsrv/slapd-tiffy/schema-reload.pl -D —cn="Directory Manager" -w password

Alternativ lässt sich über die Option „-d“ ein zusätzliches Schema-Ver-zeichnis angeben, sollte das neue Sche-ma nicht unterhalb von /etc/dirsrv/slapd-name/schema/ zur Verfügung ste-hen. Richtet man später mehrere Repli-

kationsserver ein, so ist daran zu den-ken, das das Schema nicht zwischenden Servern repliziert wird. ZusätzlicheSchema-Informationen sind also auf al-len verwendeten Servern zu speichern.

ACL-Konvertierung meist mit HandarbeitEtwas schwieriger sieht es bei der Kon-vertierung von bestehenden Access-Control-Listen (ACLs) aus. OpenLDAPund 389DS verwenden eine komplettunterschiedliche Syntax, weshalb manman die ACLs idealerweise manuellumstellt. Da sich die Anzahl der vor-handenen Regeln aber meistens imRahmen hält, ist dies nicht weiterschlimm, zumal man sich bei dieserGelegenheit die bestehenden Regelneinmal genau ansehen kann. In derPraxis hat sich oftmals gezeigt, dasshistorisch gewachsene ACLs redun-dante Einträge enthalten. Die Regeln,auch Access-Control-Instructions ge-nannt, folgen beim 389DS folgenderSyntax:

aci: (target)(version 3.0;acl "name";permission —bind_rules;)

Das Target kann ein komplettes LDAP-Objekt oder ein einzelnes Attribut sein,üblicherweise dargestellt durch seinenDistinguished Name (DN) oder einenLDAP-Filter. name ist eine Bezeichnungfür diesen Regelsatz. permission gibt dieRechte auf dem genannten Target anund bind_rules bestimmt die jeweiligen

124 iX 6/2009

PRAXIS Verzeichnisdienste

Nach einer Konvertierung steht auch das alte OpenLDAP-Schema zur Verfügung (Abb. 2).

Listing 3: Modifikationen am LDAP-Baum

# ldapmodify -x -h tiffy.fds.local -p 389 -D "cn=directory manager"-W <<eofdn: cn=encryption,cn=configchangetype: modifyreplace: nsSSL3nsSSL3: on-replace: nsSSLClientAuthnsSSLClientAuth: allowed-add: nsSSL3CiphersnsSSL3Ciphers: -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_shadn: cn=configchangetype: modifyadd: nsslapd-securitynsslapd-security: on-replace: nsslapd-ssl-check-hostnamensslapd-ssl-check-hostname: offdn: cn=RSA,cn=encryption,cn=configchangetype: addobjectclass: topobjectclass: nsEncryptionModulecn: RSAnsSSLPersonalitySSL: ldap-certnsSSLToken: internal (software)nsSSLActivation: oneof

Anmeldeparameter für einen Benutzer.Im folgenden Beispiel hat der Benutzerfoobar Schreibrechte auf alle Attributeseines eigenen Directory-Eintrags:

aci: (target="ldap:///uid=foobar,dc=fds,dc= —local")(targetattr=*)(version 3.0;acl "foobar —

example";allow (write) userdn="ldap:///self";)

Gibt es für einen Zugriff keine passen-de ACI, ist der Zugriff verboten. Ausdiesem Grunde existiert in der Stan-dardkonfiguration unter anderem derfolgende Regelsatz, womit alle Benut-zer Leserechte auf sämtliche Attributeaußer userPassword haben:

aci: (targetattr != "userPassword")(version 3.0;acl —"Enable anonymous access";allow (read,—

compare,search) userdn = "ldap:///anyone";)

Die Regeln sind entweder über die grafi-sche Konsole oder über eins der Kom-mandozeilenwerkzeuge der Datenbankhinzuzufügen. Alle ACIs sind im Di-rectory-Baum als zusätzliche Attributegespeichert. Da es sich hierbei um so-genannte „Operational Attributes“ han-delt, muss man deren Ausgabe expliziterfragen. Die Syntax hierfür sieht wiefolgt aus:

ldapsearch -x -b o=netscapeRoot -W ,(aci=*)' aci

Datenabgleich mit anderen ServernSind alle Vorbereitungen abgeschlos-sen, hat man alle notwendigen Zertifi-kate, Schemata und ACIs konvertiert,geht es schließlich an die Migration dereigentlichen LDAP-Datenbank. Hierfürexistieren mehrere Verfahren. Zum ei-nen lässt sich der neue 389DS als Repli-kationspartner in die OpenLDAP-Kon-figuration aufnehmen. Somit landenalle Daten in einer Lesekopie auf dem389DS. Beim Einrichten des „Repli-ca“-Servers ist daran zu denken, dieOperational Attributes von der Übertra-gung auszuschließen. In den meistenFällen sind diese speziellen Attributezwischen verschiedenen LDAP-Ser-vern nicht kompatibel.

Ein entsprechender Abschnitt in derOpenLDAP-Konfigurationsdatei /etc/openldap/slapd.conf sollte bei der De-finition der Replica-Hosts die nicht zureplizierenden Attribute aufführen:

replica uri=tiffy.fds.localattr!=structuralObjectClass,entryUUID,entryCSN<weitere parameter>

Klappt der Online-Abgleich zwischenOpenLDAP und 389DS, lässt sichspäter der 389DS zum Master-Serverheraufstufen, sodass darüber auch Än-derungen an der LDAP-Datenbank er-folgen können. Auf Wunsch lassen sichweitere 389DS-basierte Replicas hin-zufügen. Hierfür existiert auf Source-forge ein nützliches Skript [e]. Alterna-tiv kann eine solche Konfiguration überdie Konsole erfolgen.

Eine weitere Möglichkeit bestehtdarin, einen Dump der bestehendenOpenLDAP-Datenbank zu erzeugen.Hierfür könnte man beispielsweise aufdas Kommanozeilentool slapcat zu-rückgreifen. Allerdings ist dies nicht

ganz unproblematisch, da slapcat diekomplette LDAP-Datenbank, inklusiveder Operational Attributes, im LDIF-Format ausgibt. Besser man greift aufldapsearch zurück:

ldapsearch -x -b "dc=ol,dc=local" -D "cn=—Manager,dc=ol,dc=local" -W -LLL > ol.ldif

Dabei bewirkt die Option -LLL, dassldapsearch lediglich die LDIF-Datenohne zusätzliche Header- oder Kom-mentar-Informationen ausgibt. Die soerzeugte LDIF-Datei kann man in den389DS importieren – wahlweise überdie grafische Konsole oder über dieKommandozeile:

ldapadd -x -f ol.ldif -D cn="Directory Manager" -W

Treten beim Import Fehler auf, liegtdies sehr wahrscheinlich an verwende-ten Attributen oder Objektklassen, dieder 389DS nicht kennt. Hier sollteman sich das Schema dann noch ein-mal genauer ansehen. Ansonsten hilftwie immer ein Blick in die Log-Da-teien weiter, die sich üblicherweiseunterhalb von /var/log/dirsrv/slapd-hostname/ befinden. (avr)

THORSTEN SCHERF

arbeitet als Consultant und Trainer fürRed Hat EMEA und ist auf den BereichSecurity spezialisiert.

iX 6/2009 125

[a] 389 Directory Server directory.fedoraproject.org/wiki oder port389.org[b] Optionen für setup.inf www.redhat.com/docs/manuals/dir-server/install/8.0/

Installation_Guide-about-setup-ds-admin.pl.html[c] NSS www.mozilla.org/projects/security/pki/nss/[d] ol-schema-migrate.pl directory.fedoraproject.org/download/ol-schema-migrate.pl[e] FDS-Management-Tool fdstools.wiki.sourceforge.net

Onlinequellen

Im 389 Directory Server lassen sich bis zu vier Master-Replicas einrichten (Abb. 3).

www.ix.de/ix0906122 x