On Tue, Jul 14, 2015 at 5:45 AM, Theisen, Lucas <[email protected]> wrote:
> In my application, I use the an ldap connection pool. The login page
> checks out a connection, binds as the user, returns the connection and then
> decides what to do based upon the response. Standard stuff… However, we
> allow a single grace authentication. The desired behavior is that they
> attempt to log in, we
>
see it is their one grace authentication and we redirect them to the change
> password page. However, the grace authentication was used up during the
> authentication process, so I can no longer bind as that user to get a
> connection to change the password. I COULD bind as admin to change the
> password but that would avoid all of the password policy settings. I could
> bind as admin, delete the grace authentication operation attribute, but
> what if there are more than one (a more generic situation). I could reset
> as admin to a temporary password, then bind as the user with that temporary
> password and reset to the supplied password. But I would then have to
> remember that temporary password for some unknown period in case their new
> password violated the policy in any way and they have to try again (or do
> the admin thing again). In this case I would be adding to the password
> history which would violate that rule in that we are not preserving the
> required number of passwords (effectively half or fewer).
>
>
>
> So the question really boils down to this: how do I reset a different
> users password when I cannot bind as that user, but I still need to follow
> that users password policy? Any suggestions? Right now I am leaning
> toward resetting with admin to a temporary value, deleting the most recent
> pwdHistory attribute, binding as the user, and attempting the reset. That
> should work, but is there a better way?
>
you can configure to allow at least >1 grace login attempts and the
redirect the user to change password
page when only one is remaining, but this again falls back to the same
situation if user doesn't utilize this
session and logs in again later, to handle this case bind as admin and set
the pwdMustChange attribute
server will allow the user to connect and modify his password (it forbids
him from performing anything
other than modify password, bind, unbind, abandon and StartTLS)
and now the interesting part, there is a bug* in checkPwdReset() due to
which this flag doesn't
work as expected. I will fix it.
* the not operator should not be used, I guess this is a side effect of
changing the isPwdPolicyDisabled()
to isPwdPolicyEnabled() but the ! operator was never removed.
P.S:- the use of a HashSet to hold all the DNs is also a bad idea, this was
probably overlooked before
committing, I will fix this.
>
>
> Thank You,
>
> Lucas Theisen
>
> [email protected]
>
>
>
--
Kiran Ayyagari
http://keydap.com
