Re: Probleme mit LDAP-Authentifizierung
Thomas Guenther schrieb: > Markus Schulz schrieb: [...] > Das scheint auch das Problem gewesen zu sein. Jedenfalls geht jetzt > alles, so wie es soll. Fein. >> 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? > > Vermutlich stammt der Eintrag aus meiner "Experimentierphase". Ich hab > ihn jetzt deaktiviert und direkt auch noch in der pam_ldap.conf und der > ldap.conf. > Aber auf Grund welcher Regel eigentlich jeder die Daten lesen kann, ist > mir im Moment etwas schleierhaft. Geht das wegen: > > access to attrs=userPassword, > by anonymous auth Nein, das schränkt nur den Zugriff auf das Crypt Password (und wohl noch die Samba-PDC Passwörter: sambaLMPassword,sambaNTPassword) ein. Das braucht der nss-ldap Dienst aber garnicht, das braucht nur das pam-ldap Modul. Damit der Rest (also alles ausser die Crypt Passwörter) per Anon gelesen werden kann, hast du garantiert noch eine ACL im slapd drin: z.B. in der Art: access to * by dn.regex="cn=admin,..." write by * read 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)
Re: Probleme mit LDAP-Authentifizierung
Markus Schulz schrieb: Hallo, Hallo, Thomas Guenther schrieb: [...] hier einfügen. Damit der Pam-Dienst (pam_ldap) auch die Daten zu dem Nutzer finden kann. Ok, erledigt. Das scheint auch das Problem gewesen zu sein. Jedenfalls geht jetzt alles, so wie es soll. Ist denn dein nss_base_* wirklich die korrekte Position? Meist nennt man die entsprechenden Pfade in der Art:(komplette Zeile) nss_base_passwdou=Users,dc=example,dc=com?one Ich weiss nicht mehr genau, wieso ich die gekürzte (also ohne ou=) Version verwendet habe. Das LDAP-System ist inzwischen fast 2 Jahre alt. Aber es wird demnächst sowieso ersetzt, dann muss ich mich mit dem ganzen Kram nochmal rumschlagen und dann komm ich vielleicht auch drauf, wieso ich das so erledigt habe. Wenn ich mich recht entsinne, hat das irgendwie damit zu tun, dass das ganze als PDC läuft und die Rechnernamen, die zu einer Windows-Domain hinzugefügt werden, zwar als User im Posixbereich geführt werden, aber mit den von mir verwendeten smbldap-tools nicht in ou=Users,... abgelegt werden, weil ... Ich weiss es nicht mehr. scope sub scope one scope base Was soll das? Entweder nur einmal festlegen oder garnicht ;) Kannst du getrost weglassen. Sieht in der Tat merkwürdig aus. Ist auf dem LDAP-System aber auch so drauf, scheint also keine Probleme zu bereiten. ;-) [...] 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? Vermutlich stammt der Eintrag aus meiner "Experimentierphase". Ich hab ihn jetzt deaktiviert und direkt auch noch in der pam_ldap.conf und der ldap.conf. Aber auf Grund welcher Regel eigentlich jeder die Daten lesen kann, ist mir im Moment etwas schleierhaft. Geht das wegen: access to attrs=userPassword, by anonymous auth ? MfG Markus Schulz Ich danke Dir für Deine Hilfe! Thomas -- 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)
Re: Probleme mit LDAP-Authentifizierung
Hallo, Thomas Guenther schrieb: [...] >> /etc/ldap/ldap.conf > > --ldap.conf--- > host > base > > ldap_version 3 > binddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de > bindpw > > 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 > base > > 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_passwdou=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=: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=: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]:
Re: Probleme mit LDAP-Authentifizierung
Markus Schulz schrieb: Am Dienstag, 20. Juni 2006 15:07 schrieb Thomas Guenther: Hallo, [...] Bin ich auf dem Sarge-System root und wechsle nach user2, geht das sofort und ohne Probleme. Und auch ein Netzwerksniffen brachte wohl, weil du die rootbinddn in der ldap.conf gesetzt hast + ldap.secret. Ja, exakt. [...] Wie sehen die üblichen verdächtigen denn aus? /etc/ldap/ldap.conf --ldap.conf--- host base ldap_version 3 binddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de bindpw 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 ssl no pam_password crypt -- /etc/libnss-ldap.conf ---libnss-ldap.conf--- host uri ldap://iit005.uni-duisburg.de/ base ldap_version 3 binddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de bindpw nss_base_passwd dc=x,dc=y,dc=de?sub nss_base_shadow dc=x,dc=y,dc=de?sub nss_base_group ou=Groups,dc=x,dc=y,dc=de?one pam_filter objectclass=posixAccount use_sasl off -- -pam_ldap.conf- host base ldap_version 3 rootbinddn cn=nssldap,ou=dsa,dc=x,dc=y,dc=de scope sub scope one scope base pam_filter objectclass=posixAccount pam_password crypt --- -nsswitch.conf- passwd: files ldap group: files ldap shadow: files ldap hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc:db files #netgroup: nis --- /etc/pam.d/common-auth (oder wo auch immer du ldap eingetragen hast) ---common-auth--- auth sufficient pam_ldap.so auth required pam_unix.so try_first_pass - ---common-account--- account sufficient pam_ldap.so account required pam_unix.so ---common-password-- password sufficient pam_ldap.so password required pam_unix.so 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=: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)))" 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= 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= Jun 20 10:02:44 iit005 slapd[7759]: conn=24811 fd=42 ACCEPT from 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 wartet das System auf das Passwort, der folgende Abschnitt zeigt die Reaktion nach
Re: Probleme mit LDAP-Authentifizierung
Am Dienstag, 20. Juni 2006 15:07 schrieb Thomas Guenther: > Hallo, > > ich habe hier einen Linux-Server mit Samba und Openldap als PDC > laufen. Installiert ist das ganze auf einem woody, wobei samba > und openldap (v2.2.19) selbstkompiliert sind. Das ganze läuft > ohne Problem. > > Wenn ich jetzt versuche, von einem Sarge-System aus eine > Authentifizierung per Konsolenlogin, ssh oder su zu machen, > schlägt das ganze fehl. Das Problem dabei ist offensichtlich > irgendwas mit dem Passwort. Wenn ich auf dem Sarge-System ein > lokaler User bin, z.B. user1 und ein su benutze, um user2 zu > werden, der nur auf dem LDAP-System existiert, wird nach einem > Passwort gefragt. Dann bekomme ich nach einer kurzen Pause ein: > "su: Authentication service cannot retrieve authentication info." > Bin ich auf dem Sarge-System root und wechsle nach user2, geht > das sofort und ohne Probleme. Und auch ein Netzwerksniffen brachte wohl, weil du die rootbinddn in der ldap.conf gesetzt hast + ldap.secret. > mich soweit, dass die Benutzerinformationen abgefragt und auch > geliefert werden, aber irgendwas mit dem Passwort haut nicht hin, > vermute ich. > > Die PAM's (su, ssh, login) sind eigentlich soweit für ldap angepasst, > auch die nsswitch.conf, die libnss-ldap.conf und die pam_ldap.conf. > Im Prinzip habe ich die Dateien vom LDAP-System kopiert. > > Hat einer eine Idee, woran es liegen könnte, das die Authentifizerung > gegen das LDAP-System fehlschlägt? Habe ich vielleicht irgendetwas > übersehen? Wie sehen die üblichen verdächtigen denn aus? /etc/ldap/ldap.conf /etc/libnss-ldap.conf /etc/pam.d/common-auth (oder wo auch immer du ldap eingetragen hast) In jedem Fall den slapd auf LogLevel 256 setzen und anschauen was da genau ankommt. Damit siehst du jedes Query auf die Ldap Datenbank. ldapsearch mit -D auch probieren. Bekommst du damit dein Passwort zu gesicht? Liefert getent korrekte Informationen? Wir brauchen in jedem Fall mehr Informationen, sonst stochern wir hier nur hilflos im Dunkeln 'rum. Insbesondere am slapd Log sieht man eigentlich recht schnell woran es hakt, auch wenn dort recht viel geloggt wird und das ganze anfangs etwas unübersichtlich wirkt. -- Markus Schulz "Des is völlig wurscht, was heut beschlossen wird: I bin sowieso dagegn!" (SPD-Stadtrat Kurt Schindler; Regensburg)
Re: Probleme mit LDAP-Authentifizierung
On Tue, Jun 20, 2006 at 03:07:24PM +0200, Thomas Guenther wrote: > Hallo, Hallo, > > Wenn ich jetzt versuche, von einem Sarge-System aus eine > Authentifizierung per Konsolenlogin, ssh oder su zu machen, > schlägt das ganze fehl. Das Problem dabei ist offensichtlich > irgendwas mit dem Passwort. Wenn ich auf dem Sarge-System ein > lokaler User bin, z.B. user1 und ein su benutze, um user2 zu > werden, der nur auf dem LDAP-System existiert, wird nach einem > Passwort gefragt. Dann bekomme ich nach einer kurzen Pause ein: > "su: Authentication service cannot retrieve authentication info." > Bin ich auf dem Sarge-System root und wechsle nach user2, geht > das sofort und ohne Probleme. Und auch ein Netzwerksniffen brachte > mich soweit, dass die Benutzerinformationen abgefragt und auch > geliefert werden, aber irgendwas mit dem Passwort haut nicht hin, > vermute ich. Ist der Benutzer zu wechseln/einloggen willst im LDAP auch ein POSSIX-ACCOUNT? Wenn du ein ldapsearch oder ähnliches anwirfst wird dir da ein Password angezeigt? Wenn ja ist es verschlüsselt oder klartext? Wenn verschlüsselt dann wie? Und wenn mich nicht alles täuscht dann muß man die entsprechende Verschlüsselung auch in die ldap.conf oder in die slapd.conf eintragen. Da könnte ich aber bei Bedarf nochmal nachschauen. > > Die PAM's (su, ssh, login) sind eigentlich soweit für ldap angepasst, > auch die nsswitch.conf, die libnss-ldap.conf und die pam_ldap.conf. > Im Prinzip habe ich die Dateien vom LDAP-System kopiert. hast du da auch drauf aufgepasst das du evtl. den hostnamen anpassen mußt? > > Hat einer eine Idee, woran es liegen könnte, das die Authentifizerung > gegen das LDAP-System fehlschlägt? Habe ich vielleicht irgendetwas > übersehen? Also ich habe die Erfahrung gemacht das LDAP nicht so ganz einfach aufzusetzen ist. Aber das bekommen wir schon hin ;). > > Gruss > Thomas Gruß Sven signature.asc Description: Digital signature
