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.