Since in Kerberos V5 are used 32-bit unix timestamps, setting
maxlife in pwpolicy to values such as 9999 days would cause
integer overflow in krbPasswordExpiration attribute.
This would result into unpredictable behaviour such as users
not being able to log in after password expiration if password
policy was changed (#3114) or new users not being able to log
in at all (#3312).
The timestamp value is truncated to Jan 1, 2038 in ipa-kdc driver.
https://fedorahosted.org/freeipa/ticket/3312https://fedorahosted.org/freeipa/ticket/3114
Some of these are not real defects, because we are guaranteed to have valid
context in some functions, and checks are not necessary.
I added the checks anyway in order to silence Coverity on these issues.
One meleak on error condition was fixed in
daemons/ipa-kdb/ipa_kdb_pwdpolicy.c
Silence errors in ipa-client/ipa-getkeytab.c, the code looks wrong, but it is
actually fine as we count before hand so we never actually use the wrong value
that is computed on the last pass when p == 0
Fixes: https://fedorahosted.org/freeipa/ticket/2488
We were not searching for objectclass so the test to se if a user had the
posixAccount attribute was failing and the user was not marked as ipa_user.
This in turn caused us to not synchronize legacy hashes by not trying to store
the userPassword attribute.
Fixes: https://fedorahosted.org/freeipa/ticket/1820
Expiration time should be enforced as per policy only for users and only when a
password change occurs, ina ll other cases we should just let kadmin decide
whther it is going to set a password expiration time or just leave it empty.
In general service tickts have strong random passwords so they do not need a
password policy or expiration at all.
https://fedorahosted.org/freeipa/ticket/1839
