Link to the sudo patch in question: https://git.centos.org/blob/rpms!sudo.git/523624f1f38000c73e27c7aad2d0e607e8392c7e/SOURCES!sudo-1.8.6p7-ipahostname.patch%3bjsessionid=1wnv0bai7fk4ey1bo44wdsfcg

The main difference due to this patch is that netgr_matches in line 172 https://git.centos.org/blob/rpms!sudo.git/523624f1f38000c73e27c7aad2d0e607e8392c7e/SOURCES!sudo-1.8.6p7-ipahostname.patch%3bjsessionid=1wnv0bai7fk4ey1bo44wdsfcg#L172 now checks with a NULL user

Small example on how netgroups are evaluated in this case:

➜  ~ cat /etc/netgroup 
test1 (apollo13.apo.lan, -, apo.lan)  # This is what IPA returns for getent
test2 (apollo13.apo.lan, , apo.lan)
➜  ~ cat test.cpp 
#include <iostream>
#include <netdb.h>

using namespace std;

int main(int argc, char** argv) {
    char user[] = "florian";
    char host[] = "apollo13.apo.lan";
    char domain[] =  "apo.lan";
    char test1[] = "test1";
    char test2[] = "test2";
    cerr << innetgr(test1, host, user, domain) << endl;
    cerr << innetgr(test2, host, user, domain) << endl;
    return 0;
}
➜  ~ ./a.out 
0
1

Just to be clear:
a. You use IPA and it ability to automatically generate a netgroup for every host group, right?
b. What version of IPA do you use?

I remember there have been an issue like this many years ago when we added the netgroups support for hostgroups. But it have been OK since then and many deployments use it.

Replying to [comment:3 dpal]:

Just to be clear:
a. You use IPA and it ability to automatically generate a netgroup for every host group, right?

Yes

b. What version of IPA do you use?

4.2.0 (ie whatever comes with CentOS 7)

I remember there have been an issue like this many years ago when we added the netgroups support for hostgroups. But it have been OK since then and many deployments use it.

It works fine for CentOS Clients which do have a patch (linked above) to call innetgrp with NULL as user. But this is an extra IPA patch, the normal sudo sss plugin passes the user along…

After a bit more thinking it occurred to me that things actually work as supposed to be or I should say as designed. The netgroups that match host groups are groups that contain hosts only and are created for host matching only - this is their intent. The "-" is there on purpose to scope the netgroup to hosts only. The recommendation is to either create a specific explicit netgroup in IdM that would include a host group and user group the way you need them to be matched or reference users in sudo rules via a user group rather than a netgroup. Does this make sense?

Replying to [comment:5 dpal]:

The netgroups that match host groups are groups that contain hosts only and are created for host matching only - this is their intent. The "-" is there on purpose to scope the netgroup to hosts only.

Understood so far.

The recommendation is to either create a specific explicit netgroup in IdM that would include a host group and user group the way you need them to be matched

I can do that, but I cannot reference that netgroup from the sudo rules as "Host category" -- only hosts and hostgroups are allowed there.

or reference users in sudo rules via a user group rather than a netgroup.

I am not trying to reference users/usergroup here, all I want to do is scope a sudo rule to a subset of hosts (or do I missunderstand the purpose of " Access this host" in sudo rules). This does not work as sudo on unpatched client machines tries to compare the "netgroup" from IPA (ie the mapped hostgroup) against (host, user, domain). My workaround currently is to manually put all hosts into the rule instead of using a host-group (Sudo compares against a host just fine).

Replying to [comment:6 apollo13]:

The recommendation is to either create a specific explicit netgroup in IdM that would include a host group and user group the way you need them to be matched

I can do that, but I cannot reference that netgroup from the sudo rules as "Host category" -- only hosts and hostgroups are allowed there.

Correct but you can use the originating host group since it is the object that actually has all the host members you care about.

or reference users in sudo rules via a user group rather than a netgroup.

I am not trying to reference users/usergroup here, all I want to do is scope a sudo rule to a subset of hosts (or do I missunderstand the purpose of " Access this host" in sudo rules). This does not work as sudo on unpatched client machines tries to compare the "netgroup" from IPA (ie the mapped hostgroup) against (host, user, domain). My workaround currently is to manually put all hosts into the rule instead of using a host-group (Sudo compares against a host just fine).

It have been a while since I looked at the sudo rules and how they are evaluated but AFAIR according to http://www.sudo.ws/man/1.8.14/sudoers.ldap.man.html there is no indication that users have to be the members of the same host netgroup. Host netgroup should be checked for hosts and user group for user. If sudo makes this assumption I do not think it is spelled anywhere so IdM implementation expects that parts of the sudo rule are evaluated independently. If this is a wrong assumption and can you please point us to the documentation where this expectation is spelled out?

On the other hand Ubuntu has pretty modern SSSD. Have you tried the SUDO integration with SSSD? That leaves the resolution of the rules to SSSD and matches IdM expectations.
See this http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Also there should be a switch in ipa-client-install to configure this integration automatically.

Replying to [comment:7 dpal]:

Replying to [comment:6 apollo13]:

The recommendation is to either create a specific explicit netgroup in IdM that would include a host group and user group the way you need them to be matched

I can do that, but I cannot reference that netgroup from the sudo rules as "Host category" -- only hosts and hostgroups are allowed there.

Correct but you can use the originating host group since it is the object that actually has all the host members you care about.

Not really, because that will be the netgroup sudo tries to match then… I actually tried creating a netgroup (and include my hosts and users there) named the same as the hostgroup, but IPA does not allow that.

I am not trying to reference users/usergroup here, all I want to do is scope a sudo rule to a subset of hosts (or do I missunderstand the purpose of " Access this host" in sudo rules). This does not work as sudo on unpatched client machines tries to compare the "netgroup" from IPA (ie the mapped hostgroup) against (host, user, domain). My workaround currently is to manually put all hosts into the rule instead of using a host-group (Sudo compares against a host just fine).

It have been a while since I looked at the sudo rules and how they are evaluated but AFAIR according to http://www.sudo.ws/man/1.8.14/sudoers.ldap.man.html there is no indication that users have to be the members of the same host netgroup.

Yes, but sadly this is what sudo uses when it calls innetgroup, so having - in the netgroup returned from IdM will break that innnetgroup call.

Host netgroup should be checked for hosts and user group for user. If sudo makes this assumption I do not think it is spelled anywhere so IdM implementation expects that parts of the sudo rule are evaluated independently. If this is a wrong assumption and can you please point us to the documentation where this expectation is spelled out?

Well the main issue here is that specifying a host group in a sudo rule transforms it into a netgroup (which is the only way sudo can work with it) and sudo then dutyfully compares this to the local netgroup of (host, user, domain) -- CentOS patches that away in https://git.centos.org/blob/rpms!sudo.git/523624f1f38000c73e27c7aad2d0e607e8392c7e/SOURCES!sudo-1.8.6p7-ipahostname.patch%3bjsessionid=1wnv0bai7fk4ey1bo44wdsfcg#L172 by just setting the user to NULL and therefor it correctly compares to the host-only netgroup (not sure if that is wise to do security wise).

On the other hand Ubuntu has pretty modern SSSD. Have you tried the SUDO integration with SSSD? That leaves the resolution of the rules to SSSD and matches IdM expectations.
See this http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Also there should be a switch in ipa-client-install to configure this integration automatically.

No, didn't try it yet, I was hoping it would be using the correct provider already (I have sudo in sssd.conf services, as well as sss in nsswitch -- how can I verify?). My id_provider is IPA already, so it should automatically use that for sudo too?

Can you provide a sanitized sssd.conf please?
I will leave the rest of the conversation to SMEs in this area to chime in.
Sorry if I was not able to help right away.

[domain/bap.lan]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = bap.lan
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client01.bap.lan
sudo_provider = ipa
chpass_provider = ipa
ipa_server = _srv_, ipa01.bap.lan
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh

domains = bap.lan
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

Sorry if I was not able to help right away.

No worries, just ping me on IRC if you wanna talk ;)

I just found something interesting in https://www.sudo.ws/man/1.8.17/sudoers.man.html -- apparently netgroup_tuple is on, I have to see if I can verify & disable that, then the lookup from sudo should exclude the user!

Okay, the sss plugin ignores netgroup_tuple, starting with sudo 1.8.17 it works (https://www.sudo.ws/repos/sudo/rev/2eab4070dcf7) -- Now sudo properly leaves the user out.

Thank you dpal for pointing me into the right direction!

I'll open a bugreport on launchpad to get that integrated into Ubuntu 16.04 at least.