Hi Jackub

here is the output:
[root@10-0-0-84 ~]# ldbsearch -H /var/lib/sss/db/cache_hp.com.ldb objectclass=group
asq: Unable to register control with rootdse!
# returned 0 records
# 0 entries
# 0 referrals
[root@10-0-0-84 ~]# id nick@example.com
uid=15001(xiao-liang.xu) gid=20000(my-testing-group-at-world-wide-space) groups=20000(my-testing-group-at-world-wide-space)
[root@10-0-0-84 ~]# getent group -s -sss test-group
[root@10-0-0-84 ~]#

[root@10-0-0-84 ~]# ssh -l nick@example.com localhost
Password: 
nick@example.com@localhost's password: 
Connection closed by ::1
[root@10-0-0-84 ~]#

the "Connection closed by..." is because of the sssd conf:
access_provider = simple
# specify the long group name (as in 'cn')
simple_allow_groups = my-testing-group-at-world-wide-space


  Thanks & Best Regards!

                  ///
                 (. .)
  --------ooO--(_)--Ooo--------
  |           Nick Tan           |
  ------------------------------------


On Mon, Aug 11, 2014 at 3:40 PM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Mon, Aug 11, 2014 at 09:03:17AM +0200, Jakub Hrozek wrote:
> On Sat, Aug 09, 2014 at 07:44:58AM +0800, XuQing Tan wrote:
> > Hi Jackub
> >
> > attached is the sssd domain log, in the log i only saw the short group name
> > "test-group"
> > the command "id nick" output:
> > uid=15001(nick) gid=20000(my-testing-group-at-world-wide-space)
> > groups=20000(my-testing-group-at-world-wide-space)
> > thanks
>
> Thanks for the logs, they seem about right to me:
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_initgr_rfc2307_next_base] (0x0400): Searching for groups with base [ou=Groups,o=example.com]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(memberuid=nick)(objectclass=posixGroup)(description=*)(&(gidNumber=*)(!(gidNumber=0))))][ou=Groups,o=example.com].
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [description]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 4
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x11b1a80], connected[1], ops[0x126ecc0], ldap[0x11b1f80]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x11b1a80], connected[1], ops[0x126ecc0], ldap[0x11b1f80]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [description]
> (Fri Aug  8 23:39:17 2014) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [modifyTimestamp]
>
> You can see that the description attribute was requested. I will run a
> local test first, perhaps we can proceed with some more debugging then.

Sorry, works for me fine here. Are you sure you don't have a group with
the same GID on the system in /etc/group or in another domain?

Can you run a more isolated test?

service sssd stop
rm -f /var/lib/sss/db/cache_*
service sssd start
getent group -s -sss $groupname_in_description

If you still don't see the groupname you'd expect, can you examine the
cache?

yum -y install ldb-tools
ldbsearch -H /var/lib/sss/db/cache_$domain.ldb objectclass=group

The last command should show the group entry exactly as stored in the
cache.
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users