On Thu, Aug 22, 2019 at 11:11:18AM -0000, Jamal Mahmoud wrote:
> We've been experiencing an intermittent issue relating to SSSD v1.15.2, we 
> are running CentOS7.4 on our workstations. We use SSSD to communicate with 
> our Active Directory to pull users for auth. The majority of users have a 
> certain group set as their primary group and some departments have it as an 
> additional group. Most of the time this group works fine on all workstations 
> but sometimes we will run into an issue where a user can no longer access the 
> privileges attained from the group. For users who have it set as primary, the 
> id command returns a gid without the name and for users who have it as an 
> additional group, it doesn't appear at all. I've managed to capture output 
> from sssd services and there are a few interesting lines that I thought I 
> should share with you as I don't understand what they mean. I should add that 
> when this error occurs, restarting the sssd.service usually works, if not, 
> sss_cache -E works, and if that doesn't work, removing the workstation from 
> the realm, de
>  leting the sssd db and rejoining seems to be the final trick that works. 

I'm not sure if this is a helpful response, but I would strongly
encourage to upgrade to 1.16.x. It is quite stable and 1.15.x is not
going to receive any fixes from either RH or upstream.

> 
> Regarding the logs, the symptoms I noted are below: 
> 1. getent group *mygroup* returns nothing
> 2. id user returns a gid without a resolved group name (if it is a primary 
> group)
> 3. I had to leave the realm, delete the db and rejoin to get sssd to work 
> properly again. 
> 
> in sssd_nss.log i found this entry: 
> (Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete 
> group object for gr...@domain.com[0]! Skipping

An 'incomplete' group in sssd-lingo is an optimization stub. In cases
where the flow doesn't need the full group to be resolved, it is not,
only an entry that is internally marked as incomplete is added to the
cache.

It would be more interesting to see sssd logs when you call "getent
group $gidnumber" for the group whose number does not resolve.

> 
> and in the sssd_domain.com.log:
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged 
> accounts,DC=domain,DC=com] is unknown object
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x0400): More members were missing than the 
> deref threshold
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group 
> [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] 
> [sdap_nested_group_process_send] (0x2000): Dereferencing members of group 
> [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] 
> (0x2000): Server supports ASQ
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] 
> (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place 
> St,OU=Offices,DC=domain,DC=com] using ASQ
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] 
> (0x2000): Searching XXX.XXX.XXX.XXX:389
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] 
> (0x0400): WARNING: Disabling paging because scope is set to base.
> (Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with [no 
> filter][CN=GROUP,OU=Security,OU=Groups,OU=Place 
> St,OU=Offices,DC=domain,DC=com].

This looks fine, it's just sssd looking up all the members of the group.

> 
> I've redacted the entries but I'm sure you can get the jist of whats 
> happening here hopefully. If there is anything else you need, please do not 
> hesitate to ask! If these logs don't point to anything could you maybe 
> provide some advice on what to look for when parsing? 
> 
> Thanks,
> Jamal
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

Reply via email to