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
<jhrozek(a)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 <jhrozek(a)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
<jhrozek(a)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
<jhrozek(a)redhat.com> het volgende geschreven:
> > >>>>>
> > >>>>>
> > >>>>>> On 27 Jan 2016, at 17:50, Bolke de Bruin
<bdbruin(a)gmail.com> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>> Op 27 jan. 2016, om 17:46 heeft Jakub Hrozek
<jhrozek(a)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(a)ad.local
> > >>>>>>>> UID=1796201107(bolke(a)ad.local)
GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain
users@ad.local),1796201108(test(a)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:Administrator@win.trust.test,pkuser@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: extgroup(a)win.trust.test,
administrator(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org