Hallo alle;
ich versuche gerade (mäßig erfolgreich), einen Linux-Server von "klassischer" (dateibasierter) auf LDAP-basierte Nutzerverwaltung umzustellen. Situation:
* slapd, libnss-ldap und libpam-ldap sind installiert und konfiguriert (Debian-stable mit den entsprechenden Paketen)
* die Nutzer-Konten liegen im LDAP
* /etc/nsswitch.conf und /etc/pam.d/ssh sind analog zu den Vorgaben in der Doku modifiziert worden
* momentan beinhaltet die nsswitch.conf Einträge der Art
... passwd: files ldap ...
* ich habe einen Nutzer auf dem System innerhalb der /etc/passwd- bzw /etc/shadow - Files gelöscht, nachdem ich die Accounts nach LDAP geschoben habe - somit sollte der Nutzer nur im LDAP liegen.
Jetzt zeigt sich folgende interessante Situation:
* Gehe ich mit einem Browser (gq, ...) in das Verzeichnis / bemühe ich ldapsearch, finde ich das Konto.
* Verwende ich an der Konsole "id <account>", sehe ich in der Tat auch die korrekten Angaben zu diesem Nutzer.
Aber:
* In der Ausgabe von "getent passwd" sehe ich ihn _nicht_.
* Authentifikation etwa bei Anmeldung über ssh scheitert mit Meldungen wie der folgenden:
Nov 30 15:08:11 kerberos slapd[31020]: SRCH "dc=planconnect,dc=net" 2 0 Nov 30 15:08:11 kerberos slapd[31020]: 1 0 0 Nov 30 15:08:11 kerberos slapd[31020]: filter: (&(objectClass=shadowAccount)(uid=fnord)) Nov 30 15:08:11 kerberos slapd[31020]: attrs: Nov 30 15:08:11 kerberos slapd[31020]: uid Nov 30 15:08:11 kerberos slapd[31020]: userPassword Nov 30 15:08:11 kerberos slapd[31020]: shadowLastChange Nov 30 15:08:11 kerberos slapd[31020]: shadowMax Nov 30 15:08:11 kerberos slapd[31020]: shadowMin Nov 30 15:08:11 kerberos slapd[31020]: shadowWarning Nov 30 15:08:11 kerberos slapd[31020]: shadowInactive Nov 30 15:08:11 kerberos slapd[31020]: shadowExpire Nov 30 15:08:11 kerberos slapd[31020]: shadowFlag Nov 30 15:08:11 kerberos slapd[31020]: Nov 30 15:08:11 kerberos slapd[31020]: bdb_idl_fetch_key: [b49d1940] Nov 30 15:08:11 kerberos slapd[31020]: bdb_idl_fetch_key: [64a68d50] Nov 30 15:08:11 kerberos slapd[31020]: <= bdb_equality_candidates: (uid) index_param failed (18)
Nachdem ich mittlerweile leicht verwirrt irgendwo zwischen nsswitch, ldap und pam herumtaumele: Kann mich diesbezüglich jemand erleuchten, wo hier die Säge klemmen könnte? Google war diesbezüglich leider wenig hilfreich, zumal mir noch nicht mal genau klar ist, wonach ich suche (das getent-Verhalten würde mich nss-ldap verdächtigen lassen, aber paßt das "id" - Verhalten dazu?).
Danke und bye, Kris