I agree we need some way to address this. Active Directory is widely used and more people asked for that . I've put the comment to https://issues.jboss.org/browse/KEYCLOAK-1744 with possible solution, but it may need changes in UserFederationProvider interface, so the federationProvider is able to propagate the cause why password validation failed (password is expired, user is disabled, or just invalid password was used etc...).

As a temporary workaround, you can subclass LDAPFederationProvider and do something on your own. You can override LDAPFederationProvider.validPassword and add updatePassword on User when you detect that reason of password validation failure is expired password.

Marek

On 09/11/15 20:32, Cory Snyder wrote:

Hey guys,

Following up on this conversation that took place a couple of months back: http://lists.jboss.org/pipermail/keycloak-dev/2015-September/005286.html. I just had a chance to try the proposed approach of implementing a custom authentication provider that checks the pwdLastSet attribute and sets the update password required action. I believe that this may not be quite as easy as was suggested due to the fact that authentication fails with the default LDAP Federation Provider before a custom execution in the login flow has a chance to check the attribute and set the required action. It seems I would need to implement a custom LDAP Federation Provider that considers authentication successful when the exception referenced in https://issues.jboss.org/browse/KEYCLOAK-1744 is thrown, but also add the required action for updating the password. Is there an easy way to do that or something that I’m missing? Otherwise, I’d be willing to work on a contribution for this issue if you’re willing to have logic that is specific to AD?

Thanks,

Cory Snyder

software engineer

USA +1.419.731.3479 UK +44.20.7096.0149 iland.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev