On 09/23/2013 11:45 AM, Rowland Penny wrote:
On 23/09/13 09:41, Pavel Březina wrote:
On 09/20/2013 03:40 PM, Rowland Penny wrote:
On 20/09/13 13:49, Pavel Březina wrote:
On 09/20/2013 11:09 AM, Rowland Penny wrote:
On 20/09/13 08:36, Pavel Březina wrote:
On 09/19/2013 06:18 PM, Rowland Penny wrote: > Ok, I am back again, trying to get sssd to control sudo, but > failing. > > I added the sudo active directory schema ldif to samba4 AD > > then added this: > > dn: OU=SUDOers,DC=example,DC=com > objectClass: top > objectClass: organizationalUnit > ou: SUDOers > > dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com > objectClass: top > objectClass: sudoRole > cn: linuxusers > sudoUser: %linuxusers > sudoHost: ALL > sudoCommand: ALL > > On a Linux Mint client: > > sudo apt-get install sudo-ldap > > Edited /etc/sudo-ldap.conf > > # TLS certificates (needed for GnuTLS) > TLS_CACERT /etc/ssl/certs/ca-certificates.crt > BASE DC=example,DC=com > URI ldap://server.example.com > ssl=no > LDAP_VERSION 3 > SUDOERS_BASE ou=SUDOers,DC=example,DC=com > SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole)) > BINDDN CN=Administrator,CN=Users,DC=example,DC=com > BINDPW xxxxxxxxxx > > then edited /etc/nsswitch.conf and added > > sudoers: files ldap > > restarted sudo > > then as a normal user, tried to run a command with sudo, this > worked. > > I then altered /etc/sssd/sssd.conf and added > > services = nss, pam, autofs, sudo > > [sudo] > > ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com > > altered /etc/nsswitch.conf > > sudoers: files sss > > restarted sssd > restarted sudo > > tried to run the command with sudo again, this time it failed > > having been bitten by the way autofs works, I went straight to > the way > that sudo & sssd do the ldapsearch: > > SUDO > (&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain > Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL))) > > > > > > SSSD > (&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*)))) > > > > > > sudo searches with objectClass=sudoRole & sudoUser attribute > sssd searches with objectClass=sudoRole & sudoHost attribute > > Now I understand that the sssd search for the sudoHost attribute > is to > ensure that only sudo rules for the host are downloaded, but it > doesn't > actually seem to download any rules. > > Is there anyway I can get the sssd search to include the sudoUser > attribute in the same way that the sudo ldap search does?
Hi, no, it is not desirable. SSSD periodically downloads all rules that are applicable to the machine, and then filters them by user when sudo request is performed. In other words: filtering by sudoUser is there, only on other place (sssd_sudo process).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
I am now getting a bit confused, I took the output of 'sudo -l' to mean '(user_to_runas) what_to_run', so '(root) ALL' would allow the user to run all programs as root provided that the correct users password is entered when prompted. So as the whole idea is usually for a user to run programs as root and root is always a local user, you lost me there.
Ah, sorry to confuse you. I messed it up a little. When I saw "root" I somehow managed to think that you run "sudo -l" under root user.
The rules are provided only for SSSD-managed users and groups.
I understand this
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Have attached log level 9 logs
Thank for the logs. The LDAP provider stores three rules in the cache. Is this correct (sssd stores only those rules that are applicable to the machine)?
However, sssd_sudo.log says that sudo didn't communicate with sssd sudo responder at all. Did you run 'sudo -l' when you obtained the logs?
Can you double check that you have sudoers: files sss in /etc/nsswitch.conf and libsss_sudo.so installed?
What version of sudo do you use? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
This is a test domain and the rules are all set to 'sudoHost: ALL', none of the rules were downloaded until I added a defaults rule.
yes I did run 'sudo -l'
yes I do have the sudoers line in nsswitch.conf
libsss_sudo.so is in /usr/lib/x86_64-linux-gnu
This is where it gets interesting, I was originally trying sudo from my laptop running sssd 1.10.92, but I have now setup a VM running LM15 with sssd 1.9.4 and this has the same problem. I cannot see anywhere in any logs where sudo connects to sssd to get the rules, so I am now beginning to think that this is actually a sudo problem. The fact that using 'ldap' instead of 'sss' in nsswitch.conf works seems to point to this.
It would help if sudo actually logged somewhere without having to jump through hoops ;-)
Rowland
Can you put into /etc/sudo.conf the following line? Debug sudo /var/log/sudo_debug all@trace
Re-run sudo and send me the file?
Also what version of sudo do you run?