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 > <http://www.iland.com/> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Thanks for the suggestions, Marek. I think that overriding the LDAPFederationProvider will be the way to go. The problem that I am seeing which is preventing me from doing this in just the authenticator is that I have no way to authenticate the user in order to allow them to update the password unless I also make changes to the LDAPFederationProvider. As you mentioned, the LDAPFederationProvider simply returns false from the validCredentials method when the pwdLastSet attribute equals 0. If I don’t authenticate the user with their current password beforehand, it would allow anyone with the username to change the user’s password. Or am I overlooking something? Thanks, Cory Snyder software engineer USA +1.419.731.3479 UK +44.20.7096.0149 iland.com <http://www.iland.com/> > On Nov 10, 2015, at 8:32 AM, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > Btv. I think it should be possible to do it with authenticator as > well, but you need to configure authentication flow correctly. You > will have your custom authenticator, which will check pwdLastSet and > if it's 0, it will put the requiredAction on user and at the same > time it will set user as authenticated. It would need to be > ALTERNATIVE authenticator used in browser flow before "Forms" > authenticator (Forms authenticator is that one which displays login > form with username/password and optionally OTP). That way, forms > authenticator won't be used and username/password form won't be > displayed. It will go directly to requiredActions and user will be > asked to update password. > > Marek > > 0On 10/11/15 14:27, Marek Posolda wrote: >> 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 >>> <http://www.iland.com/> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >