Hallo Liste,
bei der Einrichtung des neuen Server mit Lenny tauchen wieder mal die Konfigurationsprobleme auf. Dasselbe hatte ich auch bei dem letzten Server unter etch schon mal, aber irgendwie dann gelöst. Allerdings will ich mich a) mit der "blackbox" nicht zufrieden geben und verstehen wie das abläuft und b) die Neuerungen in Lenny (nss-ldapd) nutzen. Laut http://wiki.debian.org/LDAP/NSS soll nss-ldapd neuer und einfacher sein, es spricht also nichts dagegen. ;)
Ziel ist es, die komplette Benutzerverwaltung in LDAP zu erledigen, wobei sich die Mail-Benutzer von den Logins via ssh/ftp unterscheiden. Postfix/Cyrus/Sasl läuft schon wieder (nachdem mich einige dovecot-Einstellungen fast zur Verzweiflung getrieben haben) Die LDAP-Daten liegen unter ou=mail,$base als inetOrgPerson und beeinflussen damit die User-Logins nicht. PAM scheint mir für die User-Logins sinnvoll, wobei ich nicht unbedingt daran festhalte. Das funktionierte unter etch alles schon, allerdings hab ich nicht ganz verstanden wie und warum.
Alle LDAP-Daten wurden in den neuen Server importiert.
Da es scheinbar mehrere Wege zum Ziel gibt, möchte ich verstehen, welche Wege es gibt und welcher Weg empfohlen werden kann.
Wofür und in welcher Reihenfolge sind PAM und NSS im Spiel? Was ist der Unterschied zwischen libnss-ldap und libnss-ldapd? files vs. compat?
Die Lenny-Konfiguration ($base ist in den Dateien natürlich korrekter Wert): /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap ...
/etc/nss-ldapd.conf: uid nslcd gid nslcd uri ldap://127.0.0.1/ base $base
/etc/pam_ldap.conf: host localhost base $base ldap_version 3 rootbinddn cn=admin,$base pam_filter objectclass=posixAccount
zugehöriges Passwort in /etc/pam_ldap.secret
keine LDAP-spezifischen Einträge in /etc/pam.d/*
LDAP-Sruktur:
User in ou=people,$base objectClass: account, posixAccount, (teilweise top) uid(rdn), uidNumber, gidNumber, userPassword, loginShell, homeDirectory, cn, gecos, description
Groups in ou=group,$base objectClass: posixGroup, top cn(rdn), gidNumber, (teilweise memberUid)
An der Lenny-Debian-Konfiguration von PAM und NSS-LDAP habe ich erstmal nichts geändert. In /etc/pam.d/* sind außer einem zusätzlichen 'min=4 max=8' in common-password in Etch keine Unterschiede. Da diese Einschränkung in Lenny nicht enthalten ist, ist das aber irrelevant. Im Gegensatz zu Etch ist bei Lenny allerdings der nss-ldapd im Einsatz.
Die Unterschiede in etch: in /etc/nsswitch.conf wird files statt compat verwendet /etc/group und /etc/passwd haben eine '+'-Zeile am Ende
Auch eine dahingehende Änderung in Lenny bewirkt keine Aänderung.
Der nscd wurde vorsorglich zur Fehlersuche gestoppt und slapd+nslcd nach Änderungen jeweils neu gestartet, um Seiteneffekte auszuschließen.
Es funktioniert bereits soweit, daß 'getent passwd' und 'getent group' mir die Daten aus /etc/passwd bzw. /etc/gr LDAP anzeigen. Ein Login per ssh mit Keyfile funktioniert auch. Lediglich die Anmeldung ohne Keyfile , nur mit einem Passwort funktioniert nicht, ebensowenig ein 'su'. ls -l zeigt User und Gruppennamen korrekt an.
Grundsätzlich beschwert sich der sshd in /var/log/auth.log über ein fehlendes /etc/default/locale: Nov 4 14:06:55 lenny sshd[23539]: Accepted publickey for test1 from 84.179.yyy.zzz port 2718 ssh2 Nov 4 14:06:55 lenny sshd[23539]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Nov 4 14:06:55 lenny sshd[23539]: pam_unix(sshd:session): session opened for user test1 by (uid=0) Nov 4 14:06:55 lenny sshd[23543]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Hier verwundert mich nur das 'by (uid=0)', der User hat 'uid=1001'. Nachgeschaut, auch bei Etch: /etc/pam.d/ssh auth required pam_env.so envfile=/etc/default/locale
Warum heißt die Datei bei Etch 'ssh' und bei Lenny 'sshd'? *grübel*
SSH ohne Key: auth.log: Nov 5 08:29:43 lenny sshd[28580]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxxxx.dip0.t-ipconnect.de user=test1 Nov 5 08:29:45 lenny sshd[28580]: Failed password for test1 from 84.179.yyy.zzz port 1208 ssh2
syslog: Nov 5 08:29:39 lenny slapd[8889]: <= bdb_equality_candidates: (uid) not indexed Nov 5 08:29:43 lenny slapd[8889]: <= bdb_equality_candidates: (uid) not indexed
slapd beschwert(e) sich über einen fehlenden Index. Es kommen also auch Anfragen beim LDAP-Server an.
Fehlende Indizes wurden inzwischen angelegt : index objectClass eq,pres index uidNumber,gidNumber,memberUid eq,pres index uid eq,pres
Danach verschlechterte sich die Situation allerdings:
getent geht noch, ls -l zeigt jedoch nur noch die ids und ein Login per ssh wird schon beim Usernamen ausgebremst: Nov 5 10:43:44 lenny sshd[29248]: Invalid user test1 from 84.179.156.17 Nov 5 10:43:44 lenny sshd[29248]: Failed none for invalid user test1 from 84.179.yyy.zzz port 2089 ssh2
Nov 5 10:43:52 lenny sshd[29248]: pam_unix(sshd:auth): check pass; user unknown Nov 5 10:43:52 lenny sshd[29248]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxxxx.t-ipconnect.de Nov 5 10:43:53 lenny sshd[29248]: Failed password for invalid user test1 from 84.179.yyy.zzz port 2089 ssh2
nachdem die Indizes wieder reduziert wurden auf: index objectClass eq funktioniert es wieder mit keyfile.
Vorsichtig hinzugefügt: index uid eq und nichts geht mehr.
Wie kann es sein, daß ein Index die Funktion beeinträchtigt, wo doch die Abfrage ohne Index nur etwas länger benötigen sollte? -> nslcd -d -> Abfragen mit ldapsearch validiert: "(&(objectClass=posixAccount)(uid=test1))" -> der index auf uid stört tatsächlich Also erstmal wieder raus.
Ohne den Index kommen noch Abfragen nach posixGroup und uidNumber (beide korrekt), aber keine Abfrage nach dem Passwort.
http://wiki.debian.org/LDAP/NSS (ldapd) http://wiki.debian.org/LDAP/PAM (pam_ldap) sind abgearbeitet
Letzte Erkenntnis: ldapsearch -h 127.0.0.1 -D uid=test1,ou=people,dc=domain,dc=de -W Enter LDAP Password: SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49)
Wieso mischt SASL hier wieder mit? Das Password wurde wahlweise als clear, crypt, md5crypt, md5 oder smd5 gespeichert - alles erfolglos.
Ich bin momentan ratlos, an welcher Stelle ich nach dem Fehler suchen soll.
Gruß Rico
Vorsichtig hinzugefügt: index uid eq und nichts geht mehr.
Wie kann es sein, daß ein Index die Funktion beeinträchtigt, wo doch die Abfrage ohne Index nur etwas länger benötigen sollte? -> nslcd -d -> Abfragen mit ldapsearch validiert: "(&(objectClass=posixAccount)(uid=test1))" -> der index auf uid stört tatsächlich Also erstmal wieder raus.
Problem gelöst, ein Index wirkt immer nur bei neu hinzugefügten Objekten. Werden Indizes nachträglich hinzugefügt, ist slapindex dein Freund und Helfer. Slapd vorher natürlich anhalten.
Ohne den Index kommen noch Abfragen nach posixGroup und uidNumber (beide korrekt), aber keine Abfrage nach dem Passwort.
Ja, ein leerer Index ist schlimmer als gar keiner. ;)
Letzte Erkenntnis: ldapsearch -h 127.0.0.1 -D uid=test1,ou=people,dc=domain,dc=de -W Enter LDAP Password: SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49)
Wieso mischt SASL hier wieder mit? Das Password wurde wahlweise als clear, crypt, md5crypt, md5 oder smd5 gespeichert - alles erfolglos.
der fehlende Parameter -x für simple auth war hier des Rätsels Lösung.
Das Anmeldeproblem besteht aber immer noch, nun mit den folgenden Meldungen:
auth.log (nach dem Passwort) Nov 5 17:30:41 lenny sshd[31672]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxxxx.dip0.t-ipconnect.de user=test1 Nov 5 17:30:42 lenny sshd[31672]: Failed password for test1 from 84.179.yyy.zzz port 3863 ssh2
nslcd -d nach login: nslcd: [8b4567] DEBUG: connection from pid=31672 uid=0 gid=0 nslcd: [8b4567] DEBUG: nslcd_passwd_byname(test1) nslcd: [8b4567] DEBUG: myldap_search(base="dc=domain,dc=de", filter="(&(objectClass=posixAccount)(uid=test1))") nslcd: [8b4567] DEBUG: simple anonymous bind to ldap://127.0.0.1/ nslcd: [8b4567] connected to LDAP server ldap://127.0.0.1/ nslcd: [8b4567] DEBUG: ldap_result(): end of results
nach passwd: nslcd: [7b23c6] DEBUG: connection from pid=31672 uid=0 gid=0 nslcd: [7b23c6] DEBUG: nslcd_passwd_byname(test1) nslcd: [7b23c6] DEBUG: myldap_search(base="dc=domain,dc=de", filter="(&(objectClass=posixAccount)(uid=test1))") nslcd: [7b23c6] DEBUG: simple anonymous bind to ldap://127.0.0.1/ nslcd: [7b23c6] connected to LDAP server ldap://127.0.0.1/ nslcd: [7b23c6] DEBUG: ldap_result(): end of results nslcd: [3c9869] DEBUG: connection from pid=31672 uid=0 gid=0 nslcd: [3c9869] DEBUG: nslcd_passwd_byname(test1) nslcd: [3c9869] DEBUG: myldap_search(base="dc=domain,dc=de", filter="(&(objectClass=posixAccount)(uid=test1))") nslcd: [3c9869] DEBUG: simple anonymous bind to ldap://127.0.0.1/ nslcd: [3c9869] connected to LDAP server ldap://127.0.0.1/ nslcd: [3c9869] DEBUG: ldap_result(): end of results
Diese Abfragen werden vom LDAP-Server auch bei einem "simple anonymous bind" mit einem Treffer beantwortet, natürlich ohne Herausgabe des Passworts. ;) Aber das sollte ja eigentlich mit einem normalen bind auf den Benutzer getestet werden.
Gruß Rico
lug-dd@mailman.schlittermann.de
-
Rico Koerner