I think this is expected behavior. All passwords set by an administrator are marked as expired. There is no override.

This is the issue
# date
Tue 30 Jul 2019 01:16:02 AM CDT

////Password expiration set explicilty works fine///
//Expire password at 2019/30/07 11:51:10
# ipa user-mod password-expiration-user --password-expiration 20190730115110Z
Modified user "password-expiration-user"
User login: password-expiration-user
First name: password
Last name: expiration-user
Home directory: /home/password-expiration-user
Login shell: /bin/sh
Principal name: password-expiration-user@ATEST.COM
Principal alias: password-expiration-user@ATEST.COM
User password expiration: 20190730115110Z <<<<<<<<<<<
Email address: password-expiration-user@atest.com
UID: 760400005
GID: 760400005
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True

////Password expiration set while setting password does not////
//Expire password at 2019/30/07 11:55:20
# ipa user-mod password-expiration-user --password --password-expiration 20190730115520Z
Password:
Enter Password again to verify:
Modified user "password-expiration-user"
User login: password-expiration-user
First name: password
Last name: expiration-user
Home directory: /home/password-expiration-user
Login shell: /bin/sh
Principal name: password-expiration-user@ATEST.COM
Principal alias: password-expiration-user@ATEST.COM
User password expiration: 20190730061714Z <<<<<<<<<<
Email address: password-expiration-user@atest.com
UID: 760400005
GID: 760400005
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True

Hi!
Any plans to fix or figure out that behaviour?

Cheers,
GT
We met on with that on freeIPA 4.5.4

I'm doubtful that we would address this.

I'm guessing it's an order of operations issue. The new user entry is written with an unhashed password and a password expiration date. The LDAP password plugin kicks in and generates the Kerberos keys an writes an expiration date.

This is the desired behavior. The workaround is to do it as two steps. Add the user, then set the date.

Leaving it open for now in case others have different opinions.

Same opinion as @rcritten, would advise to apply the workaround.

I think an advise is not sufficient for this. In my opinion the mod command should fail if password and password-expiration is given as the password-expiration date is simply not applied.

This is a big issue for us, as we have around 750 medical devices on the globe using sftp to transfer files. The users are created by script and the password is randomly generated. The devices can not handle password expirations and in sum it's work for some month to replace the passwords on the devices. So this is a real stopper for us.

@rnick do you ever want passwords to expire in this case? If so then a custom password policy with an extended maxlife is something to consider.