Thanks for the report. I think we'll need more information about how your system is configured.
Could you please show how your PAM stack and sudoers configration look like? Maybe we'll need
also some debug logs from PAM and sudo, but let's start with just the configs.

Daniel, per your 1/18/19 request, is the diff of my sudoers edits with the distro version. Following is the backuppc config to allow use of rsync on the host machine. Permissions for both are 440 and root.root.

# diff of /etc/sudoers edits
# Defaults  requiretty

# /etc/sudoers.d/01_backupppc
backuppc  ALL=NOPASSWD:  /usr/bin/rsync

The Pam config for sudo is as follows here:

# /etc/pam.d/sudo

#%PAM-1.0
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so

The working version of sudo currently is:
# rpm -qi sudo
Name        : sudo
Version     : 1.8.19p2
Release     : 14.el7_5
Architecture: x86_64
Install Date: Mon 24 Dec 2018 02:03:45 PM EST

And Pam is:
# rpm -qi pam
Name        : pam
Version     : 1.1.8
Release     : 22.el7
Architecture: x86_64
Install Date: Mon 28 May 2018 11:18:58 AM EDT


/var/log/secure for Dec 18 2019 , for sudo-1.8.23-3.el7.x86_64, prior to downgrade
Dec 18 01:00:04 localhost sudo: backuppc : PAM account management error: Authentication service cannot retrieve authentication info ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --one-file-system --exclude= --ignore-times . /

(In reply to Kelly-Rand from comment #4)
> Daniel, per your 1/18/19 request, is the diff of my sudoers edits with the
> distro version. Following is the backuppc config to allow use of rsync on
> the host machine. Permissions for both are 440 and root.root.
> 
> # diff of /etc/sudoers edits
> # Defaults  requiretty
> 
> # /etc/sudoers.d/01_backupppc
> backuppc  ALL=NOPASSWD:  /usr/bin/rsync
> 
> The Pam config for sudo is as follows here:
> 
> # /etc/pam.d/sudo
> 
> #%PAM-1.0
> auth       include      system-auth
> account    include      system-auth

Could you please show the state of the system-auth PAM file as well?

I tried to reproduce the issue but haven't succeeded yet.
So far this looks like a normal configuration and works for me when replicated.
Is the 'backuppc' a local user?

Here is the state of the system-auth-ac Pam file:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

State in Pam.d
  lrwxrwxrwx.   1 root root    14 Feb  4  2018 system-auth -> system-auth-ac
  -rw-r--r--.   1 root root  1031 Feb  4  2018 system-auth-ac

Yes, the backuppc user is local. 

If this is insufficient to determine the cause of the issue I could reinstall the latest sudo version and see if the problem is still present. I need to coordinate this with the backup schedule which would delay any results till Jan 25, 26.

Jan 26, 2019

I yum updated to sudo-1.8.23-3.el7 today and was able to duplicate my earlier error as described in the first post. I also found that the file /etc/pam.d/sudo has an added line at the end as seen here:

#/etc/pam.d/sudo
#%PAM-1.0
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth   << this line does not exist in the prior sudo

Deleting the last line does not change the outcome of the failed call to sudo by backuppc.

So there does appear to be a policy shift within sudo that relates to the session authentication?

I have to revert back to the earlier version of sudo for now.

Created attachment 1539149 [details]
testing srpm

I've attached an SRPM with an upstream patch which might fix the problem you are seeing. Could you build the SRPM and test it in your environment? I can provide binary builds if you can't build it yourself.

Daniel,

Could you provide a rpm for install? I'm not practiced at compiling nor do I know if I have the necessary libraries installed. I can test it this weekend. 

Regards,

Jim KR

Created attachment 1539376 [details]
testing build

(In reply to Kelly-Rand from comment #10)
> Daniel,
> 
> Could you provide a rpm for install? I'm not practiced at compiling nor do I
> know if I have the necessary libraries installed. I can test it this
> weekend. 

Attached.

I've installed and tested this most recent build. The result is still "Authentication service cannot retrieve authentication info"

bash-4.2$ rpm -qi
rpm: no arguments given for query
bash-4.2$ rpm -qi sudo
Name        : sudo
Version     : 1.8.23
Release     : 3.1551336486.el7_6
Architecture: x86_64
Install Date: Sun 03 Mar 2019 12:13:36 PM EST
Group       : Applications/System
Size        : 3196613
License     : ISC
Signature   : (none)
Source RPM  : sudo-1.8.23-3.1551336486.el7_6.src.rpm
Build Date  : Thu 28 Feb 2019 01:49:12 AM EST


bash-4.2$ sudo /bin/rsync -d /home /tmp/
sudo: PAM account management error: Authentication service cannot retrieve authentication info

/var/log/secure does not show any additional information.

I added these two lines to sudo.conf

Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug

But the only output in /var/log/sudo_debug is:
Mar  3 13:07:02 sudo[27680] PAM account management error: Authentication service cannot retrieve authentication info: Unknown error -1

What next?

I've done a bugzilla search for similar terms as my own and do not see any, so my question would be what is different about my setup vs the expected. This server has been running since early 2000 starting with RH6 then migrating to early Fedora and then to SL 6.1 and now SL 7.6. 

Well?

(In reply to Kelly-Rand from comment #14)
> I've done a bugzilla search for similar terms as my own and do not see any,
> so my question would be what is different about my setup vs the expected.
> This server has been running since early 2000 starting with RH6 then
> migrating to early Fedora and then to SL 6.1 and now SL 7.6. 
> 
> Well?

Maybe a strace log would give us more insight into what is happening:

```
# strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync
```

Does the backuppc user have an entry in both /etc/shadow and /etc/passwd?

Does the test RPM contain the patch from https://www.sudo.ws/pipermail/sudo-users/2018-December/006160.html, which seems to be related?

Created attachment 1541791 [details]
testing build patch

(In reply to James Juran from comment #17)
> Does the test RPM contain the patch from
> https://www.sudo.ws/pipermail/sudo-users/2018-December/006160.html, which
> seems to be related?

Yes, that is the patch used in the testing build. I've attached the patch to this BZ so that is clear what is being tested.

I won't be able to get the strace results till around 3/16. I'm away and don't have access to the system.

Created attachment 1543045 [details]
Sudo strace log for version 1.8.23-3.1551336486

Requested log info for command:
# strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync -d /home /tmp/
sudo: PAM account management error: Authentication service cannot retrieve authentication info

The user backuppc has an entry in /etc/passwd but NOT in /etc/shadow

(In reply to Kelly-Rand from comment #22)
> The user backuppc has an entry in /etc/passwd but NOT in /etc/shadow

Ok, that might be the trigger of the issue. I'll try to reproduce it myself. If you'll have a chance to test it too -- i.e. adding the /etc/shadow entry and try sudo again --, then please do.

(In reply to Kelly-Rand from comment #21)
> Created attachment 1543045 [details]
> Sudo strace log for version 1.8.23-3.1551336486
> 
> Requested log info for command:
> # strace -u backuppc -ff -o sudo-strace.log -x sudo /usr/bin/rsync -d /home
> /tmp/
> sudo: PAM account management error: Authentication service cannot retrieve
> authentication info

I've successfully reproduces this error by creating the backuppc user via useradd and then removing the /etc/shadow entry.
So, if you want to fix the issue at your site, please add that missing /etc/shadow entry.

Do you have an idea how did you end up with an entry in /etc/passwd but not in /etc/shadow? How was the backuppc entry created?

Adding backuppc via "pwck" fixed the issue. I am now running sudo version 1.8.3-23-3.

As for why the user backuppc was not in shadow will be a mystery. I can guess that it happened during a distro version change, as retaining existing users and their existing UID/GID's is cumbersome. 

running 'pwck -r' after distro version changes will become part of my routine.

Ok, great to have this resolved. I'll close this as NOTABUG then.

I am now seeing the same thing on EL8, for user who DOES have an entry in /etc/shadow, but has no password set.

We were using ssh keys to log user in, and it was working until I made some change to the krb5/sssd config, in order to authenticate vs a domain.

Then suddenly hit this 

[someuser@implicit_files@somehost ~]$ sudo su -
sudo: PAM account management error: Authentication service cannot retrieve authentication info

"authselect check" and "pwck" report no relevant issues.

Setting a password for the user resolved the issue, and also got rid of the "@implicit_files" nonsense.


There is an *INFESTATION* of bugs here...

Nope, setting password is not resolving the issue. 
It did, briefly, but restarting sssd has brought the issue back.

This is what i saw, after disabling sssd and setting password:

[root@blah ~]# passwd meh
Changing password for user meh.
New password: 
BAD PASSWORD: The password is shorter than 8 characters
Retype new password: 
passwd: all authentication tokens updated successfully.
[root@blah ~]# exit
logout
[meh@implicit_files@blah ~]$ exit
logout
Connection to blah closed.
[07-09 15:35:22 ~]$ 
[07-09 15:35:23 ~]$ ssh -i somekey -o StrictHostKeyChecking=no -X meh@blah
Last login: Tue Jul  9 15:09:19 2019 from someip
[meh@blah ~]$ sudo su -
Last login: Tue Jul  9 15:10:06 AEST 2019 on pts/0
[root@blah ~]# 

Looked good.
But after enabling sssd and rebooting, the problem is back, and now, resetting the password does not resolve the issue *at all*.

Once again, Red Hat proves to be a massive PITA.

Red Hat can't even put together an OS you can reliably login to, and sudo on.
Just pitiful.

Ah, hangon, no, it seems that when sssd is off, i can login without seeing this unbelievably ugly @implicit_files garbage.
And, i can sudo.

So, this ridiculous behaviur i'm seeing looks like it is the a problem in SSSD.
What a piece of garbage that thing is.

Nope, can't even reliably login with sssd off.
I kid you not, it looks like starting sssd does something that causes this error, and stopping sssd does not fix it.

But if I run "passwd" to set the password of the user in question, *after* stopping sssd, then that fixes the user's sudo problems& @implicit_file nonsense... at least until sssd is restarted.

What an appalling mess.

In my case, on el8, I have narrowed this down to using:
    default_domain_suffix = somedomain
in my /etc/sssd/sssd.conf

I was doing this, because our hosts are joining one domain, but the admin users who most frequently login, are from another trusted domain, so I want those users to be able to login without specifying their domain.

So now, on EL8, i have to disable this option, and they have to give their full domain when they login.

Hopeless.
Just hopeless.

Hi

Can you please reopen this BUG.

I'm having this same issue on CentOS 7 with users which are in TACACS+.

Current system sudo rpm "sudo-1.8.23-3.el7.x86_64.rpm" --Broken
Upgraded to sudo rpm "sudo-1.8.23-4.el7.x86_64.rpm"  --Broken

Downgraded to sudo-1.8.19p2-11.el7_4.rpm and it's working without any change.

Following are the Step to Reproduce with TACACS+

	Step to Reproduce
	----------------------
	1. ssh to the target system 
	2. sudo su -
	 - First time it will be successful ---
	3. exit from sudo
		exit
	4. In the same session of ssh, try to do the sudo again
		sudo su -
		
		Now you will start getting error until you close your ssh session or exit from ssh and do it again.


	Note: As User exists in TACACS+, it will have no entry in /etc/password or /etc/security

	----Output------

	[ root@Term1:~ ]# ssh isasu@mycentos
	TACACS+ Password: 
	[isasu.6.1810 ~]$ uname -a
	Linux centos.7.6.1810 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
	[isasu.6.1810 ~]$ sudo su -
	TACACS+ Password: 
	Last login: Wed Oct 23 21:38:13 UTC 2019 from 192.168.1.10 on pts/0
	[root.6.1810 ~]# exit
	logout
	[isasu.6.1810 ~]$ sudo su -
	sudo: PAM account management error: Authentication service cannot retrieve authentication info
	[isasu.6.1810 ~]$ exit
	[ root@Term1:~ ]# 
	
	
Logs
==================================

	[root.6.1810 ~]# grep isasu /etc/sudoers
	isasu   ALL=(ALL) NOPASSWD: ALL

	/var/log/secure

		Oct 23 21:51:02 centos.7.6.1810 sshd[13432]: Accepted keyboard-interactive/pam for isasu from 127.0.0.1 port 47926 ssh2
		Oct 23 21:51:02 centos.7.6.1810 sshd[13432]: pam_unix(sshd:session): session opened for user isasu by (uid=0)
		Oct 23 21:51:07 centos.7.6.1810 sudo:   isasu : TTY=pts/3 ; PWD=/home/qns-su ; USER=root ; COMMAND=/bin/su -
		Oct 23 21:51:07 centos.7.6.1810 sudo: pam_unix(sudo:session): session opened for user root by isasu(uid=0)
		Oct 23 21:51:07 centos.7.6.1810 su: pam_unix(su-l:session): session opened for user root by isasu(uid=0)
		Oct 23 21:51:08 centos.7.6.1810 su: pam_unix(su-l:session): session closed for user root
		Oct 23 21:51:08 centos.7.6.1810 sudo: pam_unix(sudo:session): session closed for user root
		Oct 23 21:51:10 centos.7.6.1810 sudo[13993]: pam_sss(sudo:account): Access denied for user isasu: 10 (User not known to the underlying authentication module)
		Oct 23 21:51:10 centos.7.6.1810 sudo:   isasu : PAM account management error: Authentication service cannot retrieve authentication info ; TTY=pts/3 ; PWD=/home/qns-su ; USER=root ; COMMAND=/bin/su -


	/var/log/messages
		Oct 23 21:49:27 centos.7.6.1810 systemd: Started Session 1616 of user isasu.
		Oct 23 21:49:46 centos.7.6.1810 systemd-logind: Removed session 1616.
		Oct 23 21:49:46 centos.7.6.1810 systemd: Removed slice User Slice of isasu.
		Oct 23 21:49:53 centos.7.6.1810 systemd: Created slice User Slice of isasu.
		Oct 23 21:49:53 centos.7.6.1810 systemd: Started Session 1617 of user isasu.
		Oct 23 21:49:53 centos.7.6.1810 systemd-logind: New session 1617 of user isasu.
		Oct 23 21:49:57 centos.7.6.1810 su: (to root) isasu on pts/3
		Oct 23 21:50:02 centos.7.6.1810 PAM-tacplus[11425]: user not authenticated by TACACS+
		Oct 23 21:50:05 centos.7.6.1810 systemd-logind: Removed session 1617.
		Oct 23 21:50:05 centos.7.6.1810 systemd: Removed slice User Slice of isasu.
		Oct 23 21:51:02 centos.7.6.1810 systemd: Created slice User Slice of isasu.
		Oct 23 21:51:02 centos.7.6.1810 systemd: Started Session 1618 of user isasu.
		Oct 23 21:51:02 centos.7.6.1810 systemd-logind: New session 1618 of user isasu.
		Oct 23 21:51:07 centos.7.6.1810 su: (to root) isasu on pts/3
		Oct 23 21:51:10 centos.7.6.1810 PAM-tacplus[13993]: user not authenticated by TACACS+
		
		
	--------sudo and pam rpm info

		[ root.6.1810:~ ]# rpm -qi pam
		Name        : pam
		Version     : 1.1.8
		Release     : 22.el7
		Architecture: x86_64
		Install Date: Tue 28 May 2019 04:03:41 PM UTC
		Group       : System Environment/Base
		Size        : 2630324
		License     : BSD and GPLv2+
		Signature   : RSA/SHA256, Wed 25 Apr 2018 11:33:49 AM UTC, Key ID 24c6a8a7f4a80eb5
		Source RPM  : pam-1.1.8-22.el7.src.rpm
		Build Date  : Wed 11 Apr 2018 03:22:15 AM UTC
		Build Host  : x86-01.bsys.centos.org
		Relocations : (not relocatable)
		Packager    : CentOS BuildSystem <http://bugs.centos.org>
		Vendor      : CentOS
		URL         : http://www.linux-pam.org/
		Summary     : An extensible library which provides authentication for applications
		Description :
		PAM (Pluggable Authentication Modules) is a system security tool that
		allows system administrators to set authentication policy without
		having to recompile programs that handle authentication.

		[ root.6.1810:~ ]# rpm -qi sudo
		Name        : sudo
		Version     : 1.8.23
		Release     : 3.el7
		Architecture: x86_64
		Install Date: Thu 17 Oct 2019 01:41:19 AM UTC
		Group       : Applications/System
		Size        : 3196629
		License     : ISC
		Signature   : RSA/SHA256, Mon 12 Nov 2018 02:47:22 PM UTC, Key ID 24c6a8a7f4a80eb5
		Source RPM  : sudo-1.8.23-3.el7.src.rpm
		Build Date  : Wed 31 Oct 2018 12:37:04 AM UTC
		Build Host  : x86-01.bsys.centos.org
		Relocations : (not relocatable)
		Packager    : CentOS BuildSystem <http://bugs.centos.org>
		Vendor      : CentOS
		URL         : http://www.courtesan.com/sudo/
		Summary     : Allows restricted root access for specified users
		Description :
		Sudo (superuser do) allows a system administrator to give certain
		users (or groups of users) the ability to run some (or all) commands
		as root while logging all commands and arguments. Sudo operates on a
		per-command basis.  It is not a replacement for the shell.  Features
		include: the ability to restrict what commands a user may run on a
		per-host basis, copious logging of each command (providing a clear
		audit trail of who did what), a configurable timeout of the sudo
		command, and the ability to use the same configuration file (sudoers)
		on many different machines.
		[ root.6.1810:~ ]#

We have also had an issue with the new sudo package (in 7u7).

We are using the pam-script module from https://github.com/jeroennijhof/pam_script, and have noticed a change in behaviour when using sudo.

With sudo 1.8.19p2-10 (7u4), our scripts did not appear to be run at all, which I take to mean that sudo was not using PAM.

With sudo-1.8.23-4 (7u7), we are finding that our PAM scripts ARE being run for the PAM "account" operation, and are run as the originating user. We expected that they would be run as root since sudo is, obviously, setuid to root.

Has there been a change in the way sudo uses PAM between the two versions? A change in the defaults, perhaps?

Can someone please reopen this BUG as i reported earlier ?
or do i need to open another one ?

There was definitely a change in the way how sudo call pam stack. Previously it did not do that.

From the description I would say there's some issue with sssd configuration rather than with sudo.
Can you provide us pam stack configuration, sssd configuration, and sudo configuration? There might be other configurations needed for the analysis, a sosreport tool might get handy here.