directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: pwdHistory not validating properly (in custom server)
Date Tue, 30 Apr 2013 13:23:05 GMT
Le 4/30/13 2:54 PM, Patricio Demitrio a écrit :
> I will check that code now. In the meantime here's the stacktrace. 

Looking at the first stackTrace you provided :

invalid reuse of password present in password history
at
org.apache.directory.server.core.authn.AuthenticationInterceptor.modify(AuthenticationInterceptor.java:956)

...

The code is :

                    for ( Value<?> value : pwdHistoryAt )
                    {
                        PasswordHistory pwdh = new PasswordHistory( Strings.utf8ToString(
value.getBytes() ) );

                        boolean matched = Arrays.equals( newPassword, pwdh.getPassword() );

                        if ( matched )
                        {
                            if ( isPPolicyReqCtrlPresent )
                            {
                                PasswordPolicyDecorator responseControl =
                                    new PasswordPolicyDecorator( directoryService.getLdapCodecService(),
true );
                                responseControl.getResponse().setPasswordPolicyError(
                                    PasswordPolicyErrorEnum.PASSWORD_IN_HISTORY );
                                modifyContext.addResponseControl( responseControl );
                            }

                            throw new LdapOperationException( ResultCodeEnum.CONSTRAINT_VIOLATION,
                                "invalid reuse of password present in password history" );
                        }


and you get an exception because the password you are providing is already present in the
passwordHistory (which may store many different password).

What the code does is quite simple :
- we grab the 'pwdHistory' AttributeType of the entry
- we iterate on all its values
- if one of them is equal to the new password, then we throw an exception

So either you set the new password in the entry *before* this test is
done (and as it's a new password, it will also be present in the
pwdHistory AT), or you are trying to set a password that has already
been set.

I think your problem is that you do the check too late.

Can you provide the code of your interceptor ?


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Mime
View raw message