pwm login : Old password still valids after password change

[bofh.jr]

Hi,
first : thanks for this software ...

During my tests I noticed that old passwords are still valid after
password change.
It seems related to some session timeout as this behavior disappear if
tomcat is restarted.

Is it a bug or an intended feature ?

J.-M.

Use case:
User logs with ('user','oldpassword') as (username password). :->
success
User change its password with 'newpassword' -> success
User logout -> success
User reconnect to pwm login page -> success
User try to log with ('user', 'oldpassword') -> success
Context:
pwm 1.5.2
openldap 2.4.12
tomcat 6.0.18

[Jason Rivard]

Hi,

This is not the intended behavior.  I haven't seen this behavior before, but I haven't done much testing with openLDAP personally.  

Any authentication to PWM should result in an ldap bind to the directory, pwm shouldn't be caching the old password after a successful password change for any reason.

Can you set the log level to TRACE and see if it provides any clues?  Post the log here if your not sure what is happening.

-jason

--
You received this message because you are subscribed to the Google Groups "pwm-general" group.
To post to this group, send email to pwm-g...@googlegroups.com.
To unsubscribe from this group, send email to pwm-general...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pwm-general?hl=en.

[bofh.jr]

Hi,

I set up some unit tests (using jwebunit) :
1) change password,
2) try to bind directly with ldap with the old password (fail
expected)
3) try to re-log in pwm with the old password. (fail expected).

As expected direct bind to ldap fails in step 2 but pwm is stil
accepting the old password in step 3:).

See below for a trace of step 3 where the successfull bind took only
0ms (average is around 5ms for other ldap operations).

I don't think the problem is openldap related , according to the trace
I think that some caching is going on through the JNDIProviderImpl
that chai uses.

J.-M.



============================ Trace for the second attempts
========================================
011-01-26 22:02:00, TRACE, pwm.AuthenticationFilter, {3b} permitting
unauthenticated request of login page [127.0.0.1/localhost]
2011-01-26 22:02:00, TRACE, pwm.UserStatusHelper, {3b} username
appears to be a DN; skipping username search [127.0.0.1/localhost]
2011-01-26 22:02:00, TRACE, pwm.AuthenticationFilter, {3b} attempting
authentication using ldap BIND [127.0.0.1/localhost]
2011-01-26 22:02:00, TRACE, pwm.SessionManager, {3b} opened new ldap
connection for null (0ms) [127.0.0.1/localhost]
2011-01-26 22:02:00, TRACE, pwm.Helper, creating new chai provider
using config of ChaiConfiguration: locked=false settings:
{chai.bind.URLs=ldap://XXXXXXXXX:389,, chai.bind.dn=uid=XXXXXXX,
chai.bind.password=**stripped**, chai.cache.enable=false,
chai.cache.maximumSize=128, chai.cache.maximumAge=1000,
chai.statistics.enable=true, chai.watchdog.enable=true,
chai.watchdog.operationTimeout=60000, chai.watchdog.idleTimeout=60302,
chai.connection.watchdog.frequency=60000,
chai.connection.promiscuousSSL=false, chai.wireDebug.enable=false,
chai.failover.enable=true, chai.failover.failBackTime=90000,
chai.failover.connectRetries=4, chai.ldap.dereferenceAliases=never,
chai.ldap.ldapTimeout=5000,
chai.provider.implementation=com.novell.ldapchai.provider.JNDIProviderImpl,
chai.edirectory.enableNMAS=true,
chai.provider.extendedOperation.failureCache=true,
chai.provider.readonly=false,
chai.default.identityAttributes=cn,uid,givenName,initials,sn,mail,telephoneNumber,workforceID,
chai.vendor.default=}
2011-01-26 22:02:00, TRACE, provider.JNDIProviderImpl, bind successful
as uid=XXXXXXX (0ms)

On 26 jan, 02:08, Jason Rivard <jriv...@gmail.com> wrote:
> Hi,
>
> This is not the intended behavior.  I haven't seen this behavior before, but
> I haven't done much testing with openLDAP personally.
>
> Any authentication to PWM should result in an ldap bind to the directory,
> pwm shouldn't be caching the old password after a successful password change
> for any reason.
>
> Can you set the log level to TRACE and see if it provides any clues?  Post
> the log here if your not sure what is happening.
>
> -jason
>

> > pwm-general...@googlegroups.com<pwm-general%2Bunsu...@googlegroups.com>
> > .

[Jason Rivard]

I'm still not sure what to say. I can't reproduce this on my setup
using eDirectory or AD instead of openLDAP. I simply haven't had a
chance to set this up with openLDAP yet for testing, but it's on my
list of things to do... Others have used openldap with pwm and I
haven't heard this reported...

There isn't anything out of the ordinary about the log. Unless you've
modified the code in some way, there is no caching happening at the
Chai layer. At least not intentionally....

> > > pwm-general...@googlegroups.com<pwm-general%2Bunsubscribe@googlegr oups.com>

[Menno Pieters]

Try a nightly built :-)

On Fri, Apr 24, 2015 at 2:07 AM, Double Think <doublethi...@gmail.com> wrote:

Hello

I've setup PWM 1.7.1 with AD 2003 and I can confirm that I'm also seeing this behaviour....

Given this issue is 4yrs old, and I have replicated it, what are our available options ?

What now ?

--
You received this message because you are subscribed to the Google Groups "pwm-general" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pwm-general...@googlegroups.com.

To post to this group, send email to pwm-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/6d13dff4-3079-42c1-8ee4-75868646e4d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Double Think]

Hi

After some investigation I discovered it's not a PWM issue but a AD artifact.

AD seems to allow the old password to authenticate for a defined amount of time at which point the old password denied.