I run Kerberos / LDAP authentication in a small network for years. Kerberos is held in LDAP, which in turn is replicated to another site. Machines at the second site authenticate to the replica, the old site authenticates to the original server. Recently, I added a couple of new user accounts.
On the original site, everything runs smoothly. The new users can login to the system without any issue.
On the second site using the replica kinit user also works without problems. However, login user claims that the password has expired and shall be changed, immediately. After changing the password, the user is logged in nicely.
Checking the settings on the replica KDC with kadmin.local everything looks nice to me:
kadmin.local: getprinc user
Principal: [email protected]
Expiration date: [never]
Last password change: Di Nov 22 21:06:35 CET 2022
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Di Nov 22 21:06:35 CET 2022 ([email protected])
Last successful authentication: Di Nov 22 21:19:27 CET 2022
Last failed authentication: So Nov 13 09:05:17 CET 2022
Failed password attempts: 0
Number of keys: 8
[ ... ]
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
So, neither passwords nor principals expire. And thus kinit works as expected:
root@client:~# kinit user
Password for [email protected]:
root@client:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
22.11.2022 21:25:17 23.11.2022 07:25:17 krbtgt/[email protected]
renew until 23.11.2022 21:25:11
However, login claims that the password is expired and must be changed:
root@ganesha:~# login user
Password:
Sie müssen Ihr Passwort sofort ändern (Passwortablauf).
Current Kerberos password:
Enter new Kerberos password:
Retype new Kerberos password:
Linux client 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Letzte Anmeldung: Dienstag, den 22. November 2022, 20:59:02 CET auf pts/5
user@client:~$
Following this login the principal's Last password change and Last modified are updated. Last successful authentication does not change. It doesn't change after successful kinit either. But it does change for successful login or kinit on the original clients. This may be another issue, but it happens just the same with the old users, which work perfectly on both sites. Using getprinc I cannot spot any difference between the old and the new users.
For login the following PAM settings should be effective for auth and account i.e., the defaults of a Debian installation:
auth optional pam_faildelay.so delay=3000000
auth requisite pam_nologin.so
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_group.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
I set up a new Bullseye client, which uses the original Kerberos and LDAP through VPN. It shows the same behaviour. I did some PAM debugging:
Jan 23 21:32:44 psyche login[2861]: pam_krb5(login:auth): user user authenticated as [email protected]
Jan 23 21:32:44 psyche login[2861]: pam_unix(login:account): expired password for user user (password aged)
Jan 23 21:32:53 psyche login[2861]: pam_krb5(login:chauthtok): user user changed Kerberos password
Jan 23 21:32:53 psyche login[2861]: pam_unix(login:session): session opened for user user(uid=10##) by admin(uid=0)
The old users, which work fine on all systems do not have an entry for (login:account) and hence no password change, of course. So, it doesn't seem to be related to replication. Even weirder that there are systems, where login works fine for those users. I checked /etc/pam.d/common-account and it is identical on both systems.
I appreciate any ideas on what to check.
Thanks for your help.
