Hallo,
Thomas Guenther schrieb: [...] >> /etc/ldap/ldap.conf > > ------------------ldap.conf------------------- > host <ldap-system ip> > base <dc=x,dc=y,dc=de> > > ldap_version 3 > binddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de > bindpw <pwd f. nssldap> > > nss_base_passwd dc=x,dc=y,dc=de?sub > nss_base_shadow dc=x,dc=y,dc=de?sub > nss_base_group dc=x,dc=y,dc=de?one Diese drei Zeilen bitte... > ssl no > pam_password crypt > ---------------------------------------------- > > [...] > ---------------------pam_ldap.conf--------------------- > host <ldap-system ip> > base <dc=x,dc=y,dc=de> > > ldap_version 3 > > rootbinddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de hier einfügen. Damit der Pam-Dienst (pam_ldap) auch die Daten zu dem Nutzer finden kann. Ist denn dein nss_base_* wirklich die korrekte Position? Meist nennt man die entsprechenden Pfade in der Art:(komplette Zeile) nss_base_passwd ou=Users,dc=example,dc=com?one > scope sub > scope one > scope base Was soll das? Entweder nur einmal festlegen oder garnicht ;) Kannst du getrost weglassen. > pam_filter objectclass=posixAccount > > pam_password crypt Ansonsten sieht das Setup ok aus. > >> In jedem Fall den slapd auf LogLevel 256 setzen und anschauen was da >> genau ankommt. Damit siehst du jedes Query auf die Ldap Datenbank. > > Ist schon. Hier mal der Teil mit der Anmeldung vom CLIENT bis zum > Zeitpunkt, als das Passwort für den User eingegeben wurde und eine > erneute Passworteingabe erwartet wurde: > > Jun 20 10:02:44 iit005 slapd[7759]: conn=24810 fd=38 ACCEPT from > IP=<client ip>:32915 (IP=0.0.0.0:389) > Jun 20 10:02:44 iit005 slapd[7778]: conn=24810 op=0 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" method=128 > Jun 20 10:02:44 iit005 slapd[7778]: conn=24810 op=0 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" mech=SIMPLE ssf=0 > Jun 20 10:02:44 iit005 slapd[7778]: conn=24810 op=0 RESULT tag=97 err=0 > text= > Jun 20 10:02:44 iit005 slapd[7762]: conn=24810 op=1 SRCH > base="dc=x,dc=y,dc=de" scope=2 deref=0 > filter="(&(objectClass=posixAccount)(\ > uid=user1))" > Jun 20 10:02:44 iit005 slapd[7762]: conn=24810 op=1 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Jun 20 10:02:44 iit005 slapd[7761]: conn=24810 op=2 SRCH > base="ou=Groups,dc=x,dc=y,dc=de" scope=1 deref=0 > filter="(&(objectClass=posi\ > xGroup)(|(memberUid=user1)(uniqueMember=uid=user1,ou=users,dc=x,dc=y,dc=de)))" > also doch ou=users. > Jun 20 10:02:44 iit005 slapd[7761]: conn=24810 op=2 SRCH attr=gidNumber > Jun 20 10:02:44 iit005 slapd[7761]: <= bdb_equality_candidates: > (uniqueMember) index_param failed (18) > Jun 20 10:02:44 iit005 slapd[7761]: conn=24810 op=2 SEARCH RESULT > tag=101 err=0 nentries=1 text= nentries=1 -> also gefunden. > Jun 20 10:02:44 iit005 slapd[21337]: conn=24810 op=3 SRCH > base="ou=Groups,dc=x,dc=y,dc=de" scope=1 deref=0 > filter="(&(objectClass=pos\ > ixGroup)(uniqueMember=cn=group1,ou=groups,dc=x,dc=y,dc=de))" > Jun 20 10:02:44 iit005 slapd[21337]: conn=24810 op=3 SRCH attr=gidNumber > Jun 20 10:02:44 iit005 slapd[21337]: <= bdb_equality_candidates: > (uniqueMember) index_param failed (18) > Jun 20 10:02:44 iit005 slapd[21337]: conn=24810 op=3 SEARCH RESULT > tag=101 err=0 nentries=0 text= Gruppe nicht gefunden? Fehlen die oder falsche Position? Libnss-ldap.conf eventuell anpassen bzgl. nss_base_group. > Jun 20 10:02:44 iit005 slapd[7759]: conn=24811 fd=42 ACCEPT from > IP=<client ip>:32916 (IP=0.0.0.0:389) > Jun 20 10:02:44 iit005 slapd[7778]: conn=24811 op=0 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" method=128 > Jun 20 10:02:44 iit005 slapd[7778]: conn=24811 op=0 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" mech=SIMPLE ssf=0 > Jun 20 10:02:44 iit005 slapd[7778]: conn=24811 op=0 RESULT tag=97 err=0 > text= > Jun 20 10:02:44 iit005 slapd[7762]: conn=24811 op=1 SRCH > base="dc=x,dc=y,dc=de" scope=0 deref=0 filter="(uid=user1)" > Jun 20 10:02:44 iit005 slapd[7762]: conn=24811 op=1 SEARCH RESULT > tag=101 err=0 nentries=0 text= Hier such pam_ldap und die Base sieht falsch aus, kein ou=users,... zu sehen. Er findet daher auch nichts. Bin mir grad nicht sicher wie die numerischen Codes für scope=0,.. aussehen. Sprich ob er auch rekursiv in diesem Falle sucht. Besser aber den korrekten Zweig wie oben beschrieben in der pam_ldap.conf angeben. > > (hier wartet das System auf das Passwort, der folgende Abschnitt > zeigt die Reaktion nach der Passworteingabe) > > Jun 20 10:03:16 iit005 slapd[21337]: conn=24812 op=4 SRCH > base="dc=x,dc=y,dc=de" scope=2 deref=0 > filter="(&(objectClass=shadowAccount\ > )(uid=user1))" > Jun 20 10:03:16 iit005 slapd[21337]: conn=24812 op=4 SRCH attr=uid > userPassword shadowLastChange shadowMax shadowMin shadowWarning sh\ > adowInactive shadowExpire shadowFlag > Jun 20 10:03:16 iit005 slapd[21337]: conn=24812 op=4 SEARCH RESULT > tag=101 err=0 nentries=1 text= > Jun 20 10:03:17 iit005 slapd[7778]: conn=24813 op=2 BIND anonymous > mech=implicit ssf=0 > Jun 20 10:03:17 iit005 slapd[7778]: conn=24813 op=2 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" method=128 > Jun 20 10:03:17 iit005 slapd[7778]: conn=24813 op=2 BIND > dn="cn=nssldap,ou=dsa,dc=x,dc=y,dc=de" mech=SIMPLE ssf=0 > Jun 20 10:03:17 iit005 slapd[7778]: conn=24813 op=2 RESULT tag=97 err=0 > text= > Jun 20 10:03:17 iit005 slapd[7762]: conn=24813 op=3 SRCH > base="dc=x,dc=y,dc=de" scope=0 deref=0 filter="(uid=user1)" > Jun 20 10:03:17 iit005 slapd[7762]: conn=24813 op=3 SEARCH RESULT > tag=101 err=0 nentries=0 text= Siehe oben, wieder an falscher Stelle gesucht. Bei den Search Results immer auch die Variable nentries achten. Warum verwendest du eigentlich binddn? libnss-ldap.conf kann auch anonymouse die Daten ermitteln, soll ja keinen Geheimen Daten ermitteln. Oder sind deine slapd-ACLs so restriktiv? MfG Markus Schulz -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)