Re: [Phpgroupware-developers] phpgw password creation for ldap buggy?

[Lars Kneschke(priv.)]

Izzy Blacklock <address@hidden> schrieb: 
>After many frustrating hours, I finally have apache working again with
>the new 
>version of openssl 0.9.6j (couldn't get 0.9.7b working, but suspect it
>will 
>now; I'll try it another day).  Sadly it didn't solve my original
>problem.  
>Not that updating my openssl libraries was a waste of time or
>anything.  It 
>needed to be done anyway.  Thanks for bringing it to my attention
>Lars.  
>Somehow I missed the update notices.
>
>Any other suggestions as to what could be causing this?  Is anyone
>actually 
>using phpgw to change ldap passwords?  I suspect this is also why I
>wasn't 
>able to log in with any of the demo or default admin accounts I
>created 
>during setup.  Has anyone had success with these accounts?
>
>I'm starting to think my problem is related to how I
>compiled/configured 
>openldap.  I suspect that PAM doesn't use ldap to authenticate, but
>reads the 
>stored password and does it's own authentication.  This would explain
>why PAM 
>doesn't have a problem with the password, no matter how it's
>generated, but 
>LDAP does.  
>
>Thoughts?
>
>...Izzy
>
I'm not shure what you are doing, but ...

- I use LDAP for changig passwords. It works very well.

- In normal cases it is unimportant how the password is stored in the ldap
tree. PAM and phpGroupware are doing following:
The user enters a username and a password. The PAM/phpgw are searching the
ldap tree for uid=username. This search is done as admin are as anonymous
user. After the the dn is found, PAM/phpgw try to bind to the LDAP-Server
using the just found dn(uid=test,dc=test,dc=org) and the user supplied
password. If this succeds, the user supllied password is correct, if not,
the password is not correct(or no dn was found). So PAM/phpgw do never read
the password from the ldap server, they just try to authenticate.

Hope this help a little bit.

Cu