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-leave@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-leave@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