On Tue, Jun 7, 2022 at 10:42 AM Gregory Carter <gjcarter2(a)gmail.com> wrote:
I went with OpenLDAP. I had AD running for integration with Windows users using
PowerBroker, but found it hard to justify shutting my linux users down when I had to work
on a Microsoft product, or vice versa for that matter. Far fewer issues really even
though I am running two different systems (OpenLDAP/Active Directory) the problem time
went away trying to get both of them to work. I spend far less time managing two separate
systems now than trying to get them both to work together.
1.16 is pretty old for something with as much churn as sssd. I would try to stay within
at least a year of the current version if you are concerned about support issues.
I normally get around that sort of thing with the bosses by doing extensive testing in
the lab before I roll out something not found in my RHEL 7 package list. (i.e. sssd
1.16>)
Agreed, I will be looking at the feasibility of using a more current client.
Thanks for the bug report which has "id sssd" taking 7.3 seconds to
complete and then increasing to ~90 seconds post software update. The
pre-update time of 7 seconds seems slow to me. Is that the initial,
first time response? e.g. once "id sssd" is cached, additional "id
sssd" operations are near instantaneous, with perhaps a background
process keeping the cache up to date? Or do sssd customers expect id
$account and ls -l large_directory_contents to take a few seconds
after some inactivity of a few hours?
I'm hoping that a combination of a streamlined, well organized AD or
equivalent ldap backend, along with a well configured sssd cache will
give my customers who are used to NIS performance a similar experience
with an sssd client.
>
> On Tue, Jun 7, 2022 at 8:41 AM Mark Christian <supertrick(a)gmail.com> wrote:
>>
>> I'm wondering what configuration options I should be tweaking to
>> improve id to name resolution when running commands such as ls -l, and
>> id? My sssd version is 1.16.*, and the sssd configuration consists
>> of:
>> [sssd]
>> domains =
DOM1.COM
>> ...
>> [nss]
>> entry_cache_timeout=5400
>> refresh_expired_interval=4050
>> ...
>> [
domain/DOM1.COM]
>> id_provider = ad
>> auth_provider = ad
>> ad_enabled_domains =
dom1.com,
dom2.com,
dom3.com,
dom4.com
>> ldap_referrals = false
>> ldap_id_mapping = false
>> ldap_access_order = expire
>> ldap_account_expire_policy = ad
>> ldap_force_upper_case_realm = true
>> ldap_group_nesting_level = 0
>> ldap_use_tokengroups = false
>> ...
>> [
domain/DOM1.COM/DOM2.COM]
>> ...
>> [
domain/DOM1.COM/DOM3.COM]
>> ...
>> [
domain/DOM1.COM/DOM4.COM]
>> ...
>>
>> ldap_user_search_base/ ldap_group_search_base are used to limit which
>> OUs to query. But at this moment I'm not able to use the filter
>> option for these parameters to possibly help performance. Some
>> accounts have as many as 250 groups. enumerating group membership via
>> "id -G $account" happens quickly enough. Initial name to id mapping is
>> a bit slow (id $account), but I can tolerate that. I was hoping that
>> the refresh_expired_interval setting would keep the entry cache from
>> "losing" the id to name mappings, but it seems that after some period
>> of time, running something like ls -l on a directory full of hundreds
>> of different group owned dirs takes longer than I would like.
>>
>> What sssd.conf options should I be considering to keep the id to name
>> cache from expiring? What other options or strategies might I
>> consider to prepopulate the sssd cache? I'm trying to migrate off a
>> NIS environment, where name to id mapping is near instantaneous and
>> I'm hoping sssd might perform as well. I'm also investigating
>> re-architecting AD, placing all groups/accounts in one Domain or
>> perhaps ditching AD in favor of freeIPA or equivalent. I must
>> accommodate 50K+ accounts, thousands of groups and ideally get the
>> same performance that NIS has historically offered.
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure