Hello all, Apologies for the necromancy here, but there seems to be conflicting information regarding group enumeration within an IPA AD Trust, specifically, these tidbits:
> > >>>>>>> ad_users is an IPA group that contains an IPA external group that > > >>>>>>> contains the users, right? > > >>>>>> > > >>>>>> Correct. > > >>>> To confirm: Is the idea behind your patches that it will enumerate > > >>>> users in groups that have not logged before? Ie. I have no means to > > >>>> determine which users are in a group on the sssd/ipa side. According to this thread and its linked bug reports, this was addressed in SSSD versions >= 1.14.0-43. But, per the URL https://access.redhat.com/solutions/3597701 the following is stated: "Enumeration is not supported in IPA-AD trust environments." "This is an expected behaviour if SSSD is not enumerating all AD users/groups on IPA server or client after setting enumerate = True and subdomain_enumerate = True in sssd.conf." & "Enumeration' is not supported in IPA-AD trust environments. As per confirmation from IPA/SSSD engineering team, there is no plan on supporting enumeration with IPA-AD trusts as it just wouldn't scale with large AD domains." Our AD domain does permit enumeration as the sssd_nss.log on the IPA master didn't manifest a message stating that the domain does not support enumeration. Given the aforementioned information, is it correct to assume that current versions of SSSD and IPA do not support enumerating a group which contains trusted AD users who haven't logged in before/been queried via `groups`, `id`, or `getent passwd`? Thank you! John DeSantis Il giorno ven 29 gen 2016 alle ore 17:52 Jakub Hrozek <jhro...@redhat.com> ha scritto: > > On Fri, Jan 29, 2016 at 04:13:01PM +0100, Bolke de Bruin wrote: > > > > > Op 28 jan. 2016, om 21:44 heeft Jakub Hrozek <jhro...@redhat.com> het > > > volgende geschreven: > > > > > > On Thu, Jan 28, 2016 at 06:37:11PM +0100, Bolke de Bruin wrote: > > >> > > >>> Op 28 jan. 2016, om 18:03 heeft Jakub Hrozek <jhro...@redhat.com> het > > >>> volgende geschreven: > > >>> > > >>> On Wed, Jan 27, 2016 at 10:29:06PM +0100, Bolke de Bruin wrote: > > >>>> > > >>>>> Op 27 jan. 2016, om 22:25 heeft Jakub Hrozek <jhro...@redhat.com> het > > >>>>> volgende geschreven: > > >>>>> > > >>>>> > > >>>>>> On 27 Jan 2016, at 17:50, Bolke de Bruin <bdbr...@gmail.com> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> Op 27 jan. 2016, om 17:46 heeft Jakub Hrozek <jhro...@redhat.com> > > >>>>>>> het volgende geschreven: > > >>>>>>> > > >>>>>>> On Wed, Jan 27, 2016 at 05:42:02PM +0100, Bolke de Bruin wrote: > > >>>>>>>> Hello, > > >>>>>>>> > > >>>>>>>> I have sssd 1.13.00 working against FreeIPA 4.2 domain. This > > >>>>>>>> domain has a trust relationship with a active directory domain. > > >>>>>>>> > > >>>>>>>> One of the systems we are using requires to enumerate all users in > > >>>>>>>> groups by (unfortunate) design (Apache Ranger). This is done by > > >>>>>>>> using > > >>>>>>>> “getent group”. During this enumeration the full user list for a > > >>>>>>>> group that has a nested external member group* is not always > > >>>>>>>> returned so we thought to > > >>>>>>>> add “getent group mygroup” in order to get more details. > > >>>>>>>> Unfortunately this does not seem to work consistently: sometimes > > >>>>>>>> this gives information sometimes it does not: > > >>>>>>>> > > >>>>>>>> [root@master centos]# getent group ad_users > > >>>>>>>> ad_users:*:1950000004: > > >>>>>>>> > > >>>>>>>> [root@master centos]# id bolke@ad.local > > >>>>>>>> UID=1796201107(bolke@ad.local) GID=1796201107(bolke@ad.local) > > >>>>>>>> groepen=1796201107(bolke@ad.local),1796200513(domain > > >>>>>>>> users@ad.local),1796201108(test@ad.local) > > >>>>>>>> > > >>>>>>>> [root@master centos]# getent group ad_users > > >>>>>>>> ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local> > > >>>>>>>> > > >>>>>>>> If I clear the cache (sss_cache -E) the entry is gone again: > > >>>>>>>> > > >>>>>>>> [root@master centos]# getent group ad_users > > >>>>>>>> ad_users:*:1950000004: > > >>>>>>>> > > >>>>>>>> My question is how do I get sssd to enumerate *all users* in a > > >>>>>>>> group consistently? > > >>>>>>>> > > >>>>>>>> Thanks! > > >>>>>>>> Bolke > > >>>>>>> > > >>>>>>> ad_users is an IPA group that contains an IPA external group that > > >>>>>>> contains the users, right? > > >>>>>> > > >>>>>> Correct. > > >>>>>> > > >>>>>>> > > >>>>>>> If so, then you're hitting: > > >>>>>>> https://fedorahosted.org/sssd/ticket/2522 > > >>>>>>> I've been working on fixing this lately and have some patches, > > >>>>>>> would you > > >>>>>>> like to test them? > > >>>>>> > > >>>>>> Sure. I would prefer RPMs (this is on RHEL 6 and 7) but I can > > >>>>>> compile if required. > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> This issue must be fixed with sssd on the IPA server itself. Please > > >>>>> send me your exact sssd version (rpm -q output) and I'll build you a > > >>>>> test package tomorrow.. > > >>>>> > > >>>> > > >>>> rpm -qa sssd* > > >>>> sssd-common-pac-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-krb5-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-client-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-krb5-common-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-ipa-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-ldap-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-proxy-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-common-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-ad-1.13.0-40.el7_2.1.x86_64 > > >>>> sssd-1.13.0-40.el7_2.1.x86_64 > > >>>> > > >>>> > > >>>> To confirm: Is the idea behind your patches that it will enumerate > > >>>> users in groups that have not logged before? Ie. I have no means to > > >>>> determine which users are in a group on the sssd/ipa side. > > >>> > > >>> Hello Bolke, please try these builds: > > >>> https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.2-external-groups/ > > >>> > > >>> These do resolve the AD members via an IPA group for me: > > >>> # rm -f /var/lib/sss/db/cache_ipa.test.ldb > > >>> # systemctl start sssd.service > > >>> # getent group l_idm_admin > > >>> > > >>> l_idm_admin:*:1190000005:administra...@win.trust.test,pku...@win.trust.test > > >>> > > >>> The groups are defined like this: > > >>> # ipa group-show l_idm_admin > > >>> Group name: l_idm_admin > > >>> GID: 1190000005 > > >>> Member groups: l_idm_admin_external > > >>> # ipa group-show l_idm_admin_external > > >>> Group name: l_idm_admin_external > > >>> Member of groups: l_idm_admin > > >>> External member: extgr...@win.trust.test, administra...@win.trust.test > > >>> > > >>> (So the code even crawls the AD group and unrolls the pkuser from there) > > >> > > >> Cool, but the files are currently inaccessible (403). Would you mind > > >> updating the permissions? > > > > > > My fault, try now. > > > _______________________________________________ > > > > Works fine in my small testing setup. I will do some more testing across > > the weekend, but this helps already quite a lot. > > My company might reach out on the corporate channels for this as we are > > planning to deploy quite a sizable IPA cluster. > > I'm glad this helped. I'll be also interested if you see any oddities -- > if you do, please add debug_level=10 to the sssd.conf's [domain] section, > run sss_cache -E, request the group and send me the log files. > > Please note that at the moment we are aware of an issue with idviews, > where if you define an alternate name, getent group would still return > the original name. We are working on a fix there, but we don't have one yet. > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
