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