OpenLDAP Password Policy account state handling.

Mon Dec 12 10:44:40 EST 2016

Thanks Daniel,

>>Your configuration looks like this?
>
>       <entry key="ExpiredPassword">
>            <list>
>                <value>PASSWORD_EXPIRED</value>
>                <value>CHANGE_AFTER_RESET</value>
>            </list>
>        </entry>

Yes.  That is not working in the same way that the PASSWORD_EXPIRED code triggers…

>> Yes. You should see an AuthenticationWarningContext added to the
> AuthenticationContext. If you do, it's just a matter of getting the correct > flow to fire.

At this point, I am not really doing anything with the context tree directly.  This is part of the Password/LDAP authentication flow as the first factor of an MFA authn flow.  I was looking for configuration options within the ldap-authn-config.xml vs. writing MFA transiition logic to determine next sub-flow.

>> Don't get too hung up on the language, it just mirrors what is in the
> RFC[1]. These aren't errors in the strictest sense.

Well, I am just looking at the org.ldaptive.auth.AuthenticationResponse in the TRACE where it shows the accountError under the “account state” object, and I am wondering how that should play according to the IdP docs I am reading at[2]

Other puzzling behavior…
I have tuned the logging on org.shibboleth.idp to TRACE and org.springframework.webflow to DEBUG.  Under normal user account state, authentication at the IdP is working perfectly.  In this instance however, with the CHANGE_AFTER_RESET code, I am being returned to the login view with no messaging, and the tail of the log is not really telling me why:

2016-12-12 08:40:20,498 - DEBUG [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:142] - Profile Action ValidateUsernamePasswordAgainstLDAP: Attempting to authenticate user xxxxxxx
2016-12-12 08:40:20,545 - TRACE [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:150] - Profile Action ValidateUsernamePasswordAgainstLDAP: Authentication response [org.ldaptive.auth.AuthenticationResponse at 2095308681::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, ldapEntry=[dn=uid=xxxxxxxx,ou=people,dc=umt,dc=edu[]], accountState=[org.ldaptive.auth.ext.PasswordPolicyAccountState at 840856734::accountWarnings=null, accountErrors=[CHANGE_AFTER_RESET]], result=true, resultCode=SUCCESS, message=null, controls=[[org.ldaptive.control.PasswordPolicyControl at 1469520422::criticality=false, timeBeforeExpiration=0, graceAuthNsRemaining=0, error=CHANGE_AFTER_RESET]]]
2016-12-12 08:40:20,545 - INFO [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:152] - Profile Action ValidateUsernamePasswordAgainstLDAP: Login by 'xxxxxxxx' succeeded
2016-12-12 08:40:20,548 - DEBUG [net.shibboleth.idp.authn.AbstractValidationAction:341] - Profile Action ValidateUsernamePasswordAgainstLDAP: Adding custom Principal(s) defined on underlying flow descriptor
2016-12-12 08:40:20,554 - TRACE [net.shibboleth.idp.profile.support.ProfileRequestContextFlowExecutionListener:62] - Updating ProfileRequestContext in servlet request

That’s IT!  That is where the log stops and I have landed back on the login view.  Any other suggestions for logging that might help me troubleshoot this?

Thanks.
Josh

[1] - https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2
[2] - https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-HandlingaccountstatewithOpenLDAP

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Daniel Fisher
Sent: Sunday, December 11, 2016 10:14 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: OpenLDAP Password Policy account state handling.

On Fri, Dec 9, 2016 at 5:20 PM, O'Dowd, Josh <Josh.O'Dowd at mso.umt.edu<mailto:Josh.O'Dowd at mso.umt.edu>> wrote:
Hi,

We are trying to take advantage of an option in the OLDAP to force a user to change their password on next login.  We have successfully implemented this at the Directory but I am having trouble finding the best way to handle this at the IdP(v3.3.0).  I have tuned logging to TRACE the authentication response, see below:
TRACE [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:150] - Profile Action ValidateUsernamePasswordAgainstLDAP: Authentication response [org.ldaptive.auth.AuthenticationResponse at 1130903839::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, ldapEntry=[dn=uid=xxxxxxx,ou=people,dc=umt,dc=edu[]], accountState=[org.ldaptive.auth.ext.PasswordPolicyAccountState at 1392004071::accountWarnings=null, accountErrors=[CHANGE_AFTER_RESET]], result=true, resultCode=SUCCESS, message=null, controls=[[org.ldaptive.control.PasswordPolicyControl at 1346651430::criticality=false, timeBeforeExpiration=0, graceAuthNsRemaining=0, error=CHANGE_AFTER_RESET]]]
Notice the CHANGE_AFTER_RESET coming in as an accountError.

Don't get too hung up on the language, it just mirrors what is in the RFC[1]. These aren't errors in the strictest sense.

That being said I have tried mapping the error code into the ClassifiedMessageMap in conf/authn/password-authn-config.xml, to an event which I have added to the flows/authn/conditions/conditions-flow.xml as a transition to the expired-password sub-flow.

Your configuration looks like this?

        <entry key="ExpiredPassword">
            <list>
                <value>PASSWORD_EXPIRED</value>
                <value>CHANGE_AFTER_RESET</value>
            </list>
        </entry>

  That did not work.  Maybe because there is no exception when the authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS?

No. An exception always fires the AUTHN_EXCEPTION event.

Is there a provided method for the IdP to handle a PPolicy accountError in the ldaptive response when the authn result code happens to be ‘success’?

Yes. You should see an AuthenticationWarningContext added to the AuthenticationContext. If you do, it's just a matter of getting the correct flow to fire.

--Daniel Fisher

[1] https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161212/4b7e590e/attachment-0001.html>