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
Am Mittwoch 30 November 2005 15:17 schrieb Kristian Rink:
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
Könntest Du mal bitte die ldif-Ausgabe für einen Beispielnutzer, so wie sie bei Dir im LDAP liegen, bringen?
Hallo William, @liste;
William Epler schrieb:
- die Nutzer-Konten liegen im LDAP
Könntest Du mal bitte die ldif-Ausgabe für einen Beispielnutzer, so wie sie bei Dir im LDAP liegen, bringen?
Die Erzeugung der Nutzer ist unter Verwendung der migrationtools-Skripte vonstatten gegangen (ebenfalls Debian-Pakete). Exemplarisch sieht das in etwa so aus:
dn: uid=tomcat,ou=People,dc=planconnect,dc=net uid: tomcat cn:: dG9tY2F0 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}$1$ztlfw3cb$bVi0jhv1pZkOqN54xkOqV1 shadowLastChange: 13117 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1009 gidNumber: 1009 homeDirectory: /home/tomcat gecos: ,,,
Cheers, Kris
Am Mittwoch 30 November 2005 15:43 schrieb Kristian Rink:
Hallo William, @liste;
William Epler schrieb:
- die Nutzer-Konten liegen im LDAP
Könntest Du mal bitte die ldif-Ausgabe für einen Beispielnutzer, so wie sie bei Dir im LDAP liegen, bringen?
Die Erzeugung der Nutzer ist unter Verwendung der migrationtools-Skripte vonstatten gegangen (ebenfalls Debian-Pakete). Exemplarisch sieht das in etwa so aus:
dn: uid=tomcat,ou=People,dc=planconnect,dc=net uid: tomcat cn:: dG9tY2F0 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}$1$ztlfw3cb$bVi0jhv1pZkOqN54xkOqV1 shadowLastChange: 13117 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1009 gidNumber: 1009 homeDirectory: /home/tomcat gecos: ,,,
Ich nutze zwar kein Debian, aber die folgenden Konfigurations-Beispiele sollten dem Gewünschten nahekommen...
Achtung: /etc/ldap.conf ist nicht gleich /etc/openldap/ldap.conf!
Beispiel /etc/ldap.conf (SuSE - für pam_unix2.so)
host <ldapserver> base dc=planconnect,dc=net ldap_version 3 pam_password crypt nss_map_attribute uniqueMember member pam_filter objectclass=posixAccount nss_base_passwd ou=People,dc=planconnect,dc=net nss_base_shadow ou=People,dc=planconnect,dc=net nss_base_group ou=Group,dc=planconnect,dc=net
Beispiel /etc/openldap/ldap.conf
URI ldap://<ldapserver> base dc=planconnect,dc=net TLS_REQCERT never
Beispiel /etc/nsswitch.conf
passwd: compat group: compat ...
Beispiel /etc/pam.d/system-auth (RedHat)
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so
SuSE: # yast ldap
Cheers, Kris
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Kristian Rink afterimage@gmx.net (Mi 30 Nov 2005 15:17:10 CET):
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
¬ libnssldap installiert? ¬ nscd mal versuchshalber ausgeschaltet?
Heiko
Hallo Heiko, @liste;
Heiko Schlittermann schrieb:
- /etc/nsswitch.conf und /etc/pam.d/ssh sind analog zu den Vorgaben in
der Doku modifiziert worden
¬ libnssldap installiert?
Ist da, ja.
¬ nscd mal versuchshalber ausgeschaltet?
nscd läuft auf dem System gar nicht... :o
Cheers, Kris
On Wed, 30 Nov 2005 15:17:10 +0100 Kristian Rink afterimage@gmx.net wrote:
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)
kann sein das ich das falsch interpretiere, aber für mich sieht es so aus als würde er zu der Anfrage 2 Ergebnisse bekommen. Vielleicht hast du den Nutzer irgendwie doppelt im Baum?
Henning
Hallo Henning, @liste;
erstmal danke für die Mail / die Hinweise...
Henning Schild schrieb:
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)
kann sein das ich das falsch interpretiere, aber für mich sieht es so aus als würde er zu der Anfrage 2 Ergebnisse bekommen. Vielleicht hast du den Nutzer irgendwie doppelt im Baum?
Nein. Hab ich getestet, sogar die LDAP-Datenbank nochmal neu erzeugt. Look:
kerberos:~# getent passwd | grep ^root root:x:0:0:root:/root:/bin/bash root:x:0:0:root:/root:/bin/bash kerberos:~# getent passwd | grep ^fnord kerberos:~#
Laut nsswitch.conf werden immer noch erst "files" und dann "ldap" durchsucht. "root" existiert in beiden, "fnord" (...) nur im LDAP-Verzeichnis. Find ich irgendwie eigenartig... Btw: Das Logfile vermeldet Dinge der Art
[...] Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (uid) index_param failed (18) Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (cn) index_param failed (18) [...]
Was will mir dieser Fehler in dieser Situation sagen?
Cheers, Kris
Hallo nochmal;
Kristian Rink schrieb:
Nein. Hab ich getestet, sogar die LDAP-Datenbank nochmal neu erzeugt. Look:
kerberos:~# getent passwd | grep ^root root:x:0:0:root:/root:/bin/bash root:x:0:0:root:/root:/bin/bash kerberos:~# getent passwd | grep ^fnord kerberos:~#
Nachtrag dazu: Dieses Problem habe ich mittlerweile behoben. Ursache: Auf dem Rechner sind _sehr_ viele Nutzer existent, und slapd hat wohl dort nur die ersten 500 zurückgegeben. "sizelimit unlimited" in der slapd.conf hat diesbezüglich Abhilfe geschaffen. Was aber immer noch kommt, ist dieser Fehler
[...] Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (uid) index_param failed (18) Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (cn) index_param failed (18) [...]
bei dem Versuch, eine ssh-Anmeldung gegen LDAP zu authentifizieren... Nächster Schritt Arbeit, vermute ich...
Cheers, Kris
Kristian Rink afterimage@gmx.net (Do 01 Dez 2005 08:45:32 CET):
Hallo Henning, @liste;
erstmal danke für die Mail / die Hinweise...
[...] Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (uid) index_param failed (18) Dec 1 08:41:49 kerberos slapd[1064]: <= bdb_equality_candidates: (cn) index_param failed (18) [...]
Was will mir dieser Fehler in dieser Situation sagen?
Er meint, daß Du einen Index haben *könntest* für uid und cn. Aber keinen Index zu haben, ist in Deiner Situation nicht so schlimm.
Heiko
Heiko Schlittermann hs@schlittermann.de (Do 01 Dez 2005 09:03:31 CET):
Was will mir dieser Fehler in dieser Situation sagen?
Er meint, daß Du einen Index haben *könntest* für uid und cn. Aber keinen Index zu haben, ist in Deiner Situation nicht so schlimm.
Wo ich jetzt weiß, daß Du *sehr* viele (>500) Nutzer hast, würde ich doch einen Index anlegen.
Heiko
Hallo Heiko, @liste;
Heiko Schlittermann schrieb:
Er meint, daß Du einen Index haben *könntest* für uid und cn. Aber keinen Index zu haben, ist in Deiner Situation nicht so schlimm.
Wo ich jetzt weiß, daß Du *sehr* viele (>500) Nutzer hast, würde ich doch einen Index anlegen.
Hab ich mittlerweile auch getan; ich war ursprünglich davon ausgegangen, daß 500 Accounts für eine LDAP-Site nicht so übermäßig viel sind (andererseits sind es mittlerweile genug, um in /etc/passwd die Übersicht zu verlieren). Hat es Wert, an dem Punkt darüber nachzudenken, eine "richtige" SQL-Datenbank hinter LDAP zu hängen?
Cheers und danke, Kris
Kristian Rink afterimage@gmx.net (Do 01 Dez 2005 09:28:15 CET):
Hab ich mittlerweile auch getan; ich war ursprünglich davon ausgegangen, daß 500 Accounts für eine LDAP-Site nicht so übermäßig viel sind (andererseits sind es mittlerweile genug, um in /etc/passwd die Übersicht zu verlieren). Hat es Wert, an dem Punkt darüber nachzudenken, eine "richtige" SQL-Datenbank hinter LDAP zu hängen?
Warum sollte die dann schneller sein, als die DB-Files, die slapd jetzt nutzt?
500 ist nicht viel. Wir haben an einer Installation mit gut 5000 Nutzern mitgewirkt und das war für den LDAP auch ok.
Ohne Index muß aber der slapd sicher so etwas wie lineare Suche in den DB-Files machen. Mach doch mal Vergleichsmessungen.
Heiko
Hallo Heiko, @liste;
Heiko Schlittermann schrieb:
Übersicht zu verlieren). Hat es Wert, an dem Punkt darüber nachzudenken, eine "richtige" SQL-Datenbank hinter LDAP zu hängen?
Warum sollte die dann schneller sein, als die DB-Files, die slapd jetzt nutzt?
Ich hab' mir im Vorfeld dieser Sache verschiedene Tutorien gegeben, die sich allesamt zu der "Erkenntnis" verleiten ließen, LDAP lieber mit einem wie auch immer gearteten SQL-Server zu betreiben. Gehärtete Erfahrung dazu fehlt mir, daher die Frage; daß ein auf Abfragegeschwindigkeit getrimmter Server wie mySQL dort Performance-Vorteile bringen könnte, scheint als Idee per se erstmal nicht abwegig...
500 ist nicht viel. Wir haben an einer Installation mit gut 5000 Nutzern mitgewirkt und das war für den LDAP auch ok.
Mit den DB-Files? Dann dürfte es bei uns wohl auch reichen...
Ohne Index muß aber der slapd sicher so etwas wie lineare Suche in den DB-Files machen. Mach doch mal Vergleichsmessungen.
Beschränken wir uns momentan mal darauf, daß die Lookups via LDAP spürbar schneller sind - das reicht mir erstmal, Performance-Tuning kommt später. Momentan kratzt mich mehr, daß die Authentifikation gegen das Teil (ssh, ftp) noch nicht tut. Kann man irgendwie protokollieren, was bei pam_ldap passiert? Ich vermute mal, daß die Nutzer jetzt zumindest korrekt gefunden werden, aber das isses dann auch schon erstmal. :/
Danke und bye, Kris
Hallo!
Am Donnerstag, 1. Dezember 2005 13:06 schrieb Kristian Rink:
Ich hab' mir im Vorfeld dieser Sache verschiedene Tutorien gegeben, die sich allesamt zu der "Erkenntnis" verleiten ließen, LDAP lieber mit einem wie auch immer gearteten SQL-Server zu betreiben.
Kenne ich so nicht. Seit OpenLDAP 2.2 (aktuell ist 2.3.x) geht es mit Berkeley-DB 4.3 alles sehr schnell.
Gehärtete Erfahrung dazu fehlt mir, daher die Frage; daß ein auf Abfragegeschwindigkeit getrimmter Server wie mySQL dort Performance-Vorteile bringen könnte, scheint als Idee per se erstmal nicht abwegig...
LDAP ist ja selbst auf Abfragegeschwindigkeit getrimmt und nutzt dazu auch viel RAM.
Beschränken wir uns momentan mal darauf, daß die Lookups via LDAP spürbar schneller sind - das reicht mir erstmal, Performance-Tuning kommt später. Momentan kratzt mich mehr, daß die Authentifikation gegen das Teil (ssh, ftp) noch nicht tut.
Meine Folien vom Linux-Info-Tag kennst Du?
Kann man irgendwie protokollieren, was bei pam_ldap passiert?
slapd.conf, hier loglevel ansehen: # loglevel <integer> # Specify the level at which debugging statements and operation statistics should be # syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). Log levels are # additive, and available levels are: # 1 trace function calls # 2 debug packet handling # 4 heavy trace debugging # 8 connection management # 16 print out packets sent and received # 32 search filter processing # 64 configuration file processing # 128 access control list processing # 256 stats log connections/operations/results # 512 stats log entries sent # 1024 print communication with shell backends # 2048 entry parsing
loglevel 0 sizelimit 10000 threads 32
Ich vermute mal, daß die Nutzer jetzt zumindest korrekt gefunden werden, aber das isses dann auch schon erstmal. :/
Gruss Reiner
Hallo!
Am Donnerstag, 1. Dezember 2005 09:28 schrieb Kristian Rink:
Wo ich jetzt weiß, daß Du *sehr* viele (>500) Nutzer hast, würde ich doch einen Index anlegen.
Bei mir liegen in der slapd.conf als Index:
# Indices to maintain index objectClass pres,eq # Don't put all your energy in a senseless searching # index cn,sn pres,eq,sub index uid pres,eq index sambaSID eq index uidNumber eq index gidNumber eq index memberUid eq index sambaPrimaryGroupSID eq index sambaDomainName eq index ipHostNumber eq index dhcpHWAddress eq index dhcpClassData eq index gecos pres,sub,approx index default eq
Generell gilt: Alle Felder, nach denen häufiger gesucht wird, sollten als Index mit entsprechendem Parameter angegeben sein. Die Samba-Werte natürlich nur, wenn Windows im Spiel ist.
Hab ich mittlerweile auch getan; ich war ursprünglich davon ausgegangen, daß 500 Accounts für eine LDAP-Site nicht so übermäßig viel sind (andererseits sind es mittlerweile genug, um in /etc/passwd die Übersicht zu verlieren). Hat es Wert, an dem Punkt darüber nachzudenken, eine "richtige" SQL-Datenbank hinter LDAP zu hängen?
Nein. Ich habe auch eine Berufsschule mit mehr als 3000 Accounts mit einem LDAP (und einer Replikation) gebaut, ohne dass Probleme auftreten. Der nscd cacht ja zusätzlich.
Gruss Reiner
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Henning Schild -
Kristian Rink -
Reiner Klaproth -
William Epler