sssd id getent and secondary groups in active directory

[Ratliff, John]

I'm using SSSD and realmd to join a machine to active directory.

When I run id on my user, I only get the primary group. If I run getent
group "groupname", it works...sometimes. Other times, it returns blank.

This is on a CentOS 7 machine (sssd 1.16.0)

$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)

$ getent group ssh-test-users2
ssh-test-users2:*:752629809:

$ sss_cache -E
$ getent group ssh-test-users2
ssh-test-users2:*:752629809:jdratlif

$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)

$ getent group ssh-test-users2
ssh-test-users2:*:752629809:

$ id jdratlif
uid=752603752(jdratlif) gid=1572000513(domain users)
groups=1572000513(domain users)

This was all in the span of 2 minutes.

Let me know what other information would be helpful.

Thanks.

-- 
John Ratliff
Research Storage / UITS / Pervasive Technology Institute
Indiana University | https://pti.iu.edu

[Sumit Bose]

On Thu, Jul 05, 2018 at 07:36:19PM +0000, Ratliff, John wrote:
>  I'm using SSSD and realmd to join a machine to active directory.
>  
>  When I run id on my user, I only get the primary group. If I run getent
>  group "groupname", it works...sometimes. Other times, it returns blank.
>  
>  This is on a CentOS 7 machine (sssd 1.16.0)
>  
>  $ id jdratlif
>  uid=752603752(jdratlif) gid=1572000513(domain users)
>  groups=1572000513(domain users)
>  
>  $ getent group ssh-test-users2
>  ssh-test-users2:*:752629809: 
What is the scope is the group ('domain local', 'global' or
'universal')?

Did you log in as jdratlif before running those commands?

>  
>  $ sss_cache -E
>  $ getent group ssh-test-users2
>  ssh-test-users2:*:752629809:jdratlif
>  
>  $ id jdratlif
>  uid=752603752(jdratlif) gid=1572000513(domain users)
>  groups=1572000513(domain users)
>  
>  $ getent group ssh-test-users2
>  ssh-test-users2:*:752629809:
>  
>  $ id jdratlif
>  uid=752603752(jdratlif) gid=1572000513(domain users)
>  groups=1572000513(domain users)
>  
>  This was all in the span of 2 minutes.
>  
>  Let me know what other information would be helpful. 
Debug logs with debug_level=9 would be helpful, especially the domain
logs and the sssd_nss.log. Please see
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for
details.

bye,
Sumit

>  
>  Thanks.
>  
>  -- 
>  John Ratliff
>  Research Storage / UITS / Pervasive Technology Institute
>  Indiana University | https://pti.iu.edu 


>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Ratliff, John]

On Thu, 2018-07-05 at 21:44 +0200, Sumit Bose wrote:
>  On Thu, Jul 05, 2018 at 07:36:19PM +0000, Ratliff, John wrote:
>  > I'm using SSSD and realmd to join a machine to active directory.
>  > 
>  > When I run id on my user, I only get the primary group. If I run
>  > getent
>  > group "groupname", it works...sometimes. Other times, it returns
>  > blank.
>  > 
>  > This is on a CentOS 7 machine (sssd 1.16.0)
>  > 
>  > $ id jdratlif
>  > uid=752603752(jdratlif) gid=1572000513(domain users)
>  > groups=1572000513(domain users)
>  > 
>  > $ getent group ssh-test-users2
>  > ssh-test-users2:*:752629809:
>  
>  What is the scope is the group ('domain local', 'global' or
>  'universal')?
>  
>  Did you log in as jdratlif before running those commands?
>   
The scope is universal.

I was logged in as root at the time. But I've logged in as that user
prior to running those commands.

I logged in as the user and ran the commands again with the same
result.

It seems if I clear the cache, then run the getent command, it has the
group membership. But when I run the id command, the getent command
loses the group membership. I cannot get it back without clearing the
sssd cache.

>  > 
>  > $ sss_cache -E
>  > $ getent group ssh-test-users2
>  > ssh-test-users2:*:752629809:jdratlif
>  > 
>  > $ id jdratlif
>  > uid=752603752(jdratlif) gid=1572000513(domain users)
>  > groups=1572000513(domain users)
>  > 
>  > $ getent group ssh-test-users2
>  > ssh-test-users2:*:752629809:
>  > 
>  > $ id jdratlif
>  > uid=752603752(jdratlif) gid=1572000513(domain users)
>  > groups=1572000513(domain users)
>  > 
>  > This was all in the span of 2 minutes.
>  > 
>  > Let me know what other information would be helpful.
>  
>  Debug logs with debug_level=9 would be helpful, especially the domain
>  logs and the sssd_nss.log. Please see
>  https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for
>  details. 
I have attached the requested logs.

Thanks.

>  
>  bye,
>  Sumit

[Sumit Bose]

On Thu, Jul 05, 2018 at 08:09:55PM +0000, Ratliff, John wrote:
>  On Thu, 2018-07-05 at 21:44 +0200, Sumit Bose wrote:
>  > On Thu, Jul 05, 2018 at 07:36:19PM +0000, Ratliff, John wrote:
>  > > I'm using SSSD and realmd to join a machine to active directory.
>  > > 
>  > > When I run id on my user, I only get the primary group. If I run
>  > > getent
>  > > group "groupname", it works...sometimes. Other times, it returns
>  > > blank.
>  > > 
>  > > This is on a CentOS 7 machine (sssd 1.16.0)
>  > > 
>  > > $ id jdratlif
>  > > uid=752603752(jdratlif) gid=1572000513(domain users)
>  > > groups=1572000513(domain users)
>  > > 
>  > > $ getent group ssh-test-users2
>  > > ssh-test-users2:*:752629809:
>  > 
>  > What is the scope is the group ('domain local', 'global' or
>  > 'universal')?
>  > 
>  > Did you log in as jdratlif before running those commands?
>  > 
>  
>  The scope is universal.
>  
>  I was logged in as root at the time. But I've logged in as that user
>  prior to running those commands.
>  
>  I logged in as the user and ran the commands again with the same
>  result.
>  
>  It seems if I clear the cache, then run the getent command, it has the
>  group membership. But when I run the id command, the getent command
>  loses the group membership. I cannot get it back without clearing the
>  sssd cache. 
Thank you for the logs. It looks like the tokenGroups LDAP lookup which
SSSD uses be default does not work as expected because it returns no
results:

(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_print_server] (0x2000): Searching
134.68.239.131:389
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with [no filter][CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [tokenGroups]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_get_generic_ext_step] (0x2000):
ldap_search_ext called, msgid = 15
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_add] (0x2000): New operation 15
timeout 6
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_result] (0x2000): Trace:
sh[0x564b5d62f090], connected[1], ops[(nil)], ldap[0x564b5d62d1e0]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_result] (0x2000): Trace:
end of ldap_result list
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_result] (0x2000): Trace:
sh[0x564b5d61dd00], connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_message] (0x4000): Message
type: [LDAP_RES_SEARCH_ENTRY]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry] (0x1000): OriginalDN:
[CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry] (0x1000): Entry has
no attributes [0(Success)]!?
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_result] (0x2000): Trace:
sh[0x564b5d61dd00], connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_process_message] (0x4000): Message
type: [LDAP_RES_SEARCH_RESULT]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_get_generic_op_finished] (0x0400):
Search result: Success(0), no errmsg set
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_destructor] (0x2000): Operation
15 finished
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_get_ad_tokengroups_done] (0x1000):
No tokenGroups entries for [jdratlif(a)ads.iu.edu]
(Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [ldb] (0x4000): start ldb transaction
(nesting: 0)

this makes SSSD assume that the user is not a member of any group.

Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
details) and check if the group memberships are reported more reliable.

Afaik the issue with the tokenGroups might indicate that the used AD DC
has issues reaching a Global Catalog server.

HTH

bye,
Sumit

> 
> > > 
> > > $ sss_cache -E
> > > $ getent group ssh-test-users2
> > > ssh-test-users2:*:752629809:jdratlif
> > > 
> > > $ id jdratlif
> > > uid=752603752(jdratlif) gid=1572000513(domain users)
> > > groups=1572000513(domain users)
> > > 
> > > $ getent group ssh-test-users2
> > > ssh-test-users2:*:752629809:
> > > 
> > > $ id jdratlif
> > > uid=752603752(jdratlif) gid=1572000513(domain users)
> > > groups=1572000513(domain users)
> > > 
> > > This was all in the span of 2 minutes.
> > > 
> > > Let me know what other information would be helpful.
> > 
> > Debug logs with debug_level=9 would be helpful, especially the domain
> > logs and the sssd_nss.log. Please see
> > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for
> > details.
> 
> I have attached the requested logs.
> 
> Thanks.
> 
> > 
> > bye,
> > Sumit

[Ratliff, John]

On Fri, 2018-07-06 at 10:55 +0200, Sumit Bose wrote:
>  On Thu, Jul 05, 2018 at 08:09:55PM +0000, Ratliff, John wrote:
>  > 
>  
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_print_server]
>  (0x2000): Searching 134.68.239.131:389
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>  [no filter][CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =
>  15
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_add]
>  (0x2000): New operation 15 timeout 6
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_result] (0x2000): Trace: sh[0x564b5d62f090],
>  connected[1], ops[(nil)], ldap[0x564b5d62d1e0]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_result] (0x2000): Trace: end of ldap_result list
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_message] (0x4000): Message type:
>  [LDAP_RES_SEARCH_ENTRY]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  (0x1000): OriginalDN: [CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  (0x1000): Entry has no attributes [0(Success)]!?
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_process_message] (0x4000): Message type:
>  [LDAP_RES_SEARCH_RESULT]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_get_generic_op_finished] (0x0400): Search result: Success(0),
>  no errmsg set
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_op_destructor] (0x2000): Operation 15 finished
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  [sdap_get_ad_tokengroups_done] (0x1000): No tokenGroups entries for [
>  jdratlif(a)ads.iu.edu]
>  (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [ldb] (0x4000):
>  start ldb transaction (nesting: 0)
>  
>  this makes SSSD assume that the user is not a member of any group.
>  
>  Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
>  details) and check if the group memberships are reported more
>  reliable.
>  
>  Afaik the issue with the tokenGroups might indicate that the used AD
>  DC
>  has issues reaching a Global Catalog server. 
Thank you for the information. I don't know what to do about it at the
moment. Adding that parameter makes id freeze when I run it. It seems
to be unable to handle it when this parameter exists.

I'm unclear what you mean by AD DC has issues reaching the global
catalog server. Do you mean my sever is having trouble, or the DC
itself?

One more thing I found interesting. I made another RHEL7 box and used
winbind instead of sssd and group membership works fine there.

I made another virtual machine and tried realmd/sssd again. I took it
off the virtual machine NAT and gave it a public IP and disabled the
firewall to make sure that wasn't causing any issues, but there was no
change.

This still feel like an sssd configuration problem to me, though I'm
not sure what to do about it at the moment.

Thanks for your assitance.

-- 
John Ratliff
Research Storage / UITS / Pervasive Technology Institute
Indiana University | https://pti.iu.edu

[Jakub Hrozek]

On Fri, Jul 06, 2018 at 01:41:38PM +0000, Ratliff, John wrote:
>  
>  
>  On Fri, 2018-07-06 at 10:55 +0200, Sumit Bose wrote:
>  > On Thu, Jul 05, 2018 at 08:09:55PM +0000, Ratliff, John wrote:
>  > > 
>  > 
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_print_server]
>  > (0x2000): Searching 134.68.239.131:389
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>  > [no filter][CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =
>  > 15
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_add]
>  > (0x2000): New operation 15 timeout 6
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_result] (0x2000): Trace: sh[0x564b5d62f090],
>  > connected[1], ops[(nil)], ldap[0x564b5d62d1e0]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_result] (0x2000): Trace: end of ldap_result list
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_message] (0x4000): Message type:
>  > [LDAP_RES_SEARCH_ENTRY]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  > (0x1000): OriginalDN: [CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  > (0x1000): Entry has no attributes [0(Success)]!?
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_process_message] (0x4000): Message type:
>  > [LDAP_RES_SEARCH_RESULT]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0),
>  > no errmsg set
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_op_destructor] (0x2000): Operation 15 finished
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > [sdap_get_ad_tokengroups_done] (0x1000): No tokenGroups entries for [
>  > jdratlif(a)ads.iu.edu]
>  > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [ldb] (0x4000):
>  > start ldb transaction (nesting: 0)
>  > 
>  > this makes SSSD assume that the user is not a member of any group.
>  > 
>  > Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
>  > details) and check if the group memberships are reported more
>  > reliable.
>  > 
>  > Afaik the issue with the tokenGroups might indicate that the used AD
>  > DC
>  > has issues reaching a Global Catalog server.
>  
>  Thank you for the information. I don't know what to do about it at the
>  moment. Adding that parameter makes id freeze when I run it. It seems
>  to be unable to handle it when this parameter exists. 
If the group membership is very deep and complex, running id might take
a very long time because without using tokenGroups, the group hierarchy
must be traversed from the user "up".

Looking at the debug logs might give a clue about what the sssd is
doing.

>  
>  I'm unclear what you mean by AD DC has issues reaching the global
>  catalog server. Do you mean my sever is having trouble, or the DC
>  itself?
>  
>  One more thing I found interesting. I made another RHEL7 box and used
>  winbind instead of sssd and group membership works fine there.
>  
>  I made another virtual machine and tried realmd/sssd again. I took it
>  off the virtual machine NAT and gave it a public IP and disabled the
>  firewall to make sure that wasn't causing any issues, but there was no
>  change.
>  
>  This still feel like an sssd configuration problem to me, though I'm
>  not sure what to do about it at the moment.
>  
>  Thanks for your assitance.
>  
>  -- 
>  John Ratliff
>  Research Storage / UITS / Pervasive Technology Institute
>  Indiana University | https://pti.iu.edu 


>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[John Hearns]

One stupid question - is there an easy(ish) way to tell how deep a group
heirarachy exists on a particular site?

On 9 July 2018 at 13:36, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Fri, Jul 06, 2018 at 01:41:38PM +0000, Ratliff, John wrote:
>  >
>  >
>  > On Fri, 2018-07-06 at 10:55 +0200, Sumit Bose wrote:
>  > > On Thu, Jul 05, 2018 at 08:09:55PM +0000, Ratliff, John wrote:
>  > > >
>  > >
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_print_server]
>  > > (0x2000): Searching 134.68.239.131:389
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
>  > > [no filter][CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [tokenGroups]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =
>  > > 15
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_op_add]
>  > > (0x2000): New operation 15 timeout 6
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_result] (0x2000): Trace: sh[0x564b5d62f090],
>  > > connected[1], ops[(nil)], ldap[0x564b5d62d1e0]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_result] (0x2000): Trace: end of ldap_result list
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  > > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_message] (0x4000): Message type:
>  > > [LDAP_RES_SEARCH_ENTRY]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  > > (0x1000): OriginalDN: [CN=jdratlif,OU=Accounts,DC=ads,DC=iu,DC=edu].
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [sdap_parse_entry]
>  > > (0x1000): Entry has no attributes [0(Success)]!?
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_result] (0x2000): Trace: sh[0x564b5d61dd00],
>  > > connected[1], ops[0x564b5d63a360], ldap[0x564b5d5a0c60]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_process_message] (0x4000): Message type:
>  > > [LDAP_RES_SEARCH_RESULT]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0),
>  > > no errmsg set
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_op_destructor] (0x2000): Operation 15 finished
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]]
>  > > [sdap_get_ad_tokengroups_done] (0x1000): No tokenGroups entries for [
>  > > jdratlif(a)ads.iu.edu]
>  > > (Thu Jul  5 16:04:42 2018) [sssd[be[ads.iu.edu]]] [ldb] (0x4000):
>  > > start ldb transaction (nesting: 0)
>  > >
>  > > this makes SSSD assume that the user is not a member of any group.
>  > >
>  > > Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
>  > > details) and check if the group memberships are reported more
>  > > reliable.
>  > >
>  > > Afaik the issue with the tokenGroups might indicate that the used AD
>  > > DC
>  > > has issues reaching a Global Catalog server.
>  >
>  > Thank you for the information. I don't know what to do about it at the
>  > moment. Adding that parameter makes id freeze when I run it. It seems
>  > to be unable to handle it when this parameter exists.
>
>  If the group membership is very deep and complex, running id might take
>  a very long time because without using tokenGroups, the group hierarchy
>  must be traversed from the user "up".
>
>  Looking at the debug logs might give a clue about what the sssd is
>  doing.
>
>  >
>  > I'm unclear what you mean by AD DC has issues reaching the global
>  > catalog server. Do you mean my sever is having trouble, or the DC
>  > itself?
>  >
>  > One more thing I found interesting. I made another RHEL7 box and used
>  > winbind instead of sssd and group membership works fine there.
>  >
>  > I made another virtual machine and tried realmd/sssd again. I took it
>  > off the virtual machine NAT and gave it a public IP and disabled the
>  > firewall to make sure that wasn't causing any issues, but there was no
>  > change.
>  >
>  > This still feel like an sssd configuration problem to me, though I'm
>  > not sure what to do about it at the moment.
>  >
>  > Thanks for your assitance.
>  >
>  > --
>  > John Ratliff
>  > Research Storage / UITS / Pervasive Technology Institute
>  > Indiana University | https://pti.iu.edu
>
>
>
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@
>  lists.fedorahosted.org/message/2FPUT7PHHJAYYKS57PUXPOG57OIJMGGW/
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@
>  lists.fedorahosted.org/message/IJQRATBXMWV7E27RUJ5ESO3D53BTKPP6/
>

[Jakub Hrozek]

On Mon, Jul 09, 2018 at 01:45:57PM +0200, John Hearns wrote:
>  One stupid question - is there an easy(ish) way to tell how deep a
> group
>  heirarachy exists on a particular site? 
I don't think so, without trying. However, looking at the code now, the
default nesting limit is only two levels deep by default and should
apply also to get-user-groups (previously I thought it applies to
get-group-members only)

[Ratliff, John]

On Fri, 2018-07-06 at 10:55 +0200, Sumit Bose wrote:
>  
>  this makes SSSD assume that the user is not a member of any group.
>  
>  Please try to set 'ldap_use_tokengroups=False' (see man sssd-ldap for
>  details) and check if the group memberships are reported more
>  reliable.
>  
>  Afaik the issue with the tokenGroups might indicate that the used AD
>  DC
>  has issues reaching a Global Catalog server.
>   
I've been talking to some people here more familiar with AD than I am.
They say that there is a setting in AD that prevents reading of
tokenGroups without a permission change. This is a behavior that is a
remnant from pre-Windows 2003 AD controllers. My machine needs to be
added to a Windows Authorization Activation Group to get the right
permissions.

I don't fully understand, but it seems as though tokenGroup is a
privileged property, and until I have the right permissions, I won't be
able to access this property, which is probably why secondary groups
are not working.

Once I have been put in the new group, I'll let you know if that
resolves the issue.

-- 
John Ratliff
Research Storage / UITS / Pervasive Technology Institute
Indiana University | https://pti.iu.edu