Authentication failure on CentOS Stream 8

[Alan Orth]

Dear list,

I am using SSSD 2.6.2 on CentOS Stream 8 to authenticate against a 389
directory server over LDAP. Both `getent` and `id` are working, as is
key-based SSH. Anything requiring a password doesn't work: like ssh and
sudo. The 389 directory server is running on CentOS 7 and other CentOS 7
clients can authenticate and sudo just fine (they were set up with
authconfig).

Here is an excerpt from /var/log/secure while trying to SSH with a password
and sudo after logging in with an SSH key:

May 19 14:49:16 server05 sshd[79520]: Connection from x.x.x.x port 58272 on
x.x.x.x port 22
May 19 14:49:19 server05 sshd[79520]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=myuser
May 19 14:49:21 server05 sshd[79520]: Failed password for myuser from
x.x.x.x port 58272 ssh2
May 19 14:53:00 server05 sudo[122435]: pam_unix(sudo:auth): authentication
failure; logname=myuser uid=751 euid=0 tty=/dev/pts/4 ruser=myuser rhost=
 user=myuser
May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): conversation
failed
May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): auth could not
identify password for [myuser]
May 19 14:53:07 server05 sudo[122435]:   myuser : 1 incorrect password
attempt ; TTY=pts/4 ; PWD=/home/myuser ; USER=root ; COMMAND=/bin/su -

I have followed the SSSD troubleshooting guide¹ and it seems there is
something wrong with pam_sss, but I can't figure it out. I used `authselect
select sssd` to configure PAM and have not modified any settings. The
configuration seems to be valid:

# authselect check
Current configuration is valid.

And here is the auth part of the PAM system-auth stack:

# grep '^auth' /etc/pam.d/system-auth
auth        required                                     pam_env.so
auth        required                                     pam_faildelay.so
delay=2000000
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so
isregular
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so
isregular
auth        sufficient                                   pam_sss.so
forward_pass
auth        required                                     pam_deny.so

Enabling `debug_level = 6` for sssd, domain/default, nss, and pam has not
helped me find anything out of place.

Does anyone have an idea of what to look for in the logs, or what else I
can try?

Thank you,

¹ https://sssd.io/troubleshooting/basics.html
-- 
Alan Orth
alan.orth(a)gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch

[Alan Orth]

I just realized something: the user 'myuser' has a UID less than 1000 and
for years my CentOS 7 deployment scripts have hacked the minimum UID from
the default of 1000 to 500 in /etc/pam.d/system-auth-ac and
/etc/pam.d/password-auth-ac. I totally forgot about this hack buried deep
in my ansible scripts. :P

I found a very interesting thread on bugzilla about this that resulted in
the pam_usertype module being written¹. :) The pam_usertype man page says
that the distinction between "regular" and "system" users is based on
the
definitions in /etc/login.defs. After modifying those I was able to login
via SSH and sudo. \o/

Cheers,

¹ https://bugzilla.redhat.com/show_bug.cgi?id=1745136

On Thu, May 19, 2022 at 3:24 PM Alan Orth <alan.orth(a)gmail.com&gt; wrote:

>  Dear list,
>
>  I am using SSSD 2.6.2 on CentOS Stream 8 to authenticate against a 389
>  directory server over LDAP. Both `getent` and `id` are working, as is
>  key-based SSH. Anything requiring a password doesn't work: like ssh and
>  sudo. The 389 directory server is running on CentOS 7 and other CentOS 7
>  clients can authenticate and sudo just fine (they were set up with
>  authconfig).
>
>  Here is an excerpt from /var/log/secure while trying to SSH with a
>  password and sudo after logging in with an SSH key:
>
>  May 19 14:49:16 server05 sshd[79520]: Connection from x.x.x.x port 58272
>  on x.x.x.x port 22
>  May 19 14:49:19 server05 sshd[79520]: pam_unix(sshd:auth): authentication
>  failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=myuser
>  May 19 14:49:21 server05 sshd[79520]: Failed password for myuser from
>  x.x.x.x port 58272 ssh2
>  May 19 14:53:00 server05 sudo[122435]: pam_unix(sudo:auth): authentication
>  failure; logname=myuser uid=751 euid=0 tty=/dev/pts/4 ruser=myuser rhost=
>   user=myuser
>  May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): conversation
>  failed
>  May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): auth could not
>  identify password for [myuser]
>  May 19 14:53:07 server05 sudo[122435]:   myuser : 1 incorrect password
>  attempt ; TTY=pts/4 ; PWD=/home/myuser ; USER=root ; COMMAND=/bin/su -
>
>  I have followed the SSSD troubleshooting guide¹ and it seems there is
>  something wrong with pam_sss, but I can't figure it out. I used `authselect
>  select sssd` to configure PAM and have not modified any settings. The
>  configuration seems to be valid:
>
>  # authselect check
>  Current configuration is valid.
>
>  And here is the auth part of the PAM system-auth stack:
>
>  # grep '^auth' /etc/pam.d/system-auth
>  auth        required                                     pam_env.so
>  auth        required                                     pam_faildelay.so
>  delay=2000000
>  auth        [default=1 ignore=ignore success=ok]         pam_usertype.so
>  isregular
>  auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
>  auth        sufficient                                   pam_unix.so nullok
>  auth        [default=1 ignore=ignore success=ok]         pam_usertype.so
>  isregular
>  auth        sufficient                                   pam_sss.so
>  forward_pass
>  auth        required                                     pam_deny.so
>
>  Enabling `debug_level = 6` for sssd, domain/default, nss, and pam has not
>  helped me find anything out of place.
>
>  Does anyone have an idea of what to look for in the logs, or what else I
>  can try?
>
>  Thank you,
>
>  ¹ https://sssd.io/troubleshooting/basics.html
>  --
>  Alan Orth
>  alan.orth(a)gmail.com
>  https://picturingjordan.com
>  https://englishbulgaria.net
>  https://mjanja.ch
>  

-- 
Alan Orth
alan.orth(a)gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch