[SSSD] Re: Question: LDAP provider doesn't show group member

[Jakub Hrozek]

On Thu, Sep 22, 2016 at 12:32:45PM +0200, Petr Cech wrote:
> Hi,
>
> I am working on [1] LDAP provider doesn't show group member
>
> There is one point what I am not able to understand clearly.
>
> I prepared environment by:
>
> ipa user-add --first=Test --last=User1 --email=[e-mail] cmt_user_1
> ipa group-add cmt_group_1
> ipa group-add-member --users=cmt_user_1 cmt_group_1
>
> And sssd.conf is attached. I used patch 0007 [2] to simpler grep of
> interesting messages. And I applied patches 0001 to 0006 (I am waiting for
> their push to master).
>
> [1] https://fedorahosted.org/sssd/ticket/3186
> [2] 0007-WIP-Debuging-of-attr-member-in-ldap-answer.patch
>
> What I saw is:
>
> # COMMAND ON CLIENT:
> [root@mirach sssd]# systemctl daemon-reload && sudo su -c "truncate -s0
> /var/log/sssd/*.log" && sudo su -c "rm -f /var/lib/sss/db/*" && sudo su -c
> "rm -f /var/lib/sss/mc/*" && sudo systemctl restart sssd.service && getent
> group cmt_group_1 && grep '>>>' *.log
>
> # There is user missing:
> cmt_group_1:*:1703800166:
>
> # SSSD LOG:
> [sdap_get_generic_ext_step] (0x0400): >>> calling ldap_search_ext with [(&(cn=cmt_group_1)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=groups,cn=accounts,dc=beta].
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [objectClass]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [cn]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [userPassword]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [gidNumber]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [member]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs:
> [modifyTimestamp]
> [sdap_get_generic_ext_step] (0x1000): >>> Requesting attrs: [entryUSN]
> [sdap_parse_entry] (0x0080): >>> ----- filter map:
> [sdap_parse_entry] (0x0080): >>>   [posixGroup]
> [sdap_parse_entry] (0x0080): >>>   [(null)]
> [sdap_parse_entry] (0x0080): >>>   [cn]
> [sdap_parse_entry] (0x0080): >>>   [userPassword]
> [sdap_parse_entry] (0x0080): >>>   [gidNumber]
> [sdap_parse_entry] (0x0080): >>>   [member]
> [sdap_parse_entry] (0x0080): >>>   [(null)]
> [sdap_parse_entry] (0x0080): >>>   [(null)]
> [sdap_parse_entry] (0x0080): >>>   [modifyTimestamp]
> [sdap_parse_entry] (0x0080): >>>   [entryUSN]
> [sdap_parse_entry] (0x0080): >>>   [(null)]
> [sdap_parse_entry] (0x0080): >>>   [(null)]
> [sdap_parse_entry] (0x0080): >>> ----- attributes in ldap answer:
> [sdap_parse_entry] (0x0020): >>>   [objectClass]
> [sdap_parse_entry] (0x0020): >>>   [cn]
> [sdap_parse_entry] (0x0020): >>>   [gidNumber]
> [sdap_parse_entry] (0x0020): >>>   [modifyTimestamp]
> [sdap_parse_entry] (0x0020): >>>   [entryUSN]
> [sdap_get_groups_process] (0x0400): >>> Group contains:
> [sdap_get_groups_process] (0x0400): >>>   0: [originalDN]
> [sdap_get_groups_process] (0x0400): >>>   1: [name]
> [sdap_get_groups_process] (0x0400): >>>   2: [gidNumber]
> [sdap_get_groups_process] (0x0400): >>>   3: [originalModifyTimestamp]
> [sdap_get_groups_process] (0x0400): >>>   4: [entryUSN]
> [sdap_nested_group_process_send] (0x2000): >>> About to process group
> [cn=cmt_group_1,cn=groups,cn=accounts,dc=beta]
>
> # LDAPSEARCH ON LDAP SERVER:
> [pcech@algol ~]$ ldapsearch -H ldap://localhost -D
> uid=admin,cn=users,cn=accounts,dc=beta -w myspulin -b
> cn=groups,cn=accounts,dc=beta "(&(cn=cmt_group_1)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
>
> # extended LDIF
> #
> # LDAPv3
> # base <cn=groups,cn=accounts,dc=beta> with scope subtree
> # filter: (&(cn=cmt_group_1)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))
> # requesting: ALL
> #
>
> # cmt_group_1, groups, accounts, beta
> dn: cn=cmt_group_1,cn=groups,cn=accounts,dc=beta
> objectClass: ipaobject
> objectClass: top
> objectClass: ipausergroup
> objectClass: posixgroup
> objectClass: groupofnames
> objectClass: nestedgroup
> cn: cmt_group_1
> ipaUniqueID: db0b564e-7efe-11e6-a757-5254001a3efa
> gidNumber: 1703800166
> member: uid=cmt_user_1,cn=users,cn=accounts,dc=beta
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> Question is why didn't SSSD obtain member attribute if I saw it in
> ldapsearch call? Is there something what I miss?
>
> Lukas pointed out that it may not be the correct way to use IPA for handling
> users in groups in LDAP server. I understand I am working on AD case too.
>
> But -- is it really possible to get different data via SSSD and ldapsearch()
> with the same filter and base?

Yes, because your ldapsearch authenticates as a user DN, but sssd
doesn't authenticate by default.

Try adding:
ldap_sasl_mech = gssapi
krb5_server = algol.beta
krb5_realm = BETA

to your sssd.conf.

I wonder if this is visible in server logs for future..