Bug 988875

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.