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. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org