Interop 3: Linux Benutzer per LDAP an AD authentifizieren

In dieser Serie von Blogeinträgen möchte ich Schritt für Schritt erklären, wie man die Vorteile des AD auch für Linux nutzen kann. Ich hab mir gedacht, ist ein bisschen viel für einen Artikel, daher werde ich das jetzt abschnittweise vorstellen.

Nachdem ich im ersten Teil erklärt habe, welche Voraussetzungen erfüllt sein müssen, um LDAP-Abfragen ans AD zu senden, und wir im zweiten Teil den Nameservice von Linux so konfiguriert haben, dass es Benutzerinfos nicht nur aus seiner lokalen /etc/passwd holt, sondern auch aus dem AD, geht es in diesem dritten Teil darum, diese LDAP-Fähigkeit zum Login zu nutzen.

Eigentlich ist LDAP nicht zum Authentifizieren da. Aber man kann es „missbrauchen“, indem man einen Benutzer sich anmelden lässt, seinen Benutzernamen und sein Passwort nimmt und damit versucht, sich an einem LDAP-Server anzumelden (man nennt das übrigens ein „bind“). Klappt die Anmeldung am LDAP-Server, dann war die Kombination Name und Passwort offensichtlich richtig, und es wird auch der lokale Zugang gestattet.

Wie geht das nun? Aktuelle Linux-Versionen bringen einen recht praktischen Mechanismus mit, der nennt sich PAM (pluggable authentication modules). Kurz gesagt kann man für Login etc. eine beliebige Reihenfolge von Bedingungen definieren, die für ein erfolgreiches Login erfüllt sein müssen. Wir nutzen dies, indem wir zusätzlich zum geforderten Standard-Unix-Login mit lokalem Passwort vorher eine LDAP-Authentifizierung versuchen, und das als ausreichend definieren. Die PAM-Syntax variiert leider etwas von System zu System, daher hier nur eine allgemeine Beschreibung, wie es unter Debian/Ubuntu aussieht:

In /etc/pam.d/ liegen für verschiedene Login-Arten (per ssh, per Login, etc) je eine Konfig-Datei, deren Einträge in der aufgeführten Reihenfolge abgearbeitet werden. Da viele Bedingungen für einen Großteil der Login-Varianten identisch sind, wird meist noch eine globale Datei eingelesen (include). Auf meinem System sieht das z. B. so aus:

auth required pam_env.so
auth include common-auth

und in der common-auth steht dann noch:

auth required pam_unix.so try_first_pass

Das liest sich dann in Prosa wie folgt: Es muss (required) die pam_env-Bedingung erfüllt sein, d. h. Environment-Variablen werden gesetzt. Nach einer nicht erfüllten „required“-Bedingung wird nicht weitergemacht. Falls alles erfüllt ist, dann mach weiter, lies die common-auth Datei ein. Dort steht, es soll eine Unix-Authentifizierung (gegen die lokale Passwort-Datei) versucht werden. Das muss klappen (required), sonst gibt’s kein Login. Wir fügen jetzt an geeigneter Stelle noch eine Zeile ein:

auth sufficient pam_ldap.so

Das sufficient sorgt dafür, dass es bei Misserfolg noch weitergeht, bei Erfolg aber hier aufgehört wird (sufficient=ausreichend), wir wollen uns doch noch als root anmelden können, wenn kein LDAP geht, oder? Und an welcher Stelle soll das rein? Am besten nicht gleich in die system-Config, sondern noch in die Login-spezifische Config, z. B. für login. Und in der Gesamtheit vor das letzte required. Warum davor? Wer das jetzt nicht beantworten kann, der sollte besser nicht abspeichern!

Ein wichtiger Tipp aus eigener Erfahrung :-): Während der ganzen Versuche mit den PAM-Dateien immer eine Shell mit eingeloggtem Root-Benutzer offen lassen. Warum? Na, wenn man die Konfig verhaut, dann geht evtl. gar kein Login mehr – also auch wenig Chancen auf Heilung. Daher immer eine Kopie der Original-PAM-Datei machen und im Notfall in der offenen Shell zurückkopieren. You have been warned!!!

So, eigentlich sollte jetzt das Login an einer anderen Konsole funktionieren. Wer das über SSH versuchen möchte (putty ist übrigens ein prima SSH-Client für Windows), der muss natürlich die /etc/pam.d/sshd PAM-Konfig bearbeiten. Wenn’s nicht klappt, dann mal

getent passwd benutzername

versuchen, das muss UID und GID zurückliefern!

Die pam_ldap.so schickt Benutzername und Passwort an den LDAP-Server, aber an welchen denn? Wenn das so einfach zu beantworten wäre. Manche Versionen bzw. Distributionen verwenden einfach die libnss-ldap.conf mit (siehe Interop2), andere verwenden eine eigene, zum Beispiel ldap.conf. Wieder andere nutzen einfach einen symlink auf eine der beiden Dateien. Einfach mal schauen. Und dann gibt es auch noch einen weiteren Haken an der Geschichte: Das Passwort geht im Klartext über das Netzwerk. Mit einem Netzwerk-Sniffer ist das einfach auszulesen. Abhilfe kann man hier durch Einsatz von SSL erreichen, dann muss man vorher Zertifikate installieren und den LDAPS-Port (636 statt 389) verwenden. Hat man zwei verschiedene Konfigurationsdateien, eine für NSS und eine für PAM, dann kann man auch bei NSS auf ein LDAPS verzichten (es geht ja kein Benutzerpasswort über das Netz bis auf den Bind-User, falls verwendet). Bei PAM mit LDAP kommt man an einer Verschlüsselung nicht vorbei.

Eine andere Möglichkeit besteht darin, die Namensinformationen und die Authentifizierung auf eine andere Art voneinander zu trennen, einmal LDAP(S) und einmal Kerberos. Das klingt zwar kompliziert, isses aber gar nicht so sehr. Den halben Weg haben wir schon zurückgelegt, und für den Rest gibt es ein weiteres Kapitel hier.

Advertisements

Über Ralf Wigand

...arbeitet für Microsoft und war von 2008-2015 MVP für Directory Services.
Dieser Beitrag wurde unter Active Directory, LDAP, Linux veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s