ldaptive: add support for CHANGE_AFTER_RESET error.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configured the LDAP ppolicy on entry "cn=default,ou=policies,dc=vbox,dc=it" 
with pwdAllowUserChange: TRUE and pwdMustChange: TRUE.

2. Configured the "test" user ldap entry with pwdReset: TRUE

3. Configured a Shibboleth IDP, with an OpenLDAP installed, to use ldaptive 
1.0.1 following this doc: 
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass ("Handle 
User account status when using OpenLDAP Password Policy overlay")

4. Performed an IdP authentication for "test" user on a Shibboleth SP.

5. Authentication Success without changing the password on IDP, but 
Authentication Failed with a 'ldapsearch' command execute on IDP's terminal for 
the same "test" user.

What is the expected output? What do you see instead?
I think the IDP Authentication must fail when pwdReset for an user is TRUE.
Now an User can authenticate himself without consider the ppolicy rules.

What version of the product are you using? On what operating system?
ldaptive 1.0.1 on Ubuntu 12.04.3 LTS

Please provide any additional information below.
I think that ldaptive must be able to fail the authentications afterwards the 
"CHANGE_AFTER_RESET" error.

This feature can be help the IDP and LDAP admin to manage the new account 
creation without store their passwords.

I attach some LOGs that explain the problem.

P.S.: Excuse me for my bad english.

Original issue reported on code.google.com by marco.ma...@gmail.com on 24 Sep 2013 at 12:03

Attachments:

• Log4fisher.txt

[GoogleCodeExporter]

That attribute indicates that the next operation performed on the connection 
must be a password change.
However, it does not affect the initial bind.
From your logs:

> Sep 24 10:54:40 pupubuntu slapd[5207]: conn=1014 op=0 BIND 
dn="uid=test,ou=people,dc=vbox,dc=it" mech=SIMPLE ssf=0
> Sep 24 10:54:40 pupubuntu slapd[5207]: conn=1014 op=0 RESULT tag=97 err=0 
text=

err=0 means success

Since authentication only performs a single bind and then closes, you never get 
the error you are looking for.
From a practical sense, how could someone change their password if they cannot 
bind?

Your application logic will need to detect the CHANGE_AFTER_RESET and then take 
the user to your IDM password change interface.

Original comment by dfis...@gmail.com on 24 Sep 2013 at 3:26

• Changed state: Accepted

[GoogleCodeExporter]

Do you have any further comments or questions on this issue?

Original comment by dfis...@gmail.com on 30 Sep 2013 at 4:04

[GoogleCodeExporter]

Hello Fisher,

you're absolutely right, we implemented a solution which is able to solve our 
specific problem (yet it is not probably general purpose for all).

We extended the JASS module LdapLoginModule in order to verify the presence of 
the attribute CHANGE_AFTER_RESET.
In this case we deny access, and return to the login page a specific error 
message so that login.jsp can provide a proper message to the user.

This solution is good for use since our IDM password change interface do not 
use Java JAAS module to authenticate users. So it is perfectly good for us to 
deny access to users with CHANGE_AFTER_RESET.
To make our solution more general purpose, we may decide to change our 
implementation and permit user login to users with CHANGE_AFTER_RESET and raise 
"something" that could be used as a flag for the login.jsp to verify if the 
user is obliged to reset his password.

For the moment we put in place our solution (that blocks logins for users with 
CHANGE_AFTER_RESET flag in LDAP).

Regards,
Marco

Original comment by marco.ma...@gmail.com on 1 Oct 2013 at 7:58

[GoogleCodeExporter]

Thanks for the feedback Marco.

Original comment by dfis...@gmail.com on 1 Oct 2013 at 4:47

• Changed state: Invalid