New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PasswordPolicyControl ambiguous graceAuthNsRemaining #131
Comments
If it helps, the apache api handles this case in two ways:
If you have a path you want to take I can try to code something up... |
I reviewed the behavior against OpenLDAP ppolicy and got the following results:
So the behavior is certainly different than ApacheDS. |
Change default warning values from 0 to -1. See #131. Update integration test.
Pushed a potential fix to 1.2.4-SNAPSHOT |
Working on getting trace data, I'll see if I can get that today. We swapped out for using org.apache in our code for now so I have to swap it back. My reading of 8.1.2.3.2 in the rfc leads me to think the final error should be invalid credentials, with the password policy also showing password expired as informational aside. But the invalid credentials is much more important to see, because in that state it is not possible for the user to change the password anymore, so seeing the expired password message is more of a red herring because it can't be fixed like a normal expired password. After grace auths are used, only a password reset is allowed to change the password, not a modify using the existing password (since the user can no longer bind to perform the password change). |
Here are the results of the trace:
|
Reading through your commit I think it'll mitigate the issue. A consumer can use the -1 values to determine if values were specified by the server. Though it feels a little wrong to have to test for a special value. Maybe methods like isTimeBeforeExpirationPresent() and isGraceAuthsRemainingPresent()? That feels weird too, though. Ideally you'd hand back nullable objects, but that would break existing stuff. I guess I don't really have good solution, so maybe the special -1 is ideal in this case. |
Thanks for the report and test data, that should close this out. |
The PasswordPolicyControl implementation defaults graceAuthNsRemaining to zero.
Per the RFC, zero is a valid value and could be returned by the server.
The client has no way to determine if the server sent the value zero or no value at all.
See https://groups.google.com/forum/#!topic/ldaptive/nzj62B_Z2js
The text was updated successfully, but these errors were encountered: