On 2019-11-15 06:10, Sumit Bose wrote: > On Fri, Nov 15, 2019 at 04:57:27AM -0800, Jim Burwell wrote: >> On 2019-11-15 04:25, Jamal Mahmoud wrote: >>>> On Fri, Nov 15, 2019 at 10:58:17AM -0000, Jamal Mahmoud wrote: >>>> >>>> Ok, do you know if the LDAP attributes uidNumber and gidNumber are >>>> replicated to the Global Catalog in your environment? By default they >>>> are not. >>>> >>>> You can check this manually as well with ldapsearch on the Global >>>> Catalog port 3268: >>>> >>>> ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b >>>> 'DC=your,DC=ad,DC=domain' samAccountName=groupname >>>> >>>> If gidNumber is missing in the Global Catalog object please try if >>>> setting >>>> >>>> ad_enable_gc = False >>>> >>>> in the [domain/...] section of sssd.conf makes the group lookup more >>>> reliable. >>>> >>>> bye, >>>> Sumit >>> Hi Sumit, >>> >>> I'm just after checking and you are correct! the ldap search through the >>> Global Catalog does not return any POSIX attributes, we're going to apply >>> this patch and see if the errors stop occurring. If this is the solution I >>> owe you a drink (or 5). >>> >>> Thanks, >>> Jamal >> >> Yep. The docs say that all those POSIX attributes should be marked as >> being part of the GC, which they aren't by default. You need to use the >> AD schema too to do that IIRC. >> >> I've also encountered issues with groups going missing, and in fact I'm >> working such an issue now. In our case, all the POSIX stuff is >> replicated to the GC. What happens is that the user's groups are fine >> for a long time (8-10 hours), then either a single group vanishes, OR >> all but their login group vanishes. The only thing that brings it back > Hi, > > are the group from the domain the client is joined to or from a > different domain in the forest? Same domain. > >> immediately is stopping SSSD, removing /var/lib/sssd/db/*, and >> restarting it. Then the groups will be back for that semi-random period. >> >> I had another case of this issue a few weeks ago. But in this case it >> turned out to be that there was an automated process on the AD that was >> removing users from groups, then adding them back shortly after. It > Are the groups being removed as well during this process and then added > back with the same name?
I'm not positive about that. I presumed that the groups themselves were being left in place and users were just being removed from the group then re-added by an automated process. But I'll inquire as to whether this was a case. I have doubts because the groups exist with the proper gidNumber, which I don't believe these automated process handles. > > Can you share your sssd.conf? # # sssd.conf for SSSD versions which have the AD provider module # (preferred method) # [sssd] config_file_version = 2 domains = {{ krb5_realm }} services = nss, pam, pac # remove PAC if it causes slow/failed login #services = nss, pam # uncomment for heavy debugging # debug_level = 0x37F0 [nss] # in case home dir isn't defined in AD/ldap unixHomeDirectory fallback_homedir = /h/%u [pam] # debugging #pam_verbosity = 5 # custom messages pam_account_expired_message = Account Expired pam_account_locked_message = Account Locked # domain section [domain/{{ krb5_realm }}] # uncomment for heavy debugging # debug_level = 0x37F0 #ad_gpo_access_control = permissive # disabled, causes issues w/ some OSes ad_gpo_access_control = disabled # Use AD provider id_provider = ad access_provider = ad auth_provider = ad chpass_provider = ad ldap_id_mapping = False cache_credentials = True ldap_schema = ad # Search base ldap_search_base = dc=widgetco,dc=com # Speed up search with narrowed user search base if required #ldap_user_search_base = OU=Users,OU=Corp,DC=widgetco,DC=com ldap_user_object_class = user # Speed up search if required. See sssd-ldap man page for how to # specify complex search bases with multiple bases, etc. # ldap_group_search_base = ou=users,dc=widgetco,dc=com ldap_group_object_class = group # Use AD unix attributes instead of generating UID/GID, etc ldap_id_mapping = False # where AD keeps these attributes ldap_user_name = sAMAccountName ldap_user_home_directory = unixHomeDirectory # expire policies ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = True # specify only if needed (DNS SRV records used otherwise) #ad_server = dcwidgetcoprim.widgetco.com # Let DHCP client handle this dyndns_update = false # This greatly improves login speed, but getent group groupname won't show # group members (but group lookups for the OS still work). It is basically # required for complex AD group schemas, or AD environments with LOTS of # groups. It may be possible to turn it off if a group search base can # be devised which speeds thing up. But if there were many many groups, we # still need it. ignore_group_members = true > > bye, > Sumit thanks. > >> seems that SSSD would sometimes catch it at the right time, and remove >> the user from the group, or sometimes bug out and remove all the users >> group except the user entry's gidNumber group (primary login group). >> >> This appears to me to be some sort of bug with SSSD where once it >> removes a group in the cache, it doesn't restore it when the user comes >> back. Perhaps negative caching (intended, or not)? >> >> >> - Jim >> >> _______________________________________________ >> 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 > _______________________________________________ > 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
_______________________________________________ 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