1

I'm trying to get an OpenLDAP server up and running a small set of servers. Some of the users naturally need root/sudo access.

The OpenLDAP is setup to use ssh keys for login using https://github.com/AndriiGrytsenko/openssh-ldap-publickey

There is a group named sudo for the purpose on the ldap server. The clients are running SSSD for the setup, all systems are running Ubuntu Server.

The sssd.conf from a client:

[sssd]
config_file_version = 2
domains = user-server

[domain/user-server]
id_provider = ldap
auth_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://user-server
cache_credentials = False
ldap_search_base = dc=user-server
ldap_sudo_search_base = ou=sudo,dc=user-server

The nsswitch.conf

passwd:         files systemd sss
group:          files systemd sss
shadow:         files sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
automount:      sss

It seems that the sudo command is working if I have made an ssh password login on the machine prior to running sudo, but if I haven't it will keep asking for a password as if it isn't looking up the password.

If the user password is changed it has an effect on all working machines. Same if I remove the user from the sudo group it does lose access as expected, and access is regained when the user is added to the group again.

How do I get my sudo to check the password against my ldap as expected?

Edit: the comment from @ognjen led me to search a bit and realized that this log might be helpful:

from auth.log:

Apr  8 14:44:36 client-machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Apr  8 14:44:40 client-machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Apr  8 14:44:40 client-machine sudo: pam_sss(sudo:auth): authentication failure; logname=rohdef uid=10000 euid=0 tty=/dev/pts/1 ruser=rohdef rhost= user=rohdef
Apr  8 14:44:40 client-machine sudo: pam_sss(sudo:auth): received for user rohdef: 9 (Authentication service cannot retrieve authentication info)

Edit part 1: sudo and pam details per @ognjen suggestion:

Personal not: compared these with the working machine, and they are virtually identical. Isn't it SSSD that should take care of pam and whatever over layers are needed, and not sudo? Can anyone confirm?

rohdef@client-machine ~ [1]> ldd (which sudo)
        linux-vdso.so.1 (0x0000ffff91dba000)
        libaudit.so.1 => /lib/aarch64-linux-gnu/libaudit.so.1 (0x0000ffff91d14000)
        libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000ffff91cdb000)
        libutil.so.1 => /lib/aarch64-linux-gnu/libutil.so.1 (0x0000ffff91cc7000)
        libsudo_util.so.0 => /usr/lib/sudo/libsudo_util.so.0 (0x0000ffff91c9b000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff91b22000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff91d88000)
        libcap-ng.so.0 => /lib/aarch64-linux-gnu/libcap-ng.so.0 (0x0000ffff91b0d000)
        libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffff91a7f000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff91a6b000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff91a3b000)
rohdef@client-machine ~> sudo -V
Sudo version 1.9.1
Sudoers policy plugin version 1.9.1
Sudoers file grammar version 48
Sudoers I/O plugin version 1.9.1
Sudoers audit plugin version 1.9.1
rohdef@client-machine ~> sudo -L
sudo: invalid option -- 'L'
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

Edit part 2: investigations from logs @Guser314 pointed towards

After digging in the logs I found one curious thing. The logs for the LDAP from SSSD varies quite a lot from the working and defunct machine.

Logs from the defunct: https://pastebin.com/05p2KszE Logs from the working: https://pastebin.com/t6av2xdy

Log note, I have added a few blank lines for readability, no lines have been removed. Logs correspond to exactly one attempt at sudo (there's no change from repeated attempts)

Judging by the logs it seems that the one that haven't run a password login is basically just giving up looking up the service

11
  • 1
    Have you enabled the sudo responder with sudo systemctl enable sssd-sudo.socket as noted here. – Guser314 Apr 6 at 21:57
  • 1
    Are you running sudo that you installed from source or sudo distribution package? It is possible that there is no pam support in the sudo package that you are using. – ognjen Apr 8 at 9:19
  • @Guser314 I hadn't :/ it doesn't seem to work though. I'm looking in to the configs they mention on you link, might answer my problebs – Rohde Fischer Apr 8 at 14:12
  • 1
    To check sudo support for pam run these 1 - ldd which sudo To check if sudo is compiled with PAM 2 - sudo -V To check version of sudo 3 - sudo -L – ognjen Apr 8 at 16:22
  • 1
    Troubleshooting sssd sudo here. Also has ways to ask for help. Notes the use of sudoers: files sss in nsswitch.conf. I have it working on 20.10 server test vm but only using files for sudo. Noted all sssd sockets enabled by default after sssd, sssd-utils, sssd-dbus installation. Using Google LDAPS. – Guser314 Apr 8 at 20:16
1
+100

Here is my consolidated list, glad it helped:

Make sure the sssd responder sockets are enabled, see here. After a fresh install of 20.10 server on a vm I noted that a subsequent apt install of sssd, sssd-utils, sssd-dbus resulted in all responder sockets being enabled. Though many times I've had to enable the responder sockets I needed.

Check the certificates (client and server). See the FAQ - Authentication fails against LDAP. I noted for Google LDAPS I needed ldap_tls_reqcert = never in sssd.conf because LDAPS requires SNI and CentOS 7,8 and Ubuntu 20.04 do not provide the same resulting in Google sending back a self signed certificate.

Finally, dig into the logs by following the Troubleshooting SUDO.

1
  • One side comment, I actually didn't need the sockets enabled (or they just are by default in my setup) :) but it's definitely needed for some setups indeed :) – Rohde Fischer Apr 11 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.