Description of problem: Assigning of new hosts to sudorule by adding it to hostgroup doesn't apply appropriate rule. On another hand assigning this host explicitly to sudorule without any hostgroup end up with successfull rule applying. Version-Release number of selected component (if applicable): How reproducible: add new host to hostgroup wich is assigned to some sudorule Steps to Reproduce: 1. 2. 3. Actual results: as workaround should join host explicitly to sudorule Expected results: adding host to hostgroup should apply relevant sudorule Additional info:
hostgroups are represented as netgroups to a client so you need to be sure that getent netgroup <hostgroup> returns a correct triple and you need to set nisdomainname on the client to your domain.
Note that there is an upstream ticket to all these steps automatically. It is planned to be included in next release: https://fedorahosted.org/freeipa/ticket/3358 At this point, one needs to do the manual configuration as Rob wrote in Comment 1. s.zemlyanoy, did the change help?
I reproduced the issue more detailed. I installed IPA replica and then added this host to hostgroup which should allow sudo command. But it seems that indirect membership of host in sudorule causes the problem, because when I add host directly to sudorule - it works fine for me. And now this problem occured only on this replica host. getent netgroup <hostgroup> returns corresponding ldap group
Ok, (In reply to s.zemlyanoy from comment #3) > getent netgroup <hostgroup> returns corresponding ldap group Ok, I assume this works for you now. Do you also have "sss" for "sudoers" database in /etc/nsswitch.conf and properly set "nisdomainname"? SUDO won't recognized the netgroup content without that.
Hi, So it appears that 'nisdomainname' was not set for host in question. But after I've set it the problem retained. Please review the listing of nsswitch.conf file below: passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files aliases: files nisplus # from IPA # sudoers: files ldap (END)
Can you try changing: sudoers: files ldap to sudoers: files sss to enable SSSD support in SSSD? Lets see if that makes any difference. This is the recommended integration method for FreeIPA&SUDO.
I changed it and got such message $ sudo less /var/log/messages sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? On all the rest hosts this string is set to: sudoers: files ldap so I'm not sure that it's problem
Ah, sorry for confusion, it should have been "sssd" instead of sss. I did not realize that sudoers is a special case in nsswitch.conf. There is more info on enabling sudo with sssd here: https://fedorahosted.org/freeipa/ticket/3358 (In reply to s.zemlyanoy from comment #7) ... > so I'm not sure that it's problem This is probably not the root cause, I was just interested if routing sudo integration through SSSD instead of native LDAP would change the outcome. I am not experienced with ldap backend for SUDO, adding needinfo on Pavel to advise.
I think setting the SUDOERS_DEBUG to 2 is a good next step from the ldap side.
Hi, to enable sssd for sudo, it should indeed say "sss" in nsswitch.conf. However, libsss_sudo package has to be installed, to get the missing library. There will be also more configuration needed, depending on your sssd version (1.9 or 1.10), please see 'man sssd-sudo'. But I'm not really convinced that switching to sssd backend instead of ldap will help, since the steps for evaluating netgroups are the same. The debug output as Rob suggested will be helpful. Please put the following line into /etc/ldap.conf: sudoers_debug 2 And following line into /etc/sudo.conf Debug sudo /var/log/sudo_debug all@warn And send us output of sudo command and /var/log/sudo_debug. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Hello s.zemlyanoy, did you manage to get the required data as suggested by my colleagues in Comment 9 and Comment 10? Or have you resolved the issue? If we do not have enough data to understand or reproduce the issue, we would have to close this bug.
Closing the bug. Please feel free to reopen it in case you hit the issue again.