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.
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
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:
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 ~ > 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.
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