OpenLDAP Password Policy account state handling.

[O'Dowd, Josh]

OK, I see what you are saying.  However the reason the account that just had successful bind authentication no longer has search operation permission(for attribute retrieval) is because regardless of the successful bind, there is an “accountError=CHANGE_AFTER_RESET” defining an accountState in the AuthenticationResponse.

Again notice the null accountState in the response to a normal state authentication(TRACE#1) vs. the accountState in the response to an account where pwdReset has been triggered(TRACE#2):

TRACE#1
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:150] - Profile Action ValidateUsernamePasswordAga
instLDAP: Authentication response [org.ldaptive.auth.AuthenticationResponse at 1328806434::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, lda
pEntry=[dn=uid={normal account id},ou=people,dc=umt,dc=edu[[umid[xxxxxxxxx]]], responseControls=null, messageId=-1], accountState=null, result=true, resultCod
e=SUCCESS, message=null, controls=[[org.ldaptive.control.PasswordPolicyControl at -350057371::criticality=false, timeBeforeExpiration=0, graceAuthNsRem
aining=0, error=null]]]

TRACE#2 [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:150] - Profile Action ValidateUsernamePasswordAgainstLDAP: Authentication response [org.ldaptive.auth.AuthenticationResponse at 203824680::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, ldapEntry=[dn=uid={forced password reset account id},ou=people,dc=umt,dc=edu[]], accountState=[org.ldaptive.auth.ext.PasswordPolicyAccountState at 1145598332::accountWarnings=null, accountErrors=[CHANGE_AFTER_RESET]], result=true, resultCode=SUCCESS, message=null, controls=[[org.ldaptive.control.PasswordPolicyControl at 587665572::criticality=false, timeBeforeExpiration=0, graceAuthNsRemaining=0, error=CHANGE_AFTER_RESET]]]

So back to my original issue, the IdP is not handling the CHANGE_AFTER_RESET account state.

Thanks for your time.

Josh

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

On Mon, Dec 12, 2016 at 3:34 PM, O'Dowd, Josh <Josh.O'Dowd at mso.umt.edu<mailto:Josh.O'Dowd at mso.umt.edu>> wrote:
Sure.  The following is DEBUG output from ldaptive packages.  I believe we are seeing a successful bind followed by a failed search operation.  The search operation appears to be restricted from the list of current allowed operations.  I believe this is due to the fact that the directory is enforcing a password-must-change policy that is active.  I am concluding that because search operations are not being restricted for accounts with normal account state.

That's what I expected. If you need that attribute for your flow, you'll have to wire up a connection factory to read it.
See https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AttributeRetrieval

--Daniel Fisher

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