Zu Testzwecken können Sie sich mittels "openssl" schnell ein eigenes Zertifikat erstellen und dieses durch eine vorhandene CA signieren lassen. Das Beispiel in Listing 1 erzeugt sowohl den privaten Schlüssel als auch eine entsprechende Zertifikatsanfrage (CSR).
Die Datei mit der Zertifikatsanfrage »(tscherf.csr
«
) senden Sie dann an eine Zertifizierungsstelle, um ein signiertes Zertifikat zurückzuerhalten. In einer Testumgebung können Sie natürlich auch die interne OpenSSL CA verwenden (Listing 2).
Listing 2: Zertifikatsanfrage durch die OpenSSL CA signieren
# openssl ca -in tscherf.csr -out tscherf.crt Using configuration from /etc/pki/tls/openssl.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 2 (0x2) Validity Not Before: Aug 7 18:01:51 2014 GMT Not After : Aug 7 18:01:51 2015 GMT Subject: countryName = DE stateOrProvinceName = NRW organizationName = RedHat organizationalUnitName = GSS commonName = Thorsten Scherf emailAddress = tscherf@redhat.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 6D:01:FB:C8:65:07:E8:0C:5D:16:10:C0:5A:12:48:96:F7:94:EF:8A X509v3 Authority Key Identifier: keyid:E7:2D:ED:E9:BE:A2:F8:BE:ED:24:AB:4F:FB:65:E4:7B:2D:13:C6:A3 Certificate is to be certified until Aug 7 18:01:51 2015 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
Um mit den OpenLDAP Client-Tools nun auf den Server zugreifen zu können, legen Sie eine LDAPRC-Datei in Ihrem Home-Verzeichnis an. In der Datei definieren Sie nun "EXTERNAL" als Authentifzierungsmethode und verweisen auf den Speicherort Ihres Zertifikats:
# cat .ldaprc
SASL_MECH EXTERNAL
TLS_CERT /etc/openldap/certs/tscherf.crt
TLS_KEY /etc/openldap/certs/private/tscherf.key
Damit der Server nun auch das Zertifikat des Benutzers anfordert und dieses auf einen LDAP-Benutzer mappen kann, sind einige Einstellungen in der Datei »slapd.conf
«
notwendig. Mittels "VerifyClient demand" fordert der Server ein Benutzer-Zertifikat an und bricht im Fehlerfall die Verbindung ab. Um nun ein Mapping zwischen dem Zertifikat und einem LDAP-Benutzer herzustellen, gibt es mehrere Möglichkeiten. Der einfachste Weg ist ein statisches Mapping zwischen einer eindeutigen Kennung des Zertifikats (beispielsweise der E-Mail) und dem LDAP Distinguished Name (dn):
authz-regexp
"email=tscherf@redhat.com, cn=thorsten scherf,ou=gss, o=redhat,st=nrw,c=de"
"uid=tscherf,ou=people,dc=redhat, dc=com"
Natürlich lässt sich dieser Ausdruck auch dynamisieren, indem Sie beispielsweise den Benutzernamen in der E-Mail-Adresse innerhalb eines Klammernblocks als regulären Ausdruck darstellen und dann im LDAP dn mittels des Platzhalters "$1" die "uid" bestimmen. In der OpenLDAP-Dokumentation sind zahlreiche Beispiele hierzu zu finden.
Im Anschluss sollte nun eine Verbindung zum Server mit der Anweisung "ldapsearch -ZZ" ohne weiteres funktionieren. Der folgende Mitschnitt zeigt den Header der Verbindung an:
# ldapsearch -ZZ
SASL/EXTERNAL authentication started
SASL username: email=tscherf@redhat.com,cn=thorsten scherf,ou=gss,o=redhat,st=nrw,c=de
SASL SSF: 0
[...]
Schließlich können Sie nun jede gewünschte Anwendung für eine zertifikatsbasierte Authentifizierung am LDAP-Server konfigurieren. Hierfür ist lediglich "EXTERNAL" als Authentifizierungs-Mechanismus und der Pfad zum eigenen Zertifikat anzugeben.
(jp)