> 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.