Hi,
While troubleshooting "slow login" with ipa users we discovered that adding these two lines to our clients sssd.conf file fixed our issue for ipa users.
ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
On the freeipa server side's sssd, we also added, based on the performance tuning blog post https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i..., these two parameters.
ignore_group_members = True subdomain_inherit = ignore_group_members
Without these options and sssd debug enabled, we can see that it goes through all the trusted AD group to request membership(I think).
Here's a log entry example:
(Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_next] (0x0400): Received [testgroup@domain.com] attributes from IPA server. (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_save_objects] (0x0400): Processing group testgroup@domain.com (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_group_by_gid] (0x0400): No such entry
Should ldap_search_base and lda_user_seach_base parameters should be in our clients sssd per default ? Is that a normal behavior ?
We're also experiencing similar login slowness with our AD trusted credentials. Do similar parameters exist for a trusted AD realm ?
Thanks for your help.
On Mon, Dec 18, 2017 at 06:59:25PM -0500, Alexandre Pitre via FreeIPA-users wrote:
Hi,
While troubleshooting "slow login" with ipa users we discovered that adding these two lines to our clients sssd.conf file fixed our issue for ipa users.
ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com
This should already be the default
ldap_user_search_base = cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
This is not, but does it really make much of a difference? By default, both the user and group search bases are set to cn=accounts,dc=ipa,dc=domain,dc=com
On the freeipa server side's sssd, we also added, based on the performance tuning blog post https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-i..., these two parameters.
ignore_group_members = True subdomain_inherit = ignore_group_members
I think this is what makes the difference
Without these options and sssd debug enabled, we can see that it goes through all the trusted AD group to request membership(I think).
Here's a log entry example:
(Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_next] (0x0400): Received [testgroup@domain.com] attributes from IPA server. (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_save_objects] (0x0400): Processing group testgroup@domain.com (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_group_by_gid] (0x0400): No such entry
Should ldap_search_base and lda_user_seach_base parameters should be in our clients sssd per default ? Is that a normal behavior ?
Yes, currently the group resolution is not super fast in a large domain. But we've added some performance improvements in the 1.16.x branch of SSSD which should make its way (at least to) RHEL-7.5
We're also experiencing similar login slowness with our AD trusted credentials. Do similar parameters exist for a trusted AD realm ?
Some parameters for the trusted domains can be set in the trusted domain section directly, e.g.
[domain/ipadomain/addomain] ad_site = site_override
some parameters must still be set in the trusted domain set with the subdomain_inherit option. Sorry it's a bit inconvenient, we have a PR to unify the behaviour and allow setting all parameters in the subdomain sub-section, but the PR is not merged yet.
Hi Jakub,
Thanks for your response. I assume our puppet configuration was incomplete and ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com was left out by mistake. We're already using the trusted domain section to force connection to AD site-specific domain controllers. Is ad_site parameter useful only if we we relying on DNS discovery ? See our sssd.conf full configuration below.
Server side:
[domain/ipa.domain.com]
cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = ipa-001.ipa.domain.com chpass_provider = ipa ipa_server = ipa-001.ipa.domain.com ipa_server_mode = True ignore_group_members = True subdomain_inherit = ignore_group_members
[sssd] services = nss, sudo, pam, ssh domains = ipa.domain.com
[domain/ipa.domain.com/domain.com] ad_server = ad-001.domain.com ad_backup_server = ad-002.domain.com
[nss] homedir_substring = /home override_shell = /bin/bash
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
Client side:
[domain/ipa.domain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = centos.ipa.domain.com chpass_provider = ipa dyndns_update = True ipa_server = _srv_, ipa-001.ipa.domain.com, ipa-002.ipa.domain.com dyndns_iface = eth0
[sssd] services = nss, sudo, pam, ssh domains = ipa.domain.com,domain.com
[nss] homedir_substring = /home override_shell = /bin/bash
[pam] pam_id_timeout = 120
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
My colleague added this section as a test and this seems to have fixed our login slowness with AD credentials.
[domain/domain.com] auth_provider = krb5 cache_credentials = True ldap_id_use_start_tls = False krb5_server = ad-001.domain.com:88 krb5_kpasswd = ad-002.domain.com:88 ldap_search_base = OU=Accounts,DC=domain,DC=com krb5_realm = DOMAIN.COM chpass_provider = none id_provider = ldap krb5_canonicalize = false
Is this a good practice ?
Thanks, Alex
On Tue, Dec 19, 2017 at 5:13 AM, Jakub Hrozek via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
On Mon, Dec 18, 2017 at 06:59:25PM -0500, Alexandre Pitre via FreeIPA-users wrote:
Hi,
While troubleshooting "slow login" with ipa users we discovered that
adding
these two lines to our clients sssd.conf file fixed our issue for ipa
users.
ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com
This should already be the default
ldap_user_search_base = cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
This is not, but does it really make much of a difference? By default, both the user and group search bases are set to cn=accounts,dc=ipa,dc=domain,dc=com
On the freeipa server side's sssd, we also added, based on the
performance
tuning blog post https://jhrozek.wordpress.com/2015/08/19/performance-tuning-
sssd-for-large-ipa-ad-trust-deployments/,
these two parameters.
ignore_group_members = True subdomain_inherit = ignore_group_members
I think this is what makes the difference
Without these options and sssd debug enabled, we can see that it goes through all the trusted AD group to request membership(I think).
Here's a log entry example:
(Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_next] (0x0400): Received [testgroup@domain.com] attributes from IPA server. (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [ipa_s2n_save_objects] (0x0400): Processing group testgroup@domain.com (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]] [sysdb_search_group_by_gid] (0x0400): No such entry
Should ldap_search_base and lda_user_seach_base parameters should be in
our
clients sssd per default ? Is that a normal behavior ?
Yes, currently the group resolution is not super fast in a large domain. But we've added some performance improvements in the 1.16.x branch of SSSD which should make its way (at least to) RHEL-7.5
We're also experiencing similar login slowness with our AD trusted credentials. Do similar parameters exist for a trusted AD realm ?
Some parameters for the trusted domains can be set in the trusted domain section directly, e.g.
[domain/ipadomain/addomain] ad_site = site_override
some parameters must still be set in the trusted domain set with the subdomain_inherit option. Sorry it's a bit inconvenient, we have a PR to unify the behaviour and allow setting all parameters in the subdomain sub-section, but the PR is not merged yet. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On Tue, Dec 19, 2017 at 04:11:04PM -0500, Alexandre Pitre wrote:
Hi Jakub,
Thanks for your response. I assume our puppet configuration was incomplete and ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com was left out by mistake. We're already using the trusted domain section to force connection to AD site-specific domain controllers. Is ad_site parameter useful only if we we relying on DNS discovery ?
Yes.
See our sssd.conf full configuration below.
The configuration looks good to me.
Server side:
[domain/ipa.domain.com]
cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = ipa-001.ipa.domain.com chpass_provider = ipa ipa_server = ipa-001.ipa.domain.com ipa_server_mode = True ignore_group_members = True subdomain_inherit = ignore_group_members
[sssd] services = nss, sudo, pam, ssh domains = ipa.domain.com
[domain/ipa.domain.com/domain.com] ad_server = ad-001.domain.com ad_backup_server = ad-002.domain.com
[nss] homedir_substring = /home override_shell = /bin/bash
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
Client side:
[domain/ipa.domain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = centos.ipa.domain.com chpass_provider = ipa dyndns_update = True ipa_server = _srv_, ipa-001.ipa.domain.com, ipa-002.ipa.domain.com dyndns_iface = eth0
[sssd] services = nss, sudo, pam, ssh domains = ipa.domain.com,domain.com
[nss] homedir_substring = /home override_shell = /bin/bash
[pam] pam_id_timeout = 120
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
My colleague added this section as a test and this seems to have fixed our login slowness with AD credentials.
[domain/domain.com] auth_provider = krb5 cache_credentials = True ldap_id_use_start_tls = False krb5_server = ad-001.domain.com:88 krb5_kpasswd = ad-002.domain.com:88 ldap_search_base = OU=Accounts,DC=domain,DC=com krb5_realm = DOMAIN.COM chpass_provider = none id_provider = ldap krb5_canonicalize = false
Is this a good practice ?
Hmm, I think this goes in the right direction, but I think it's much better to define a Kerberos realm in krb5.conf for the AD-based DOMAIN.COM and define the KDCs there.
I'm not sure if this domain would be even reached, because all queries qualified with @domain.com should be caught already be the autodiscovered sub-domain of ipa.domain.com...but since you say the domain definition helps here, I suspect it's because sssd the address of the AD DCs into kerberos kdcinfo files (see man sssd_krb5_locator_plugin) and that's where libkrb5 reads them from.
So if you put the AD DC addresses into krb5.conf, you should achieve the same thing, except with less magic
freeipa-users@lists.fedorahosted.org
-
Alexandre Pitre -
Jakub Hrozek