Adding administrators to "wheel" group to use sudo issues
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Adding administrators to "wheel" group to use sudo issues
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.
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.
Re: Adding administrators to "wheel" group to use sudo issues
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?
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
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
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Re: Adding administrators to "wheel" group to use sudo issues
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:
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 sudo: user : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo hello
Code: Select all
hostname sshd[216505]: Failed password for user from (IP address) port 65317 ssh2
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Re: Adding administrators to "wheel" group to use sudo issues
I'm not sure if you are after a specific answer, but I'll try to answer this as best as I can.How are you integrating with AD?
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
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.
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Re: Adding administrators to "wheel" group to use sudo issues
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
Code: Select all
account required pam_unix.so broken_shadow
Code: Select all
account [default=bad success=ok user_unknown=ignore] pam_winbind.so
Code: Select all
password sufficient pam_winbind.so use_authtok
Code: Select all
session optional pam_winbind.so
sudo on compute1 does not have this line (but compute2 does):
Code: Select all
session include system-auth
Code: Select all
session include sudo
We'll start with the system-auth file and see what happens.
Re: Adding administrators to "wheel" group to use sudo issues
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.)
(I've never used AD, so might be wrong on this.)
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Re: Adding administrators to "wheel" group to use sudo issues
I used the command:
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
but I get the following error:
I've been using wbinfo to check things, but the answers I am getting are a little inconsistent.
Code: Select all
authconfig --enablewinbindauth --update
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
Code: Select all
Failed to join domain: failed to lookup DC info for domain '(domain)' over rpc: An internal error occurred.
-
- Posts: 29
- Joined: 2018/06/25 12:07:10
Re: Adding administrators to "wheel" group to use sudo issues
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.
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.