pam nss ldap problem

[SDP]

Hi,

habe ein kleines Probelm mit der Authentifizierung über PAM.
Habe meiner Meinung nach alles "richtig" eingerichtet, aber trotzdem läuft da was falsch.

Client --> debian
Ldap-Directory-Server --> Win2003Server

Folgendes Problem:
trotz eines falschen Passwortes werde ich am Client angemeldet, wie kann das sein? LdapLog zeigt ein unterschiedliches Verhalten vom Server bei richtigem und falschen PW, also erkennt er schon, dass das PW richtig bzw. falsch war. macht im anschluss aber (scheinbar) nochmal einen bind mit admin (wenn das PW falsch war). Warum und wie kann ich mir da abhilfe schaffen? Hat vielleicht jemand eine Idee?

Danke und Grüße
Sascha

[mkahle]

login an der Konsole oder per ssh oder ...?
ggf. Inhalt der Dateien /etc/pam.d/login, /etc/ldap.conf und /etc/nsswitch.conf?

Passwörter bitte überschreiben.

[SDP]

hi,

bevor ich hier alles reinposte, habe ich grade festgestellt, dass ich mich sogar ohne existierende /etc/pam.d/login datei anmelden kann. mache eine Konsolenanmeldung. da ich erst seit sehr kurzem versuche mich mit diesem thema zu beschäftigen, habe ich wohl noch nicht ganz verstanden, wie das ablaufen muss.

hast du dazu vielleicht eine idee?

[mkahle]

X- oder Textkonsole?

[SDP]

textkonsole

hier mal meine konfiguration, wie ich sie mir im netz zusammengesucht hatte.

#
# /etc/pam.d/common-account - authorization settings common to all services
#
account sufficient pam_unix.so
account required pam_ldap.so use_first_pass


#
# /etc/pam.d/common-auth - authentication settings common to all services
#
auth sufficient pam_unix.so
auth required pam_ldap.so use_first_pass


#
# /etc/pam.d/common-password - password-related modules common to all services
#
password requisite pam_unix.so md5 #nullok obscure min=4 max=8 md5
password required pam_ldap.so use_first_pass


#
# /etc/pam.d/common-session - session-related modules common to all services
#
session sufficient pam_unix.so
session required pam_ldap.so use_first_pass
#session sufficient pam_mkhomedir.so skel=/etc/skel/ umask=0022


#
# /etc/pam.d/login The PAM configuration file for the Shadow `login' service
#
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
@include common-auth
@include common-account
@include common-session
session optional pam_lastlog.so
session optional pam_motd.so
@include common-password

#
# /etc/nsswitch.conf
#
passwd: ldap compat
group: ldap compat
shadow: ldap compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis


#
# pam_ldap.conf --> nss_ldap.conf ist auf pam_ldap.conf gelinkt
#
host 192.168.11.101
base o=my-company
ldap_version 3
binddn cn=admin,o=my-company
bindpw ****************
pam_filter objectclass=posixAccount
pam_login_attribute uid
nss_base_passwd ou=accounting,o=my-company
nss_base_shadow ou=accounting,o=my-company
nss_base_group ou=accounting,o=my-company

[mkahle]

hast Du evtl. eine Datei namens other im pam.d Verzeichnis und wie sieht der Inhalt aus, falls sie existiert?

[SDP]

ja, hatte ich, verwende ich aber nicht mehr. d.h. ich habe sie rausgeschmissen.

hast du vielleicht ideen, warum ich mich mit einem beliebigen passwort anmelden kann?

danke schonmal
grüße
sascha

[mkahle]

ich denke, das entscheidende Kriterium zur Überprüfung des Paßwortes ist, ob ein erfolgreicher bind an den LDAP Server mit der gegebenen DN des Users und des Paßwortes möglich ist. Wenn keine Fehler zurückkommt, wird angenommen, daß das Paßwort OK war.

Probiere doch mal folgendes:

ldapwhoami -x -D uid=existierender_user,ou=accounting,o=my-company -w beliebiges_passwort

[SDP]

funktioniert nicht (auch mit dem richtigen passwort nicht), muss ich mich nicht zuvor mit einem user (z.B. admin) binden, damit ich das attribut userPassword auslesen kann? meine user dürfen ihre passwörter in diesem Beispiel nicht einsehen bzw. das attribut nicht sehen.

wenn ich aber ein:

ldapwhoiam -x -H ldap:// ..... :389 -D cn=admin,o=my-company -w <adminpasswort>
mache, bekomme ich die meldung:
Result: Server is unwilling to perform (53)

--> adminpasswort stimmt aber

[SDP]

ldapwhoami meinte ich natürlich :)

[mkahle]

ok ... dann unterstützt der LDAP Server das Kommando nicht. Dann halt:

ldapsearch -x -D uid=existierender_user,ou=accounting,o=my-company -w beliebiges_aber_falsche_passwort "(uid=existierender_user)"

[SDP]

ich bekomme folgende meldung bei einem falschen aber auch bei einem richtigen passwort:

ldap_bind: Invalid credentials (49)
additional info: Authenticated bind failed. Anonymous bind established.


ich werde langsam irre damit :(

[SDP]

wenn ich das als cn=admin,o=my..... bekomme ich alle user inkl. attribute

ist das admin passwort falsch bekomme ich die gleiche meldung wie oben

[mkahle]

Ist eventuell die base in der /etc/openldap/ldap.conf nicht richtig?

Versuche mal die base (-b) mit anzugeben:

ldapsearch -x -b o=my-company -D uid=existierender_user,ou=accounting,o=my-company -w beliebiges_aber_falsche_passwort "(uid=existierender_user)"

[SDP]

habe ich auch die gleiche meldung, es ist doch nicht so, wenn ich einen ldap-server benutze, der nicht auf dieser debian-maschine läuft und nicht openldap ist (ist ein dirx von Siemens, der auf einer windowsmaschine läuft), dass ich openldap konfigurieren muss.
ich habe openldap garnicht installiert, meine base o=my-company steht in pam_ldap.conf, dass der ldapserver vom dirx richtig konfiguriert ist, davon kann man ausgehen.
gibt es vielleicht noch andere vorschläge, woran das liegen kann?
hatte so eine vermutung:
bei der anmeldung am client werden doch die einzelnen pam-module abgearbeitet. zuerst macht er bei mir ein rootbinddn, um sich mit dem ldap zu binden und nach der uid suchen zu können. danach versucht er mit dem gefundenen eintrag (dann mit dem dn) einen user-bind zu machen. also mit dem user, mit dem ich mich am client anmelden wollte. ist dieser erfolgreich, so arbeitet er alle anderen benötigten pam-module ab und holt sich die benötigten attribute (z.b. gidnumber, uidnumber, loginshell etc.). ist er mit dem user-bind nicht erfolgreich, so macht er merkwürdigerweise einen weiteren rootbinddn und holt sich damit alle nötigen infos und melden den user trotz falschem passwort am client an.

könnte das so sein (laut logfile sieht das so aus).
kann man da vielleicht was machen?

[SDP]

funktioniert jetzt, habe in meinem schema ein cn=user mit objectclass posixGroup angelegt, seit dem geht das, obwohl die user nicht unbedingt dieser gruppe angehören. wie kann das jetzt sein?