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.
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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....
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
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@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
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@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.
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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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....
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@redhat.com 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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/
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)
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.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hearns -
Ratliff, John -
Sumit Bose