I'm running a NIS/YP setup for login credentials using a Debian 12 server. I have a few dozen clients running Ubuntu 24.04. Most users are using either the default GNOME although a few are running XFCE. Since a few days the XFCE users are having problems unlocking the screen after the screensaver (lock screen) switched on. When typing the password, it is consistently rejected as being the wrong password (but it's not). That is, users are locked out once the screen locker has been switched on. Choosing switch user and trying to login again as the same user also fails.
The problem is reproducible across multiple clients, multiple users (including a newly created account on the NIS server) and is not due to the wrong password. Indeed, when switching to another TTY, the user can still login. Similarly, logging in on the client using SSH works just fine. Additionally, when these users login using the default Ubuntu GNOME, unlocking the screen works like usual. It seems to be confined to xfce. The hosts are not running lightdm and not using light-locker. It's the default xfce4 screensaver.
To further probe this I tried the same thing using a newly created local account. In this case unlocking the screen works just fine. My conclusion therefore is that it is related to the combination of XFCE4, Ubuntu 24, and NIS/YP.
When running journalctl -f in a parallel SSH session while trying to unlock the screen I get the following
Sep 25 17:04:17 <hostname> unix_chkpwd[3564]: check pass; user unknown
Sep 25 17:04:17 <hostname> unix_chkpwd[3564]: password check failed for user (<username>)
Sep 25 17:04:17 <hostname> xfce4-screensaver-dialog[3454]: pam_unix(xfce4-screensaver:auth): authentication failure; logname=<username> uid=1071 euid=1071 tty=:1.0 ruser= rhost= user=<username>
where I've replaced the host and user names by <hostname> and <username>, respectively. I've tried googling this but get fairly old results and nothing that seems relevant to my
setup.
Any suggestions how to pursue?
Edit: I tried to trace this down further and checked automatic package upgrades. The Ubuntu machines are running unattended-upgrades and when I try to narrow it down the following updates seem to have occurred before this problem started occurring:
Start-Date: 2025-09-24 06:13:30
Commandline: /usr/bin/unattended-upgrade
Upgrade: linux-tools-common:amd64 (6.8.0-83.83, 6.8.0-84.84), linux-libc-dev:amd64 (6.8.0-83.83, 6.8.0-84.84)
End-Date: 2025-09-24 06:13:32
Start-Date: 2025-09-24 06:13:34
Commandline: /usr/bin/unattended-upgrade
Upgrade: libpam-runtime:amd64 (1.5.3-5ubuntu5.4, 1.5.3-5ubuntu5.5), libpam-modules:amd64 (1.5.3-5ubuntu5.4, 1.5.3-5ubuntu5.5), libpam-modules-bin:amd64 (1.5.3-5ubuntu5.4, 1.5.3-5ubuntu5.5), libpam0g:amd64 (1.5.3-5ubuntu5.4, 1.5.3-5ubuntu5.5)
End-Date: 2025-09-24 06:13:36
Start-Date: 2025-09-24 06:13:38
Commandline: /usr/bin/unattended-upgrade
Upgrade: libc6:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), locales:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), libc-dev-bin:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), libc-bin:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), libc-devtools:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), libc6-dbg:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), libc6-dev:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6), nscd:amd64 (2.39-0ubuntu8.5, 2.39-0ubuntu8.6)
End-Date: 2025-09-24 06:13:54
Start-Date: 2025-09-24 06:13:56
Commandline: /usr/bin/unattended-upgrade
Upgrade: python3-pip-whl:amd64 (24.0+dfsg-1ubuntu1.2, 24.0+dfsg-1ubuntu1.3), python3-pip:amd64 (24.0+dfsg-1ubuntu1.2, 24.0+dfsg-1ubuntu1.3)
End-Date: 2025-09-24 06:13:58
My best guess is that it's related to the libpam-updates, but I still don't know how to proceed here. Any suggestions would be appreciated.