What occurs is that the user can indeed enter their old password and successfully authenticate, but upon the immediate subsequent login (sssd, ipa webui, etc), the user is presented with an error message that the account password is expired and is immediately necessary to change the password. This is -NOT- supposed to happen, per the IPA Development team. Once the user has 'migrated' and has entered their password info, it should be converted into the appropriate kerberos blob and consider the account -NOT Expired-

Gathered additional info:

Deleting the following attributes after the modrdn and prior to the 'migration page' password set, does NOT fix the expiration issue. The password still gets expired once the password is set.

• krbPasswordExpiration
• krbprincipalkey
• krbExtraData
• krbLastPwdChange

If krbPwdPolicyReference is also removed with the above, it DOES fix the problem, however, at that point, there is no expiration attribute or policy set and the user would not have any enforcement of password policy or expiration. After validating successful login, adding krbPwdPolicyReference back to the account immediately expires the password.

It seems that as long as krbPwdPolicyReference and/or krbPasswordExpiration is present during the migration mode 'password set', it will cause the expiration of the password immediately.

Finding based on Simo's notes: I used gdb on DS and found out the expiration was reset due to a false
positive in the script. The user password had been just changed to
krblastpwdchange check would kick in and make the server detect that too
little time was passed since last password change. This made the policy
check fail and the plugin resets the expiration time in this case.

I adjusted the script to avoid and it doesn't happen anymore.
This may have been what the user experienced too, and a min_complexity check
may also have triggered, though that would be odd, because he was trying
to migrate users with password that were passing the policy check when
set.

Now the question is whether failing the policy check this way should
happen in this case or not.

Should we entirely skip policy checks ? Should we add a "migration mode"
to policy check that will skip some checks but not others ?