IDP v3 - OpenLDAP password policy - forcing password reset

Emilio Penna emilio.penna at seciu.edu.uy
Wed May 20 17:09:56 EDT 2015


Scott, thanks for the explanation.

With respect to ppolicy control, I thinks there's some limitation in the
control handling in ValidateUsernamePasswordAgainstLDAP, let me explain:

As you said, in case of bind success (and accountState not null), the
message generated is:
String.format("%s:%s:%s", "ACCOUNT_WARNING", response.getResultCode(),
response.getMessage())

In bind failure, the message is
String.format("%s:%s:%s", state.getError(), response.getResultCode(),
response.getMessage())


The difference: if bind success, the state.getError() isn't
"propagated", so you "lose" it for catching any error code, and maybe
adapt flow accordingly mapping the error code to some event.

One example is the control for forcing password reset, in that case, the
bind success, and the control is informed by ldaptive in state.getError
(state.getError=CHANGE_AFTER_RESET in this case). The generated message
in this case, I guess that is something like
"ACCOUNT_WARNING:SUCCESS:null",  it don't have the errorCode
"CHANGE_AFTER_RESET", so you don't have the chance to detect it as
result of the action and adapt the flow.


Emilio


El 19/05/2015 a las 11:03 p.m., Cantor, Scott escribió:

>> Given the message generated in ValidateUsernamePasswordAgainstLDAP:189,
>> I think that I don't have the error code to map/catch in 
>> password-auth-config (or somewhere else), for trying to change the flow 
>> to deny user login...
> 
> Well, I think the main operation there is the bind. If that succeeds, I 
> don't think anything you put into the map of messages is going to make it 
> actually fail, but the ACCOUNT_WARNING string looks like it's just part of 
> the default message being built:
> 
> String.format("%s:%s:%s", "ACCOUNT_WARNING", response.getResultCode(),
> 	response.getMessage())
> 
> That may be too aggresively mapped to ExpiringPassword because it looks 
> like that will happen no matter what the Code or Message values are. I 
> don't know if that's intentional or not, but the mappings are obviously 
> not anything we care about, they should be whatever you need.
> 


More information about the users mailing list