Wheezy LDAP-Server mit TLS | su zu LDAP-User nicht möglich

[cc_aero]

Hallo allerseits ,

ich habe unter Debian Wheezy (7.1) einen OpenLDAP-Server eingerichtet, welchen ich für Benutzer-Anmeldungen (und wenn da alles klappt) auch als Samba-Backend benutzen möchte. LDAP soll zu dem auch über TLS funktionieren (allerdings nur "start_tls" über den normalen LDAP-Port 389).
Zu dem sollen auf der Maschine, auf welcher der LDAP-Server läuft, Benutzeranmeldungen via LDAP möglich sein ... ebenfalls mit TLS gesichert.
Außerdem soll das LDAP-Verzeichnis nicht für Anonyme Benutzer einsehbar sein.

Soweit, so gut - Der LDAP-Server läuft (inkl. konfigurierten TLS) und Anmeldungen von LDAP-Benutzern am System ist ebenfalls möglich. Die LDAP Benutzer können auch über "passwd" ihr LDAP-Password ändern.
"getent passwd" und "getent group" liefern auch brav lokale Benutzer/Gruppen sowie LDAP-Einträge.

Was jedoch nicht funktioniert - und ich komm einfach nicht dahinter warum - ist das wechseln von einem lokalen Benutzer zu einem LDAP-Benutzer oder von einem LDAP-Benutzer zu einem anderen LDAP-Benutzer - beides mit "su $user".

Folgende Fehlermeldungen erscheinen beim wechseln von einem lokalen User zu einem LDAP-User:

Der Lokale Benutzer ist "srv-admin" und der LDAP-Benutzer "testusr3"

Auf der Konsole:

srv-admin@mastertux:~$ su testusr3
Password:
setgid: Die Operation ist nicht erlaubt

In /var/log/auth.log:

Sep 18 11:56:57 mastertux su[5209]: Successful su for testusr3 by srv-admin
Sep 18 11:56:57 mastertux su[5209]: + /dev/pts/1 srv-admin:testusr3
Sep 18 11:56:57 mastertux su[5209]: bad group ID `16985' for user `testusr3': Operation not permitted

Folgende Fehlermeldungen erscheinen beim wechseln von einem LDAP-User zu einem anderen LDAP-User:

Auf der Konsole:

testusr2@mastertux:~$ su testusr3
Password:
initgroups: Die Operation ist nicht erlaubt

In /var/log/auth.log:

Sep 18 12:01:40 mastertux su[5223]: Successful su for testusr3 by testusr2
Sep 18 12:01:40 mastertux su[5223]: + /dev/pts/1 testusr2:testusr3
Sep 18 12:01:40 mastertux su[5223]: initgroups failed for user `testusr3': Operation not permitted

Die LDAP-Benutzer haben übrigens als primäre Gruppe eine LDAP-Gruppe (LDAP_Users) eingetragen, ansonsten besitzen sie keine Gruppenmitgliedschaften.

Das Interessante ist ... wenn ich folgende Einträge zu TLS aus den Config-Dateien "libnss-ldap.conf" und "pam_ldap.conf" herausnehme funktioniert die Sache ohne Probleme:

ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

Daher dürfte es ein Problem mit TLS sein - nur welches? Das normale anmelden funktioniert doch problemlos. Auch das Anmelden an den Verzeichnis-Dienst per LDAP-Admin von einer Windows-Maschine via TLS funktioniert reibungslos.

Auch der Befehl "ldapsearch -xLLL -ZZ -W -D cn=admin,cn=config" bringt ohne Fehler Ergebnisse

Alle LDAP-Benutzer können zudem Problem auf einen lokalen-Benutzer via "su" wechseln. Root kann problemlos auf Lokale und LDAP-Benutzer via "su" wechseln.

Was jedoch noch auffällig ist ... sobald "nscd" gestoppt wird, kann kein Benutzer - außer root - "su" einsetzen. Ein lokaler Benutzer kann auch nicht mehr mit "su" zum root-Account wechseln. - Erst wenn "nscd" wieder gestartet ist, funktioniert "su" wieder.


Detail-Informationen zu meiner Konfiguration:

TLS für den OpenLDAP-Server hab ich nach einen How-To von Ubuntu konfiguriert - http://wiki.ubuntuusers.de/OpenLDAP#Sichere-bertragung-mit-TLS-SSL
Ich hab hierzu mittels CA.pl - wie im Howto beschrieben - eine eigene CA eingerichtet und darüber das Server-Zertifikat erstellt.
Außerdem habe ich zusätzlich das Paket "ssl-cert" via apt installiert und den Benutzer "openldap" zur Gruppe "ssl-cert" hinzugefügt da der SLAPD ansonsten nicht startet - siehe https://wiki.debian.org/LDAP/OpenLDAPSetup#Configuring_LDAPS

Meine config in cn=config des SLAPD zu TLS sieht wie folgt aus:

olcTLSCACertificateFile: /etc/ssl/certs/ldap_slapd_cacert.pem
olcTLSCertificateFile: /etc/ssl/certs/ldap_slapd_cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_slapd_key.pem

/etc/ldap/ldap.conf:

BASE    dc=sascha-bauer,dc=net
URI     ldap://mastertux.sascha-bauer.net
ldap_version 3

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
ssl start_tls
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

libnss-ldap und pam_ldap hab ich über apt installiert und mittels dpgkconfigure konfiguriert.
Die Config-Dateien "libnss-ldap.conf" und "pam_ldap.conf" habe ich um die TLS-Parameter ergänzt, welche ich weiter oben bereits notiert habe und zusätzlich in beiden Dateien die Optionen "binddn" und "bindpw" gesetzt, da auf meinem LDAP-Verzeichnis kein anonymer Zugriff möglich sein soll:

binddn cn=usr_ldapread,ou=service,dc=sascha-bauer,dc=net
bindpw XXXXXXX

Die Config-Datei "/etc/pam.d/common-auth" sowie "/etc/pam.d/common-password" habe ich auch etwas angepasst, da im SYSLOG immer Warnings/Fehler auftauchen (von pam_unix) wenn sich ein LDAP-User anmeldet.

/etc/pam.d/common-auth:

auth    [success=1 default=ignore]      pam_succeed_if.so quiet uid > 4999 debug
auth    [success=2 auth_err=1 default=ignore]   pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

/etc/pam.d/common-password:

password        [success=1 default=ignore]      pam_succeed_if.so quiet uid > 4999
password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 user_unknown=ignore default=die]     pam_ldap.so try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

In common-session habe ich zu dem am Ende noch "session required pam_mkhomedir.so" angefügt, damit Home-Dirs automatisch erstellt werden.

Und zu guter letzt noch die /etc/nsswitch.conf:

passwd:         files ldap
group:          files ldap
shadow:         files ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Kennt das beschriebene Problem bereits jemand und hat eine Lösung parat? Wo kann hier der Fehler liegen?
Muss ich davon ausgehen das diese Problem evtl. auch anders Dinge beeinflussen kann, welche ich an LDAP binden möchte (SAMBA zb) oder bleibt es nur beim "su"-Problem?

Für eine Lösung wäre ich sehr dankbar

PS: Hoffentlich ist das der richtige Forums-Bereich

 

[lodex]

Edit: Hier stand Mist.

Wie sehen libnss-ldap.conf und pam-ldap.conf aus?

 

[cc_aero]

Ich habe die beiden Dateien als ZIP-File angehängt.

Im Prinzip beinhalten sie die Standard-Konfiguration, welche durch dpkg-configure eingestellt wurde. Ich habe die Dateien um folgende Parameter erweitert:

ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
binddn cn=usr_ldapread,ou=service,dc=sascha-bauer,dc=net
bindpw XXXXXXX

 

[lodex]

Das Einzige was mir spontan aufgefallen ist, ist dieser Eintrag hier in beiden Dateien:

uri ldap://mastertux.sascha-bauer.net:389/

Da ist der Port doppelt angegeben. Einmal mit "ldap://" am Anfang und mit ":389" am Ende. Den Teil am Ende kannst du weg lassen.

Es ist schon etwas länger her, dass ich solche Dienst unter Debian konfiguriert habe, unter RedHat seit Version 6 passiert es aber mal gerne, dass andere Dienste dazwischen funken, die Aufgaben von NSS und PAM übernehmen möchten. Ganz unabhängig von deinem Problem solltest du darauf achten, dass die Dienste "nslcd" und "sssd" auf dem System nicht laufen, am besten erst garnicht installiert sind. Die kommen sich gerne mit "nscd" und "pam-ldap" in die Quere.

 

[cc_aero]

Hab mal versucht den Port wegzulassen (dürfte dpkg-configure so eingestellt haben) das Ergebnis bleibt jedoch das gleiche. Ich habe statt mit start_tls auch einmal mit "ssl on" - also Verbindung direkt über SSL-Port 636 - versucht. Ändert auch nichts am Ergebnis.

nslcd und sssd habe ich auf dem System gar nicht installiert (nach dem Motto "weniger ist mehr" ).

Wenn der Fehler nur bei "su" bleibt, könnte ich damit leben. Hauptsache "root" kann auf alle Benutzer wechseln bzw. alle Benutzer auf "root".
Nur bin ich mir nicht sicher ob dieser Fehler evtl. Auswirkung auf andere Dienste hat.

 

[lodex]

Deiner Beschreibung nach beschränkt sich das Problem auf das Authentifizierungsmodul PAM. Das kommt nämlich bei einem "su" von root auf einen anderen Benutzer nicht zum Einsatz, denn in diesem Fall wird kein Passwort verlangt.
Das heißt also du wirst immer dann ein Problem haben, wenn ein Dienst versucht einen Benutzer aus dem LDAP zu authentifizieren und dazu PAM benutzt.
Dienste wie Samba beispielsweise können sich selbst an den LDAP verbinden, sind also dazu nicht unbedingt darauf angewiesen.
Ich würde dir aber dennoch wärmstens empfehlen, entweder weiter auf Fehlersuche zu bleiben und das Problem zu lösen, oder gänzlich auf PAM in Verbindung mit LDAP zu verzichten. Bei solchen Zwischenlösungen wirst du immer ein mulmiges Gefühl behalten, sollte irgendetwas nicht funktionieren.

 

[cc_aero]

Genau dieses mulmige Gefühl hab/hatte ich bereits - ich bin dabei die Maschine von Grund an Neu Aufzubauen - daher mach ich mit den Konfigurationen von neuen Diensten erst weiter, wenn bereits installierte Dienste völlig ohne Probleme funktionieren.

Glücklicherweiße habe ich das Problem nun gefunden.
Das Problem findet sich nicht in der Konfiguration, sondern in Debian selbst bzw. in "libldap" ... hier ist scheinbar seit Squeeze ein Bug vorhanden, der jedoch in Wheezy offiziel noch nicht geschlossen wurde.
Siehe http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658739
Betroffen ist eben su/sudo und auch passwd.

Im Bug-Report findet sich auch ein Link zu einem kleinen Patch, welcher in wheezy das Problem behebt:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658896#104

root ~ # wget http://ftp.neutrino.es/debian/OpenLDAP/libldap-2.4-2_2.4.31-1.1_amd64.deb
root ~ # dpkg -i libldap-2.4-2_2.4.31-1.1_amd64.deb

Nun funktioniert (vorerst) alles wie es soll

 

[lodex]

Perfekt. Dann viel Spaß damit