If the ldap authentication does not throw that error back to CAS, LPPE will not be able to detect the error code. You'd likely need to augment the authN handler and do a direct lookup on the attribute that specifies the password behavior, and throw the exception yourself.
-Misagh From: Jeff Chapin [mailto:[email protected]] Sent: Tuesday, September 11, 2012 9:17 AM To: [email protected] Subject: [cas-user] LPPE configuration issues All, I am attempting to configure CAS 3.5.0 to operate in our environment and to fit our needs. We are currently using a modified version of 3.3.5, and it is working just fine. One of the requirements we have is the LPPE functionality. I am currently working to configure this functionality, but it appears something is missing -- and I think I see where it is missing. We use Oracle OID as our ldap source, and this seems to be working just fine for authentication, but it appears that LPPE is not triggering correctly. When I configure the warnDays, I can successfully get the warning to fire, display the proper page for the users informing them that their password will expire in the near future. The problem appears to be some of the ldap return codes that should trigger a password reset. When we administratively reset a password, we require that the user change their password on next login. Using ldapsearch, I can see this: $ ${ORACLE_HOME}/bin/ldapsearch -h ${HOST} -p ${PORT} -D cn=chapinj,cn=Users,${BASE_DN} -w ${PASSWORD} -b "${BASE_DN}" "cn=chapinj" ldap_search: DSA is unwilling to perform ldap_search: additional info: Password Policy Error :9009: GSL_PWDMUSTCHANGE_EXCP :Your Password has been reset; You must change your password before performing other operations. As you can see, ldapsearch recognizes that the password must change... but binding alone does not trigger that: $ ${ORACLE_HOME}/bin/ldapbind -h localhost -p 389 -D cn=chapinj,cn=Users,${BASE_DN} -w ${PASSWORD} bind successful Even updating lppe-configuration.xml with the proper return code of 9009 for mustChangePassword does not trigger the user to change the password. Looking at the logging, even after cranking up the logging for org.jasig.cas.adaptors.ldap I don't see anything in the logs indicating that CAS thinks this account has issues. I am *guessing* that since the bean is of class org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler, the issue is that we are looking only at a bind, which is not returning the error code. Is there any way to test this, or fix this? Thanks, Jeff -- Jeff Chapin, Assistant Systems/Applications Administrator ITS-IS, University of Northern Iowa Phone: 319-273-3162 Email: [email protected] -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
