Bäumchen wechsle dich
Werbung
Verzeichnisdienste PRAXIS avr.penrose_id17058_ Penrose: Unterschiedliche Datenquellen via LDAP Bäumchen wechsle dich Thorsten Scherf In heutigen IT-Landschaften gestaltet sich die Verwaltung der stark zunehmenden Benutzerinformationen immer schwieriger – nicht zuletzt, weil viele unterschiedliche Backend-Systeme zum Einsatz kommen. Das freie Identity-Management-System Penrose-Server hilft, den Überblick nicht zu verlieren, und stellt einen einheitlichen Blick auf vorhandene Benutzerinformationen sicher. E in gängiges Szenario aus der Praxis: Zwei Unternehmen fusionieren. Firma A setzt zwei unterschiedliche Identity-Systeme ein. So befinden sich die Daten der Mitarbeiter in einem LDAPv3-konformen Directory-Server, die Kundeninformationen hingegen in einer SQL-Datenbank. Firma B setzt ausschließlich Active Directory (AD) ein. Die CRM-Applikation aus Firma B ist nicht in der Lage, auf Daten aus einer SQL-Datenbank zuzugreifen, Anwendungen aus Firma A wiederum erwarten ein LDAPv3-konformes Schema und können nichts mit dem proprietären Schema eines ADServers anfangen. Einen potenziellen Ausweg bietet der Einsatz eines Meta-Directory wie Novells DirXML, das alle vorhandenen Identitäten aufnimmt und verwaltet. Der entscheidende Nachteil dieses Ansatzes besteht im nicht zu unterschätzenden Synchronisierungsaufwand zwischen den Systemen. Weitere Schwierigkeiten birgt gegebenenfalls die Berechtigungstruktur der synchronisierten Datenlandschaft. Dieser Artikel beschreibt einen anderen Lösungsweg: ein virtuelles Directory mit Penrose. Hier bleiben die Daten auf ihren ursprünglichen Systemen gespeichert und lassen sich auch weiterhin über diese verwalten. Das virtuelle Directory sorgt für einen einheitlichen Blick auf alle vorhandenen Daten, unabhängig davon, ob sie sich in einer SQL-Datenbank, einem LDAP-, AD-Verzeichnis- dienst oder auf einem NIS-Server befinden. Über die LDAP-Schnittstelle von Penrose lassen sich die so konsolidierten Daten abfragen. Alle Applikationen benötigen damit für den Zugriff auf die Daten nur noch eine einzelne Schnittstelle – LDAP. Ein virtuelles Directory bietet neben der Konsolidierung von Identity-Informationen weitere Vorteile. So kann es beispielsweise auch als Proxy für bestehende Directory-Server agieren. Be- LDAP-Abfragen Penrose x-TRACT 2 ● Mit Penrose steht eine mächtiges Identity Management Framework als Open-Source-Software zur Verfügung. ● Identitätsinformationen aus LDAP-, SQL-, NIS- oder Active-Directory-Quellen lassen sich mit Penrose konsolidieren. ● Mit dem Eclipse-RCP-Client Penrose-Studio existiert ein komfortables GUI zur Konfiguration des Servers. Dateien DBMS LDAP Active Directory Penrose sorgt für eine Konsolidierung der unterschiedlichen IdentitySysteme (Abb. 1). iX 3/2009 Listing 2: conf/connections.xml Listing 1: conf/server.xml <server> <system-property> <property-name>java.rmi.server.hostname</property-name> <property-value>rhel5-rhvd.virt.tuxgeek.de</property-value> </system-property> <session/> <adapter name="JDBC"> <adapter-class>org.safehaus.penrose.jdbc.adapter.JDBCAdapter</adapter-class> </adapter> <adapter name="LDAP"> <adapter-class>org.safehaus.penrose.ldap.adapter.LDAPAdapter</adapter-class> </adapter> <adapter name="NIS"> <adapter-class>org.safehaus.penrose.nis.adapter.NISAdapter</adapter-class> </adapter> <root> <root-dn>uid=admin,ou=system</root-dn> <root-password>secret</root-password> </root> [...] <connections> <connection name="rhel5-ds"> <adapter-name>LDAP</adapter-name> <parameter> <param-name>java.naming.security.credentials</param-name> <param-value>redhat123</param-value> </parameter> <parameter> <param-name>java.naming.provider.url</param-name> <param-value>ldap://rhel5-ds.virt.tuxgeek.de/</param-value> </parameter> <parameter> <param-name>java.naming.security.principal</param-name> <param-value>cn="Directory Manager"</param-value> </parameter> </connection> <connection name="rhel5-db"> <adapter-name>JDBC</adapter-name> <parameter> <param-name>driver</param-name> <param-value>com.mysql.jdbc.Driver</param-value> </parameter> <parameter> <param-name>url</param-name> <param-value>jdbc:mysql://rhel5-rhvd.virt.tuxgeek.de/jdbc?autoReconnect=true</param-value> </parameter> <parameter> <param-name>user</param-name> <param-value>root</param-value> </parameter> </connection> <connection name="winad"> <adapter-name>LDAP</adapter-name> <parameter> <param-name>java.naming.factory.initial</param-name> <param-value>com.sun.jndi.ldap.LdapCtxFactory</param-value> </parameter> <parameter> <param-name>java.naming.provider.url</param-name> <param-value>ldap://winad.virt.tuxgeek.de/</param-value> </parameter> <parameter> <param-name>java.naming.security.principal</param-name> <param-value>cn=Administrator,cn=Users,dc=virt,dc=tuxgeek,dc=de</param-value> </parameter> <parameter> <param-name>java.naming.security.credentials</param-name> <param-value>Helsink!</param-value> </parameter> </connection> </connections> Listing 3: conf/sources.xml nötigt ein Partner Zugriff auf einen bestimmten Teilbaum des Directory, so lässt sich dieser über die Proxy-Funktion bereitstellen. Für die so exportierten Objekte kann man neue Zugriffsregeln erzeugen, sogenannte AccessControl-Instructions (ACIs). Darüber hinaus lässt sich über ein virtuelles Directory eine Migration von NIS nach LDAP durchführen, indem schrittweise die Umstellung der Clients auf LDAP erfolgt. Durch einen konsolidierten Blick auf die NIS-Daten stehen diese ja über das LDAP-Protokoll ebenfalls zur Verfügung. Mit dem Penrose-Server existiert seit einiger Zeit eine Open-Source-Lösung für ein virtuelles Directory. Ursprünglich entwickelte und vertrieb die Firma Identyx den Server. Durch die Übernahme durch Red Hat im Sommer 2008 existiert nun weiterhin eine OpenSource-Version (siehe „Onlinequellen“, [a]). Penrose besteht aus zwei Komponenten, dem eigentlichen Server, vd-server, und einem EclipseRCP-Client (Rich Client Platform), vdstudio, der per JMX-Schnittstelle (Java Management Extensions) mit dem Server kommunizieren kann. Mit dem Client steht ein GUI zur Verwaltung und Konfiguration von Penrose zur Verfügung. Server-Konfiguration im Detail Auf der Website des Projekts ([b]) finden sich fertige Installationspakete für Windows und Linux. Da Penrose jedoch komplett in Java geschrieben ist, kann eine Installation auf jedem System mit Java-Umgebung erfolgen. Es setzt ein aktuelles JDK ab Version 1.5 iX 3/2009 voraus. Auf einem Linux-System befindet sich das Server-Root nach erfolgreicher Installation unter /opt/vdserver-2.0/. Penrose bezeichnet jeden virtuellen Verzeichnisbaum als Partition. Die Default-Partion lässt sich über den Ordner conf/ einrichten. Sollten weitere Partitionen vorhanden sein, erfolgt deren Konfiguration im Ordner partitions/. Bei den Partitionen handelt es sich um Java-Objekte, die über den Aufruf bestimmter JavaKlassen die Eigenschaften des virtuellen Directory definieren. Sie legen beispielsweise fest, welche BackendSysteme existieren, wie diese zu erreichen sind und welches Mapping zwischen den Objekten des BackendSystems und des virtuellen Directory vorzunehmen ist. Da sämtliche Konfigurationsdateien im XML-Format vorliegen, lassen sie sich manuell editieren. Alternativ geschieht die Konfiguration mit dem RCP-Client vd-studio. Die Konfiguration aller notwendigen Adapter, mit denen der Server auf die Backend-Systeme zugreifen kann, erfolgt in der Datei server.xml. Außerdem ist hier neben dem Rechnernamen auch der Admin-Account für den Server festzulegen. Listing 1 zeigt einen Ausschnitt. An dieser Stelle noch ein Hinweis: Aus Platzgründen sind die gedruckten Listings teilweise stark gekürzt. Die vollständigen Listings gibt’s per FTP über den iX-Listing-Service [c]. Zwei weitere wichtige Dateien sind connections.xml und sources.xml. Erstere legt die Verbindungsinformationen zu den Backend-Systemen fest. Möchte man beispielsweise die Benutzerinformationen eines LDAP-Servers, eines Windows-AD und einer SQL-Datenbank konsolidieren, sind in <sources> <source name="dbusers"> <connection-name>rhel5-db</connection-name> <field name="username" primaryKey="true"/> <field name="firstName"/> <field name="lastName"/> <field name="password"/> <parameter> <param-name>table</param-name> <param-value>users</param-value> </parameter> </source> <source name="ldapusers"> <connection-name>rhel5-ds</connection-name> <field name="cn"/> <field name="sn"/> <field name="uid" primaryKey="true"/> <field name="userPassword"/> <parameter> <param-name>objectClasses</param-name> <param-value></param-value> </parameter> <parameter> <param-name>scope</param-name> <param-value>ONELEVEL</param-value> </parameter> <parameter> <param-name>baseDn</param-name> <param-value>ou=People,dc=virt,dc=tuxgeek,dc=de</param-value> </parameter> <parameter> <param-name>filter</param-name> <param-value>(objectClass=*)</param-value> </parameter> </source> <source name="adusers"> <connection-name>winad</connection-name> <field name="sAMAccountName" primaryKey="true"/> <field name="cn"> <field name="sn"/> <field name="unicodePwd"/> <field name="userAccountControl"/> <parameter> <param-name>baseDn</param-name> <param-value>cn=Users,dc=virt,dc=tuxgeek,dc=de</param-value> </parameter> <parameter> <param-name>scope</param-name> <param-value>ONELEVEL</param-value> </parameter> <parameter> <param-name>filter</param-name> <param-value>(objectClass=user)</param-value> </parameter> <parameter> <param-name>objectClasses</param-name> <param-value>user</param-value> </parameter> <parameter> <param-name>authentication</param-name> <param-value>full</param-value> </parameter> </source> </sources> connections.xml drei Verbindungen einzutragen. Als Adapter kann man logischerweise nur die zuvor in server. xml definierten verwenden (siehe Listing 2). In der Datei sources.xml (siehe Listing 3) befinden sich die gewünschten Applikationsdaten der Backend-Systeme. Mit diesen erzeugt man später den virtuellen Verzeichnisbaum. Der Parameter <connection-name> bestimmt, welche Verbindung aus der connections.xml Penrose zum Erreichen einer bestimmten Applikation benutzt. Des Weiteren bestimmen die sogenannten „Fields“ die Art der von einer Appli3 PRAXIS kation zu beziehenden Information. Je nach Anwendungstyp kann es sich bei diesen Feldern um Attribute eines LDAP-Baums, Spalten aus einer SQLTabelle oder NIS-Map handeln. Penrose baut später einen virtuellen Verzeichnisbaum aus Referenzen zu diesen Informationen auf. Dies erfolgt durch eine Art Cross-Referenzierung zwischen den Informationen der hier konfigurierten Felder und den dazu eingeblendeten Attributen des virtuellen Directory. Dabei bestimmen die über das virtuelle Directory bereitzustellenden Informationen, welche Felder der Administrator hier definieren muss. Möchte man beispielsweise das LDAPAttribut uid verwenden, ist es sinnvoll, es auf das SQL-Feld username abzubilden. Ein passendes Feld aus dem AD wäre samAccountName und bei einem LDAP-Server als Datenquelle benutzt man natürlich das vorhandene uid-Attribut. Konfigurationswerkzeug vd-studio Hiermit ist die grundlegende Konfiguration der Verbindungs- und Applikationsdaten abgeschlossen. Über das grafische Frontend vd-studio kann man nun schon durch die einzelnen Daten der Backend-Systeme browsen und sich die dort vorhandenen Benutzerinformationen anzeigen lassen. Das grafische Frontend befindet sich nach der Installation in /opt/vd-studio/. Nach dem initialen Start ist zuerst eine Verbindung zum Penrose-Server aufzubauen. Unter dem Ordner „Partition“ findet man anschließend die schon manuell vorgenommene Konfiguration wieder. Die Standard-Partition für den Server lautet DEFAULT. Unter den Ordnern „Connections“ sowie „Sources“ findet man die Verbin- Verzeichnisdienste dungs- und Applikationsdaten. Wie im Screenshot (Abb. 2) zu sehen, kann man über das Browser-Fenster auf der rechten Seite durch die Benutzerdaten der Applikationen navigieren. Natürlich kann die komplette Konfiguration auch per vd-studio erfolgen. Ein virtueller Directory-Baum Bisher hat man nichts anderes gemacht, als bestehende Applikationen mit Datenfeldern und den hierfür notwendigen Verbindungsinformationen zu definieren. Im nächsten Schritt gilt es, den eigentlichen virtuelle LDAPBaum aus diesen Informationen zusammenzusetzen. Je nachdem, was man genau machen möchte, sieht die hierfür notwendige Konfiguration anders aus. Das Beispiel in diesem Artikel erzeugt ein neues Directory mit dem RootDN dc=example,dc=com und zwei Containern, die die Benutzer-Informationen der jeweiligen Quelle in einem eigenen Sub-Container halten. Auf Wunsch lassen sich die Informationen in einem einzelnen Container zusammenfassen. Möchte man allerdings Benutzerinformationen mit gleichen Eigenschaften von verschiedenen Applikationen konsolidieren, sollte man nur Attribute verwenden, die mehrere Werte aufnehmen können. In conf/directory.xml erfolgt zuerst die Definition der RootDN. Dies geschieht durch das Setzen einer Konstanten und der passenden LDAP-Objektklasse. Anschließend lassen sich die beiden Sub-Container ou=Employees und ou=Customer, inklusive der Applikations-Container, ebenfalls durch das Setzen einer Konstanten und der Auswahl der passenden Objektklasse erzeugen. Welche Klasse man wählt, hängt von den Attributen ab, die das Über den vd-studio-Browser lässt sich bereits auf die konfigurierten Identify-Applikationen zugreifen (Abb. 2). 4 Listing 4: conf/directory.xml <directory> <entry dn="dc=example,dc=com"> <oc>dcObject</oc> <oc>top</oc> <at name="dc" rdn="true"> <constant>example</constant> </at> </entry> <entry dn="ou=Employees,dc=example,dc=com"> <oc>organizationalUnit</oc> <oc>top</oc> <at name="ou" rdn="true"> <constant>Employees</constant> </at> </entry> <entry dn="ou=ldap,ou=Employees,dc=example,dc=com"> <oc>organizationalUnit</oc> <oc>top</oc> <at name="ou" rdn="true"> <constant>ldap</constant> </at> </entry> <entry dn="ou=winad,ou=Employees,dc=example,dc=com"> <oc>organizationalUnit</oc> <oc>top</oc> <at name="ou" rdn="true"> <constant>winad</constant> </at> </entry> <entry dn="ou=Customer,dc=example,dc=com"> <oc>organizationalUnit</oc> <oc>top</oc> <at name="ou" rdn="true"> <constant>Customer</constant> </at> </entry> <entry dn="ou=sql,ou=Customer,dc=example,dc=com"> <oc>organizationalUnit</oc> <oc>top</oc> <at name="ou" rdn="true"> <constant>sql</constant> </at> </entry> </directory> virtuelle Directory anbieten soll. Unterhalb des Ordners schema/ befinden sich alle zur Verfügung stehenden Schemata. Im grafischen Frontend vdstudio erledigt man diese Arbeit durch das Anlegen eines statischen Directory-Eintrags unterhalb der DefaultPartition. In der entsprechenden Maske lässt sich dann die gewünschte Objektklasse für den Eintrag auswählen. Danach sollte directory.xml wie in Listing 4 aussehen. Im folgenden Schritt muss man ebenfalls in conf/directory.xml die Umsetzung zwischen den Informationen der Backend-Systeme und den Attributen des virtuellen Directory festlegen. Über vd-studio erzeugt man hierfür einen dynamischen DirectoryEintrag unterhalb des Containers, der die Benutzerinformationen eines Backend-Systems aufnehmen soll. Auch hier ist wieder darauf zu achten, die passende Objektklasse auszuwählen, damit man auf alle notwendigen Attribute für die neuen Objekte zurückgreifen kann. Jedes Attribut des virtuellen Directory lässt sich mit einer Information der Applikation eines BackendSystems verknüpfen. Wahlweise kann man einem Attribut auch wieder eine Konstante zuweisen oder ein BeanShell-Skript übergeben. Letztere Methode ist ganz interessant, möchte man vorhandene Informationen in einer bestimmten Art konvertieren oder den Inhalt vor einer Weiterverarbeitung überprüfen. Listing 5 stellt den SubContainer ou=winad,ou=Employees dar. Neben dem Mapping von AD-AtiX 3/2009 Listing 5: conf/direcory.xml Listing 6: Auszug der Ausgabe von ldapsearch <entry dn="uid=...,ou=winad,ou=Employees,dc=example,dc=com"> [...] <entry-class>org.safehaus.penrose.directory.DynamicEntry</entry-class> # swhite, sql, Customer, example.com <oc>inetOrgPerson</oc> dn: uid=swhite,ou=sql,ou=Customer,dc=example,dc=com <oc>organizationalPerson</oc> objectClass: inetOrgPerson <oc>person</oc> objectClass: organizationalPerson <oc>top</oc> objectClass: person <at name="cn"> <variable>adusers.cn</variable> </at> objectClass: top <at name="sn"> <variable>adusers.sn</variable> </at> cn: Scott White <at name="uid" rdn="true"> <variable>adusers.sAMAccountName</variable> </at> sn: White <at name="userPassword"> <variable>adusers.unicodePwd</variable> </at> uid: swhite <source alias="adusers"> userPassword:: a1doMXQyz <source-name>adusers</source-name> [...] <field name="cn"> <variable>cn</variable> </field> # foo, winad, Employees, example.com <field name="sn"> <variable>sn</variable> </field> dn: uid=foo,ou=winad,ou=Employees,dc=example,dc=com <field name="sAMAccountName"> <variable>uid</variable> </field> objectClass: inetOrgPerson <field name="unicodePwd"> objectClass: organizationalPerson Listing 7: conf/directory.xml <expression foreach="userPassword" var="p"> objectClass: person import org.safehaus.penrose.util.*; objectClass: top <entry dn="ou=winad,ou=Employees,dc=example,dc=com"> if (p == void || p == null) return null; cn: foo bar [...] return ActiveDirectoryUtil.toUnicodePassword(p); sn: bar <aci subject="self"> <permission>rws</permission> </aci> </expression> uid: foo <aci> </field> userPassword:: x8eoWBQyt <target>ATTRIBUTES</target> <field name="userAccountControl" operations="add"> [...] <attributes>userPassword</attributes> <constant>512</constant> <action>deny</action> </field> Listing 8: Änderungen der config.ldif <permission>rs</permission> </source> <scope>SUBTREE</scope> </aci> </entry> dn: cn=PKCS12,cn=Key Manager Providers,cn=config <aci> <permission>rs</permission> </aci> [...] </entry> ds-cfg-enabled: true ds-cfg-key-store-file: config/tmp/penrose.pk12 ds-cfg-key-store-pin-file: config/tmp/penrose.pin tributen wird hier jedem virtuellen Directory-Objekt ein userAccountControl-Attribut mit einer Konstanten „512“ zugewiesen. Ein BeanShell-Skript überprüft den Inhalt des unicodePwd-Attributs. Die Verknüpfung der Informationen aus einer SQL-Datenbank oder iX 3/2009 dn: cn=LDAPS Connection Handler,cn=Connection Handlers,cn=config [...] ds-cfg-enabled: true ds-cfg-listen-port: 10636 ds-cfg-allow-start-tls: false ds-cfg-use-ssl: true ds-cfg-ssl-cert-nickname: penrose-cert ds-cfg-key-manager-provider: cn=PKCS12,cn=Key Manager Providers,cn=config 5 Verzeichnisdienste PRAXIS Datenquellen LDAP dc=companyA, dc=com ou=People SQL-Datenbank Customer TABLE Benutzerinformationen aller drei Quellen stehen nun über den virtuellen Verzeichnisbaum zur Verfügung (Abb. 3). Active Directory dc=companyB, dc=com cn=Users virtueller Verzeichnisbaum LDAP dc=example, dc=com ou=Employees, ou=ldap ou=Employees, ou=winad ou=Customer, ou=sql einem anderen LDAP-Server sehen ganz ähnlich aus und lassen sich über den Menüpunkt „New Dynamic Entry“ aus vd-studio heraus erzeugen – wahlweise auch manuell über die Datei directory.xml. Hat man nun alle notwendigen Konfigurationen vorgenommen, steht, wie in Abbildung 3 zu sehen, ein neuer Directory-Baum dc=example,dc=com bereit. Alle Benutzerinformationen lassen sich nun per ldapsearch -x -h rhel5-rhvd.virt.tuxgeek.de -p 10389 -D uid=admin,ou=system -w secret -b dc=example,dc=com über die LDAPSchnittstelle abfragen. Listing 6 zeigt Teile der Ausgabe. Ausgefeilte Zugriffskontrolle möglich Mit den oben genannten ACIs lässt sich eine fein granulierte Zugriffskontrolle für beliebige Objekte und Attribute des Verzeichnisbaums einrichten. Dabei können untergeordnete Objekte die ACIs der höheren Ebene erben. Ein Eintrag zur Zugriffssteuerung besteht aus den folgenden Komponenten: Subjekt: Gibt an, für wen diese ACI gilt. Üblicherweise erfolgt die Darstellung des Subjekts über einen DN (Distinguished Name), es sind jedoch auch Einträge wie „anonymous“, „authenticated“, „anybody“, „self“ oder „user“ erlaubt. Target: Bestimmt das Objekt/Attribut, für das die Zugriffseinschränkung gelten soll. Beispielsweise könnte man einen Eintrag für das Attribut userPassword erzeugen. Scope: Legt fest, ob der ACI-Eintrag nach unten zu vererben ist. Gültige Werte sind „SUBTREE“ und „OBJECT“. Action: Legt die Zugriffserlaubnis fest. Mögliche Werte hier sind „deny“ oder „allow“. Berechtigung: Die eigentliche Zugriffsberechtigung. Hier stehen zur Auswahl: „Read“, „Search“, „Write“, „Add Children“ und „Delete“. Wie das Beispiel in Listing 7 zeigt, muss der ACI-Eintrag in conf/directory.xml im passenden Container erfolgen. Sicherer Zugriff auf die Daten Selbstverständlich lässt sich die LDAP-Schnittstelle von Penrose auch über TLS abfragen, sodass die Daten gesichert über die Leitung fließen. Dies erfordert zunächst ein X.509-Zertifikat im PKCS#12-Format. Auf einem Linux-System lässt sich zu Testzwecken per certutil einfach ein Onlinequellen [a] [b] [c] [d] Penrose Penrose-Server/Studio-Download iX -Listing-Service Penrose-Dokumentation penrose.safehaus.org docs.safehaus.org/display/PENROSE/Download ftp.heise.de/pub/ix/ix_listings/ docs.safehaus.org/display/PENROSE20/Documentation selbstsigniertes Zertifikat erzeugen und anschließend via pk12util exportieren. cd /opt/vd-server-2.0 mkdir tmp certutil -N -d . certutil -d . -S -s "cn=FQDN" -n penrose-cert -x -m 1000 -t P,, pk12util -d . -n penrose-cert -o penrose.pk12 Für die Benutzung eines CA-signierten Zertifikats erzeugt certutil auf Wunsch eine Zertifikats-Anfrage, die man an eine CA senden kann. In der Konfigurationsdatei des integrierten LDAP-Servers fehlt nun noch der Dateiname des PKCS#12-Zertifikats, im obigen Beispiel penrose.pk12. Zusätzlich ist in einer zweiten Datei das Passwort dafür zu hinterlegen. Als integrierten LDAP-Server verwendet Penrose den von Sun entwickelten OpenDS. Dessen Konfigurationsdatei befindet sich unter services/OpenDS/ config/. Die in Listing 8 gezeigten Einstellungen in config.ldif schließen die Konfiguration ab. Nach einem Neustart von Penrose lauscht der Server nun auch auf dem Port 10636 auf eingehende LDAPSAnfragen. Möchte man mit den OpenLDAP-Tools auf den Server zugreifen, muss man das CA- oder Server-Zertifikat nach /etc/openldap/cacerts/ kopieren. Anderenfalls können Clients das Penrose-Server-Zertifikat nicht verifizieren und ein LDAPS-Verbindungsaufbau scheitert. Fazit Penrose ist ein mächtiges Tool, das das Verwalten unterschiedlicher Identitätsquellen extrem vereinfacht. Dies ist gerade dann interessant, wenn eine Anwendung einen konsolidierten Blick auf die vorhandenen Nutzerdaten benötigt. Das grafische Frontend vd-studio ist in der aktuellen Version noch etwas fehleranfällig, aber dank einer umfangreichen Dokumentation [d] fällt das manuelle Bearbeiten der XMLbasierten Konfigurationsdateien nicht schwer. (avr) THORSTEN SCHERF arbeitet als Consultant und Trainer für Red Hat EMEA und ist auf den Bereich Security spezialisiert. iX-Link ix0903 6 x iX 3/2009
