On Jun 7, 2010, at 3:50 AM, Buchan Milne wrote:
Sure, but are you sure ldapsearch and pam_ldap are using the same password?
If
you *think* so, maybe you should check with a packet capture ...
I did, and found that pam_ldap had altered the password prior to submittal.
It turns out that
Jo Rhett jrh...@netconsonance.com writes:
I did, and found that pam_ldap had altered the password prior to
submittal. It turns out that for what it perceives as invalid user ids,
it changes the password hash to 'INCORECT', mis-spelling and all. There
was a problem with nsswitch/nscd which
On Jun 9, 2010, at 12:37 PM, Russ Allbery wrote:
I can tell you in general why a PAM module would do that. One of the
much faster than the first. This information disclosure vulnerability
could then be used to further target brute-force password attacks and
I understand that. I
Jo Rhett wrote:
On Jun 9, 2010, at 12:37 PM, Russ Allbery wrote:
I can tell you in general why a PAM module would do that. One of the
much faster than the first. This information disclosure vulnerability
could then be used to further target brute-force password attacks and
I
On Friday, 4 June 2010 23:50:26 Jo Rhett wrote:
I'm seeing a problem where I can authenticate as a user using the ldap
tools (ie ldapsearch) but I am unable to login using PAM.
Comparing debug on the server shows that ldapsearch is doing a new BIND,
where's PAM is not:
Jun 4 14:58:52
I'm seeing a problem where I can authenticate as a user using the ldap tools
(ie ldapsearch) but I am unable to login using PAM.
Comparing debug on the server shows that ldapsearch is doing a new BIND,
where's PAM is not:
Jun 4 14:58:52 ldap-server slapd[5158]: = dn: [1]
Jun 4 14:58:52
