"could not obtain user info" after 5.2 update

UCS - Univention Corporate Server
1

We upgrade from 5.0 to 5.2 recently and ever since then we get repeatedly this error message from syslog:

Jun 10 11:49:23 backup-node unix_chkpwd[10088]: check pass; user unknown
Jun 10 11:49:23 backup-node unix_chkpwd[10088]: password check failed for user (primary-node$)
Jun 10 11:49:23 backup-node sshd[10087]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.9  user=primary-node$
Jun 10 11:49:23 backup-node sshd[10087]: pam_krb5(sshd:auth): user primary-node$ authenticated as primary-node$@EXAMPLE.ORG
Jun 10 11:49:23 backup-node unix_chkpwd[10089]: could not obtain user info (primary-node$)
Jun 10 11:49:23 backup-node sshd[10085]: Accepted keyboard-interactive/pam for primary-node$ from 192.168.0.9 port 34074 ssh2
Jun 10 11:49:23 backup-node sshd[10085]: pam_unix(sshd:session): session opened for user primary-node$(uid=2001) by (uid=0)
Jun 10 11:49:23 backup-node sshd[10085]: pam_unix(sshd:session): session closed for user primary-node$

At first glance, it doesn’t look like anything critical, PAM just tries to auth with local user, which doesn’t exist, and then uses kerberos?

We can just ignore this, right?

2

Yes, this can typically be ignored. The log records PAM trying to authenticate the primary-node$ user locally (via pam_unix first), fail because the user does not exist on the local system, and then successfully authenticate, using Kerberos (pam_krb5) later. This is normal in environments that use Active Directory (or similar systems using host based trust and kerberos auth). It is not critical, but if the noise bothers you, you may suppress or redirect these logs via PAM or syslog configuration. Just be careful not to hide genuine auth issues in the meantime.

1 Like
3

Thanks for the reply! :slightly_smiling_face:

In this case, I’ll suppress the message through syslog.