Okay, for those who are on the edge of their seats waiting to find out
the answer whether an upgrade fixed the issue I was experiencing... The
answer is a definite yes - for now! We still need to test some more
scenarios, but this still begs the question as to why I was seeing this
behavior in version 1.0.2. At least I am able to move ahead, now.
And, to answer your question below about binding with the new password
using Studio: No, I was not able to bind with the new password using
Studio or the webapp - even though I can see the new password value (for
the user whose password was changed) when logged in as the admin user,
so it appears this is an issue inside the (version 1.0.2) LDAP server.
HTH,
Rich
Emmanuel Lecharny wrote:
Rich Remington wrote:
I am using the standalone server. BTW, the password is seen right
after the change AND after a reboot of the standalone server, so the
password change is permanent - even if not written to disk
immediately. The problem still remains that between the time it is
changed by the webapp and before the reboot of the LDAP server,
webapp attempts to bind with the new password fail, but binding with
the old password works.
And you can bind with the new password using Studio ?
Weird...
I will upgrade to 1.5.4 in the meantime and let you know if this is
fixed. Are there any config migration tools and/or tips? Will LDIF
export/import just work?
1.5.4 has been released, and is available. Export and re-import using
LDIF, there is no other way atm. (be carefull : if you have changed
the schema, then you have to modify it on the new version)
