39.11. Verwenden von LDAP und Kerberos

openSUSE-Dokumentation Kapitel 39. Installation und Administration von Kerberos / 39.11. Verwenden von LDAP und Kerberos
	39.10. Konfigurieren von SSH für die Kerberos-Authentifizierung		Kapitel 40. Verschlüsseln von Partitionen und Dateien

Wenn Sie Kerberos einsetzen, können Sie die Benutzerinformationen (wie Benutzer-ID, Gruppen und Home-Verzeichnis) in Ihrem lokalen Netzwerk mithilfe von LDAP verteilen. Dafür ist ein starker Authentifizierungsmechanismus erforderlich, der Paket-Spoofing und andere Angriffe verhindert. Eine Lösung ist die Nutzung von Kerberos für die LDAP-Kommunikation.

OpenLDAP implementiert die meisten Authentifizierungsarten über SASL, die einfache Authentifizierungs-Sitzungsschicht. SASL ist eigentlich ein Netzwerkprotokoll für die Authentifizierung. Die SASL-Installation ist cyrus-sasl, das eine Reihe verschiedener Authentifizierungsarten unterstützt. Die Kerberos-Authentifizierung wird mithilfe von GSSAPI durchgeführt (General Security Services API). Standardmäßig ist das SASL-Plugin für GSSAPI nicht installiert. Installieren Sie es manuell mit rpm -ivh cyrus-sasl-gssapi-*.rpm.

Wenn Sie Kerberos den Bind mit dem OpenLDAP-Server ermöglichen möchten, müssen Sie einen Prinzipal ldap/earth.example.com erstellen und der keytab-Datei hinzufügen.

Standardmäßig wird der LDAP-Server-slapd als Benutzer- und Gruppen-ldap ausgeführt, während die keytab-Datei nur von root gelesen werden kann. Sie können daher entweder die LDAP-Konfiguration ändern, damit der Server als root ausgeführt wird, oder die keytab-Datei für die Gruppe ldap lesbar machen. Letzteres wird automatisch vom OpenLDAP-Startskript (/etc/init.d/ldap) ausgeführt, wenn die keytab-Datei in der Variable OPENLDAP_KRB5_KEYTAB in /etc/sysconfig/openldap angegeben wurde und wenn die Variable OPENLDAP_CHOWN_DIRS auf yes eingestellt ist (die Standardeinstellung). Wenn OPENLDAP_KRB5_KEYTAB leer gelassen wird, wird die standardmäßige keytab-Datei unter /etc/krb5.keytab verwendet und Sie müssen die Berechtigungen, wie im Folgenden beschrieben, selbst anpassen.

Wenn Sie slapd als root ausführen möchten, bearbeiten Sie /etc/sysconfig/openldap. Deaktivieren Sie die Variablen OPENLDAP_USER und OPENLDAP_GROUP, indem Sie ein Kommentarzeichen davor setzen.

Um die keytab-Datei für die Gruppe LDAP lesbar zu machen, führen Sie Folgendes aus:

chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab

Eine dritte und vielleicht die beste Lösung ist es, wenn Sie OpenLDAP anweisen, eine spezielle keytab-Datei zu verwenden. Dafür starten Sie kadmin und geben Sie den folgenden Befehl ein, nachdem Sie den Prinzipal ldap/earth.example.com hinzugefügt haben:

ktadd -k /etc/openldap/ldap.keytab ldap/earth.example.com@EXAMPLE.COM

Auf der Shell führen Sie dann Folgendes aus:

chown ldap.ldap /etc/openldap/ldap.keytab 
chmod 600 /etc/openldap/ldap.keytab

Wenn Sie OpenLDAP anweisen möchten, eine andere keytab-Datei zu verwenden, ändern Sie die folgende Variable in /etc/sysconfig/openldap:

OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"

Starten Sie schließlich den LDAP-Server mit rcldaprestart neu.

39.11.1. Verwenden der Kerberos-Authentifizierung mit LDAP

Jetzt sollten Sie Werkzeuge, wie ldapsearch, mit der Kerberos-Authentifizierung automatisch verwenden können.

ldapsearch -b ou=people,dc=example,dc=com '(uid=newbie)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# newbie, people, example.com
dn: uid=newbie,ou=people,dc=example,dc=com
uid: newbie
cn: Olaf Kirch
[...]

Wie Sie sehen, gibt ldapsearch eine Meldung aus, dass die GSSAPI-Authentifizierung gestartet wurde. Die nächste Meldung ist sehr unverständlich, aber sie zeigt, dass der Security Strength Factor (SSF) 56 beträgt. (Der Wert 56 ist etwas willkürlich. Wahrscheinlich wurde er gewählt, weil diese Anzahl an Bits in einem DES-Verschlüsselungsschlüssel enthalten ist.) Das bedeutet, dass die GSSAPI-Authentifizierung erfolgreich war und dass der Datenschutz und die Vertraulichkeit der LDAP-Verbindung mittels Verschlüsselung gewährleistet ist.

In Kerberos ist die Authentifizierung immer gegenseitig. Das bedeutet, dass Sie sich nicht nur selbst beim LDAP-Server authentifiziert haben, sondern dass sich der LDAP-Server auch bei Ihnen selbst authentifiziert hat. Nun wissen Sie, dass die Kommunikation wirklich mit dem gewünschten LDAP-Server stattfindet und nicht mit einem falschen Dienst, den ein Hacker eingerichtet hat.

39.11.2. Kerberos-Authentifizierung und LDAP-Zugriffskontrolle

Jetzt können Sie jedem Benutzer erlauben, das Anmelde-Shell-Attribut seines LDAP-Benutzerdatensatzes zu ändern. Angenommen Sie haben ein Schema, bei dem der LDAP-Eintrag des Benutzers joe sich unter uid=joe,ou=people,dc=example,dc=com befindet, richten Sie die folgende Zugriffskontrolle in /etc/openldap/slapd.conf ein:

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
       by self write
# Every user can read everything
access to *
       by users read

Die zweite Anweisung gewährt authentifizierten Benutzern Schreibzugriff auf das loginShell-Attribut des eigenen LDAP-Eintrags. Die dritte Anweisung gibt allen authentifizierten Benutzern Lesezugriff auf das gesamte LDAP-Verzeichnis.

Es fehlt jedoch ein Puzzle-Teil. Wie findet der LDAP-Server heraus, dass der Kerberos-Benutzer joe@EXAMPLE.COM dem LDAP-DN uid=joe,ou=people,dc=example,dc=com entspricht? Diese Art der Zuweisung muss manuell konfiguriert werden mit der saslExpr-Direktive. In diesem Beispiel fügen Sie Folgendes der Datei slapd.conf hinzu:

authz-regexp
   uid=(.*),cn=GSSAPI,cn=auth 
   uid=$1,ou=people,dc=example,dc=com

Um die Funktionsweise zu verstehen, müssen Sie zunächst wissen, dass OpenLDAP bei der Benutzerauthentifizierung über SASL einen DN aus dem von SASL angegebenen Namen (z. B. joe) und dem Namen der SASL-Funktion (GSSAPI) erstellt. Das Ergebnis lautet: uid=joe,cn=GSSAPI,cn=auth.

Wenn ein authz-regexp konfiguriert wurde, überprüft er den DN der SASL-Informationen und nimmt dabei das erste Argument als regulären Ausdruck. Wenn dieser reguläre Ausdruck passt, wird der Name durch das zweite Argument der authz-regexp-Anweisung ersetzt. Der Platzhalter $1 wird durch den Substring ersetzt, der dem (.*)-Ausdruck entspricht.

Es sind auch kompliziertere Entsprechungsausdrücke möglich. Wenn Sie über eine kompliziertere Verzeichnisstruktur oder ein Schema verfügen, in dem der Benutzername kein Teil des DNs ist, können Sie sogar Suchausdrücke verwenden, um den SASL-DN dem Benutzer-DN zuzuweisen.