To add extra information: the IPA instance which I am trying to migrate from was installed at an older version but currently running at 4.2.0 and I'm not seeing this problem in this older instance.

I found a sort of "work around" for this issue. It turns out the cause is that the default password-length polcity was more restrictive than the passwords of some users migrated into IPA and so the {{{/ipa/migration}}} activity failed due to the password being rejcted by the password policy.

I still see this as an issue, because there was no indication on the UI side that this was correct behavior (based on the new IPA configuration) rather than some arcane internal failure. If possible, it would be useful to alert users migrating or changing passwords if their password does not meet policy.

Replying to [comment:2 bsiposrkf]:

I still see this as an issue, because there was no indication on the UI side that this was correct behavior (based on the new IPA configuration) rather than some arcane internal failure. If possible, it would be useful to alert users migrating or changing passwords if their password does not meet policy.

I do not think it is possible to detect whether the password is meeting the policy or not. The check is performed once when password is being set and available in clear. IPA stores hashes there is no way to get the original password. It would be interesting to see the migration logs. I suspect that the might be some logic to check and match password policies. It would be interesting to inspect this area and potentially improve. If you can provide logs would be great.

In general this case should be easy to reproduce:
1. Install IPA
2. Create couple users with passwords
3. Install another IPA
4. Change password policies to be more restrictive than the first one
5. Run migrate-ds
6. Try to change password/authenticate with the migrated user

Maybe it should be a part of the migration test suit.

If it is about error message on password change form then it should be fixed in #5567 and other messages are also fixed in #5077 and #5076

5567 should report also that password which is about to set doesn't meet password policy. #5567 was released in RHEL 7.2 update ipa-4.2.0-15.el7_2.8

Ah sorry, my comment was about password reset page in login part of Web UI. Password migration page doesn't show this error message.

I'm not sure if we will be able to detect it though there as mentioned in comment 3.

This may be addressed then. My major problem was that the migration seemed to succeed, which redirected me to the password reset page (presumably because the old password did not comply with new policy) but I didn't understand why. Further, when attempting to reset password the web form seemed to "do nothing" in that I entered (password) text, clicked the reset button, and the text simply went away while the form stayed up and displayed no new information.

Even if there was some positive indication of why I was being shown the reset form I would have at least understood. Even speculative text such as "Your password may not be acceptable under current policy, see IPA admin for assistance." Anything would be better than the lack of info that I ran into.

Replying to [comment:6 bsiposrkf]:

This may be addressed then. My major problem was that the migration seemed to succeed, which redirected me to the password reset page (presumably because the old password did not comply with new policy) but I didn't understand why. Further, when attempting to reset password the web form seemed to "do nothing" in that I entered (password) text, clicked the reset button, and the text simply went away while the form stayed up and displayed no new information.

Even if there was some positive indication of why I was being shown the reset form I would have at least understood. Even speculative text such as "Your password may not be acceptable under current policy, see IPA admin for assistance." Anything would be better than the lack of info that I ran into.

Sure, we just need to understand the sequence and duplicate the experience and see it for ourselves. Then we will be able to internalize and figure our what can be done to make things better. Your comment above is really helpful. We need to try to reproduce it following this.

Replying to [comment:6 bsiposrkf]:

This may be addressed then. My major problem was that the migration seemed to succeed, which redirected me to the password reset page (presumably because the old password did not comply with new policy) but I didn't understand why.

The password reset in step 4 was done by an administrator? If so then password was marked as expired and then it was definitely solved by #5076

Further, when attempting to reset password the web form seemed to "do nothing" in that I entered (password) text, clicked the reset button, and the text simply went away while the form stayed up and displayed no new information.

Should be fixed by #5567

Even if there was some positive indication of why I was being shown the reset form I would have at least understood. Even speculative text such as "Your password may not be acceptable under current policy, see IPA admin for assistance." Anything would be better than the lack of info that I ran into.

I think that we can close the ticket provided that my assumptions above are correct.

The apparent reset of step !#4 was not a manual operation by an admin, but appeared to be a side effect of the migrated password not being valid within the new password policy and the IPA server forcing a reset. The displayed page was an IPA password reset page, which was identical to the one displayed after an admin resets a user password.

The workflow was retested find findings

After migrating users from IPA 4.2.4 to fIPA 4.2.4 where was set more restrictive password policy, it is neccessary to change password - current password is set as expired (probably because it does not meet the policy). Changing password works correctly, even warnings that user entered too short password are shown.

Therefore closing as fixed.