On Tue, Jul 14, 2015 at 11:05 AM, Kiran Ayyagari <[email protected]> wrote:
> > > 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. > fixed both issues here https://issues.apache.org/jira/browse/DIRSERVER-2082 > >> >> Thank You, >> >> Lucas Theisen >> >> [email protected] >> >> >> > > > > -- > Kiran Ayyagari > http://keydap.com > -- Kiran Ayyagari http://keydap.com
