External groups from AD trust fail with "Incomplete group object for ...[0]! Skipping" (although in the logs all members seem to be fetched)
I have an FreeIPA domain (ipa.engr.tamu.edu) that has a one-way trust with an AD domain (engr.tamu.edu). I've created a POSIX group called 'linux_team' that contains an external group called 'linux_team_ext', which itself contains the AD group linux_team@engr.tamu.edu (from the trusted domain). When I perform a 'getent group linux_team', I get no results. When looking at the debug logs, I see that SSSD does fetch all of the users from the group:
(Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-william.luke@engr.tam u.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-andrew.eggleston@engr .tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-blake.dworaczyk@engr. tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-david.miller@engr.tam u.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-j.polasek@engr.tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-matthew.mjelde@engr.tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-steve.herring@engr.tamu.edu] to [overridememberUid].
However, I ultimately see this line: (Fri Aug 16 16:16:37 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for linux_team@engr.tamu.edu[0]! Skipping
I've tested the trust relationship and it appears to work fine; I am able to create view overrides and fetch users from the domain without any problem.
The complete logs are here: https://drive.google.com/file/d/164_zRBreVtA4P9-MZ0r8MIx-ElFOful-/view?usp=s...
On pe, 16 elo 2019, Blake Dworaczyk via FreeIPA-users wrote:
I have an FreeIPA domain (ipa.engr.tamu.edu) that has a one-way trust with an AD domain (engr.tamu.edu). I've created a POSIX group called 'linux_team' that contains an external group called 'linux_team_ext', which itself contains the AD group linux_team@engr.tamu.edu (from the trusted domain). When I perform a 'getent group linux_team', I get no results. When looking at the debug logs, I see that SSSD does fetch all of the users from the group:
(Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-william.luke@engr.tam u.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-andrew.eggleston@engr .tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-blake.dworaczyk@engr. tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-david.miller@engr.tam u.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-j.polasek@engr.tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-matthew.mjelde@engr.tamu.edu] to [overridememberUid]. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): No override name available. (Fri Aug 16 16:16:37 2019) [sssd[nss]] [sysdb_add_group_member_overrides] (0x4000): Added [coe-steve.herring@engr.tamu.edu] to [overridememberUid].
However, I ultimately see this line: (Fri Aug 16 16:16:37 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for linux_team@engr.tamu.edu[0]! Skipping
It is here: (Fri Aug 16 16:09:32 2019) [sssd[be[ipa.engr.tamu.edu]]] [sdap_check_ad_group_type] (0x4000): AD group [linux_team@engr.tamu.edu] has type flags 0x80000004.
Type 0x80000004 is a security domain local group.
SSSD filters domain local groups out over trust:
/* Only security groups from AD are considered for POSIX groups. * Additionally only global and universal group are taken to account * for trusted domains. */ if (!(ad_group_type & SDAP_AD_GROUP_TYPE_SECURITY) || (IS_SUBDOMAIN(dom) && (!((ad_group_type & SDAP_AD_GROUP_TYPE_GLOBAL) || (ad_group_type & SDAP_AD_GROUP_TYPE_UNIVERSAL))))) { DEBUG(SSSDBG_TRACE_FUNC, "Filtering AD group [%s].\n", group_name);
*_need_filter = true; }
Thank you for the information, I do indeed see what you mean:
[sssd[be[ipa.engr.tamu.edu]]] [sdap_check_ad_group_type] (0x0400): Filtering AD group [linux_team@engr.tamu.edu].
Is there any way to force SSSD not to filter out the domain local groups? We use almost exclusively domain local groups in our AD because our users often reside in a different domain than the groups due to circumstances out of our control. This particular group (linux_team@engr.tamu.edu) only contains users in the same domain as the group, but this is often not the case. I had planned on creating a trust to both domains, the domain that contains the groups (and some users), and the domain that contains the bulk of our users.
On a very puzzling note, when I first set up my IPA domain, I was able to get back results from a 'getent group linux_team' that properly contained all of the group members. However, I could only get this to work on the IPA server. When I tried this on a client I got the results that I am seeing now. During the process of debugging I stopped getting any members returned on either client or server. This is particularly strange because all of my settings appear to be the same as before when it was working on the server.
On pe, 16 elo 2019, Blake Dworaczyk via FreeIPA-users wrote:
Thank you for the information, I do indeed see what you mean:
[sssd[be[ipa.engr.tamu.edu]]] [sdap_check_ad_group_type] (0x0400): Filtering AD group [linux_team@engr.tamu.edu].
Is there any way to force SSSD not to filter out the domain local groups? We use almost exclusively domain local groups in our AD because our users often reside in a different domain than the groups due to circumstances out of our control. This particular group (linux_team@engr.tamu.edu) only contains users in the same domain as the group, but this is often not the case. I had planned on creating a trust to both domains, the domain that contains the groups (and some users), and the domain that contains the bulk of our users.
Convert domain local group into a global group. This is the only way.
To make sure: this is a fundamental Active Directory design, not IPA. Active Directory requires to filter domain local groups at a domain boundary in Kerberos tickets. This means that a service in IPA domain cannot see any domain local membership from a trusted domain by definition. See MS-PAC 4.1.2.2, https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/55fc19f2...
On a very puzzling note, when I first set up my IPA domain, I was able to get back results from a 'getent group linux_team' that properly contained all of the group members. However, I could only get this to work on the IPA server. When I tried this on a client I got the results that I am seeing now. During the process of debugging I stopped getting any members returned on either client or server. This is particularly strange because all of my settings appear to be the same as before when it was working on the server.
See previous answer -- SSSD filters them when you are trying to login with a user that has these groups missing in MS-PAC.
I verified that Universal and Global groups work properly. Thank you for the information, this is definitely the issue.
I have one final question, I am able to see all of the group members in a 'domain local' group that has been placed into an IPA external group and then into a posix group on the IPA server, but not the clients. For example, on the server:
[root@ipa0 ~]# getent group linux_team@ipa.engr.tamu.edu linux_team@ipa.engr.tamu.edu:*:662759310:coe-william.luke@engr.tamu.edu,coe-andrew.eggleston@engr.tamu.edu,coe-blake.dworaczyk@engr.tamu.edu,coe-david.miller@engr.tamu.edu,coe-j.polasek@engr.tamu.edu,coe-matthew.mjelde@engr.tamu.edu,coe-steve.herring@engr.tamu.edu,coe-william.luke@engr.tamu.edu
But on the client: [root@ipa-test ~]# getent group linux_team@ipa.engr.tamu.edu linux_team@ipa.engr.tamu.edu:*:662759310:
Is the fact that I can see the group members on the IPA server despite being in a domain local group just a fluke? I can reproduce this with other groups as well. If I was able to do the same thing on the clients my problems would likely be solved.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Blake Dworaczyk