Adding administrators to "wheel" group to use sudo issues

General support questions
Post Reply
TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/10/21 13:35:24

Hi,
Our company has a number of Centos (7) and Ubuntu servers. We have a full-time system administrator, who has a Windows background and not much Linux experience, and myself, who is a Mechanical Engineer by profession, but the person in the company who understands Linux the most. There was someone before me who set up our system, but he is no longer available.

A security certificate we are trying to obtain has a requirement that system administrators each use their own password rather than use a shared password (i.e. the root account). The best solution to me would be to add administrators to the "wheel" group in Centos and the "sudoers" group in Ubuntu. All user accounts are on a Samba AD controller, and the /home directories of all users are on a NFS. I have added myself and the other administrator to the wheel group, but I seem to only be able to use sudo successfully on some of our Centos servers and not others. For the servers where it doesn't work, the password is considered incorrect, so I get the "sorry, try again" message twice then "sudo: 3 incorrect password attempts".

What I have noticed is that the servers on which sudo does not work also do not allow password authentication for ssh logins. We usually use rsa key authentication so this is not an issue, but it does make me wonder if the two observations are linked. I also have another interesting observation: on the servers for which sudo does not work I get the "we trust you have received the usual lecture from the local System Administrator..." message before the password prompt, but on the servers where sudo does work I get no message.

Any ideas on what to check? I think I could possibly look at how they interact with Samba AD, or how root is setup.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Adding administrators to "wheel" group to use sudo issues

Post by TrevorH » 2021/10/21 14:16:28

I'd suggest reading /var/log/messages and /var/log/secure to see if there are clues there on the machines that do not work.

How are you integrating with AD?
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Re: Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/10/21 15:20:58

On one server, it seems I forgot to add myself to the wheel group. However, for the other two where sudo doesn't work, the /var/log/secure file just says:

Code: Select all

hostname sudo:    user : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo hello
I have also tried logging into one of the servers with ssh but without presenting the private key (and trying to login with password) and this message appears in the /var/log/secure:

Code: Select all

hostname sshd[216505]: Failed password for user from (IP address) port 65317 ssh2

TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Re: Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/10/21 15:47:58

How are you integrating with AD?
I'm not sure if you are after a specific answer, but I'll try to answer this as best as I can.

We have an Ubuntu VM (we shall call "ads"), setup by someone before me, and it seems to serve as both a local DNS server and is running Samba as an AD Domain Controller.

I have only been involved in the setup of 2 servers (the rest were setup by someone before me), but among other things (editing /etc/samba/smb.conf and /etc/nsswitch.conf), I have used the command:

Code: Select all

net ads join -U administrator
to add the servers to the AD domain.

The 2 servers I have been involved with both don't have sudo working.

This has just reminded me of something. I wonder if it is firewall-cmd related? The first server I setup was based on one of the existing servers, but rather than having the firewall completely disabled I decided to have the firewall enabled but I allowed certain services (nfs, mountd, rpc-bind, samba) and ports. The one with firewall disabled works fine with sudo.

TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Re: Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/10/28 12:39:39

TrevorH wrote:
2021/10/21 14:16:28
I'd suggest reading /var/log/messages and /var/log/secure to see if there are clues there on the machines that do not work.

How are you integrating with AD?
I was looking into the password login issue and managed to find something.
One server (we shall call "compute1") does allow password login for AD users and also allows sudo for me (also an AD user).
Another server (we shall call "compute2") does not allow either: AD users can log in using an rsa-key (but in practice rarely do) because /home/ is mounted on an NFS, administrators can use su - and the root password.

I noticed in /var/log/secure that for compute1 if I ssh without presenting a private key, the entry "pam_winbind(sshd:auth): getting password" appears but this does not happen for compute2.

I have therefore looked into winbind, which has led to me comparing the /etc/pam.d/system-auth files between the two servers and I've found a number of differences:

compute1 contains this additional line in the auth section:

Code: Select all

auth        sufficient   pam_winbind.so use_first_pass
This line has "broken_shadow" added to the end:

Code: Select all

account     required     pam_unix.so broken_shadow
This additional line in the account section:

Code: Select all

account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
This additional line in the password section:

Code: Select all

password    sufficient   pam_winbind.so use_authtok
And this additional line in the session section:

Code: Select all

session     optional      pam_winbind.so
I decided to also compare /etc/pam.d/sudo and /etc/pam.d/sudo-i and found:
sudo on compute1 does not have this line (but compute2 does):

Code: Select all

session    include      system-auth
sudo-i on compute1 does not have this line (but compute2 does):

Code: Select all

session    include      sudo
To me, it does seem if the system-auth file does not contain the pam_winbind.so lines then the server would not be able to check the user passwords. I have not implemented the changes yet, but I imagine these are needed to both allow user password login and for sudo password to work. I don't know the significance of the "broken_shadow", nor whether the sudo and sudo-i files need to have the lines removed.

We'll start with the system-auth file and see what happens.

User avatar
jlehtone
Posts: 4523
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Adding administrators to "wheel" group to use sudo issues

Post by jlehtone » 2021/10/28 14:37:53

There are more than one method to handle authentication. The PAM can connect to AD (with pam_winbind?) or to sssd (with pam_sss). The sssd can in turn use AD as backend.

(I've never used AD, so might be wrong on this.)

TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Re: Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/11/05 19:48:21

I used the command:

Code: Select all

authconfig --enablewinbindauth --update
to update the /etc/pam.d/system-auth file, and it made exactly the same changes as described above.

It also made changes to the /etc/nsswitch.conf file. As I had previously edited the file manually to set Samba as a Domain Member (as described here: https://wiki.samba.org/index.php/Settin ... ain_Member ) and suspected it would overwrite my changes, I made a copy of the nsswitch.conf file before running the authconfig command. My nsswitch.conf changes were not reversed, but there are other changes. I therefore reverted the nsswitch.conf file.

However, the issue I was trying to fix has not been fixed, and now there are issues with the functioning of the server. When I "ls -l /home" (for example: the /home area is an NFS home area) I do not see the user names and group names but numerical uids and gids. "getent passwd" and "getent group" does not show the AD users and groups. It seems there is now a problem with this server and its domain membership.

I've tried to join the domain again with

Code: Select all

net ads join -U administrator
but I get the following error:

Code: Select all

Failed to join domain: failed to lookup DC info for domain '(domain)' over rpc: An internal error occurred.
I've been using wbinfo to check things, but the answers I am getting are a little inconsistent.

TypoSpotter
Posts: 29
Joined: 2018/06/25 12:07:10

Re: Adding administrators to "wheel" group to use sudo issues

Post by TypoSpotter » 2021/11/11 13:09:11

The issue now appears to be fixed.
The authconfig --enablewindbindauth --update command probably fixed the issue with sudo and password login, but it initially appeared to break the system. However, that is an unrelated issue with the primary AD DC, for now I have fixed that by setting the secondary AD DC as the controller using authconfig --smbservers=ads2.domain.company.com --update

Now that the system is working properly again, I have noticed that sudo and password login is working correctly as intended.

Post Reply