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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>> 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/[email protected]
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
