krbpasswordexpiration for new users is depending on the used context. For client context this will be the time the user was created. With the server context this is date + 3 months.
1.$ ipa -e in_server=true user-add test1 --first=test --last=1 --random | grep expiration User password expiration: 20220426130554Z 2.$ ipa user-add test2 --first=test --last=2 --random | grep expiration User password expiration: 20220126130615Z
Using the client context a new user needs to change the password with the first login, but not with the server context.
Same behaviour.
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server 89-ds-base pki-ca krb5-server freeipa-server-4.9.4-1.fc34.x86_64 freeipa-client-4.9.4-1.fc34.x86_64 package ipa-server is not installed package ipa-client is not installed 389-ds-base-2.0.5-1.fc34.x86_64 pki-ca-10.10.6-1.fc34.noarch krb5-server-1.19.1-3.fc34.x86_64
This is an issue in ansible-freeipa (https://github.com/freeipa/ansible-freeipa/issues/745) as it is using the server context by default.
I've been unable to reproduce this. The passwords are marked as expired as expected.
I'm curious though, did you modify the password policy maxlife to 30 days?
I think it is a difference between LDAPI versus remote API access. In case of LDAPI access ipa -e in_server=true ... maps you to cn=Directory Manager and this gets you to the the following code in ipapwd_CheckPolicy:
ipa -e in_server=true ...
cn=Directory Manager
ipapwd_CheckPolicy
if (data->expireTime == 0) { if (pol.max_pwd_life > 0) { /* max_pwd_life = 0 => never expire * set expire time only when max_pwd_life > 0 */ data->expireTime = data->timeNow + pol.max_pwd_life; } }
data->expireTime is always 0, it seems, in ipapwd_chpwop()
data->expireTime
ipapwd_chpwop()
This is why I asked about the pwpolicy. 90 days is the default which seems the same as 3 months but asking for clarity.
The reproduction steps are misleading. This only happens if the user executing the command is root and in_server is true.
This is with the default policy. I reproduced it locally as root when investigating, so I am pretty sure this is what triggers it.
When I asked Thomas to create this ticket, we forgot to share our investigation details here, sorry for that!
Login to comment on this ticket.