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.
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 supertrick@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@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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Jun 7, 2022 at 10:42 AM Gregory Carter gjcarter2@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.
Diplomacy I found was the best option. :-)
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@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@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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Mark,
We have tens of thousands of RHEL7/OL7 (sssd 1.16.*) and RHEL8/OL8 servers connected to a single (multi-domain) AD forest.
Before RHEL7/OL7, sssd would technically work but you didn't have any of the good trouble-shooting calls. So we didn't AD integrate older OS versions.
In your sssd.conf file, it looks right. You might add:
[sssd] ... domains = DOM1.COM domain_resolution_order = DOM1.com, DOM2.com, DOM3.com ...
I also notice you are using tokengroups (which is the default). That was a huge win for enumerating group memberships with nested subgroups.
We originally tried: ldap_group_nesting_level = 0
But use of tokengroups was better.
It looks like you're letting sssd detect its site and determine its preferred AD DCs from the details of the site. (That's how we do it too.)
Do you have all your sites appropriately set up in AD sites & services? And do you have local AD DCs for each of your DOM1.COM, DOM2.COM, DOM3.COM, etc?
Spike
On Tue, Jun 7, 2022 at 2:54 PM Mark Christian supertrick@gmail.com wrote:
On Tue, Jun 7, 2022 at 10:42 AM Gregory Carter gjcarter2@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.
Diplomacy I found was the best option. :-)
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@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@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.o...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
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.o...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure _______________________________________________ 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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On Tue, Jun 7, 2022 at 5:41 PM Mark Christian supertrick@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
Is this a Win/Samba share (i.e. does this operation include SIDs resolution)?
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
Did you consider using `ignore_group_members = true`?
... [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,
It should. You need to read sssd_$domain.log to check if it works as expected.
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@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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
Gregory Carter -
Mark Christian -
Spike White