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>) Diplomacy I found was the best option. :-) PS: https://bugzilla.redhat.com/show_bug.cgi?id=1984591 On Tue, Jun 7, 2022 at 8:41 AM Mark Christian <[email protected]> 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 -- [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] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ 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] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
