sssd-users December 2022

sssd-users@lists.fedorahosted.org

14 participants
13 discussions

CentOS 7, SSSD against LDAP: finds user but will not log them in, "Authentication failure" when trying to su
by Jarett DeAngelis 07 Dec '22

07 Dec '22

Hi, I am trying to get SSSD to authenticate against an OpenLDAP directory. I have "debug_level" turned up to 10 but have not been able to figure out what the problem is based on the log. On an Ubuntu 22.04 system I have found that something with TLS is broken when it tries to connect to OpenLDAP, which is why it has failed on that system -- I think this is related to the OS moving to OpenSSL 3 but have not been able to figure out how to fix it. On this CentOS 7 system, you can see that it can find the user, can get properties from the user, but still fails the user login without, as far as I can tell, explaining why. I have pasted our sssd.conf below, and here is a link to my Nextcloud instance where I am hosting the relevant portion of the log (it was too big for me to be able to paste it into Pastebin): https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD <https://checkwithscience.com/index.php/s/e7mXKAzcq87q6HD> Hoping someone can help us get to the bottom of this. Thanks. Here is our sssd.conf: [sssd] services = nss, pam config_file_version = 2 domains = default certificate_verification = no_verification [nss] [pam] offline_credentials_expiration = 60 [domain/default] debug_level = 10 ldap_id_use_start_tls = False cache_credentials = True ldap_search_base = ou=users,dc=clab,dc=lab id_provider = ldap auth_provider = ldap chpass_provider = ldap access_provider = ldap ldap_uri = ldaps://10.8.8.60:636 ldap_default_bind_dn = cn=admin,dc=clab,dc=lab ldap_default_authtok = definitelyverysecurepassword ldap_tls_reqcert = allow ldap_tls_cacert = /usr/local/share/ca-certificates/mycacert.crt ldap_tls_cacertdir = /usr/local/share/ca-certificates ldap_tls_cert = /etc/ldap/ldapserver00_slapd_cert.pem certificate_verification = no_verification ldap_search_timeout = 50 ldap_network_timeout = 60 ldap_access_order = filter ldap_access_filter = (objectClass=posixAccount) override_homedir = /home/%U override_shell = /bin/bash ldap_user_name = uid auto_private_groups = true sudo_provider = none ldap_account_expire_policy = nds ldap_passwd_policy = shadow

3 4

tuning sssd-ldap to perform close to nss_ldap
by Christian, Mark 02 Dec '22

02 Dec '22

I've been running some benchmarks, timing how long it takes nss_ldap and sssd-ldap configurations to map uid to user names, trying to get an sssd.conf configuration that performs more or less to the existing nss_ldap configuration in terms of system responsive and network utilization. For better or worse I work in an environment where it's not uncommon for folks to do ls -l on directories where hundreds or thousands of subdirectories have unique ids. These tests are run on SLES12sp5, and have the following relevant pkgs: # rpm -q kernel-default sssd sssd-ldap nss_ldap kernel-default-4.12.14-122.136.1.x86_64 sssd-1.16.1-7.44.1.x86_64 sssd-ldap-1.16.1-7.44.1.x86_64 nss_ldap-265-35.12.x86_64 With the system configured for nss_ldap a "stat -c%U" on a parent directory containing 34735 uniquely owned subdirectories, takes 15 to 30 seconds to complete, and generates approximately 30MB of ldap traffic. This is consistent barring any account caching, e.g. nscd. I know the number of subdirectories is extreme, but I find it useful for "worst case" benchmark purposes. With the system configured for sssd-ldap a "stat -C%U" on the same directory initially takes 8+ minutes, and generates ~53MB of ldap traffic. Subsequent runs of the stat command complete in as little as 5 seconds or as long as 45 seconds with the benefit of the sssd cache. To achieve similar system and network performance to nss_ldap, I'm considering increasing entry_cache_timeout from 90 minutes to 4 hours, with refresh_expired_interval set at 3 hours in the hopes of not exceeding the amount of network traffic I see with nss_ldap. I'm also comtemplating pre-populating the sssd cache, when provisioning new systems in order to prevent the initial time it takes to map uid to user name? If so, does it make sense to copy recent copies of the files under /var/lib/sss/db to newly deployed systems? Can I attribute the variance in time it takes to run the stat command, anywhere from 5 to 45 seconds, to the background refresh process being in the "middle" of it's refresh? Should I accept that this will always be the case depending on when the "stat -c%U" is run? If the sssd cache is near expiring and refresh_expired_interval is in the middle of the refresh process I'm going to see stat take longer to complete than if the cache is mostly current? Is there anything I can do to avoid this on systems, e.g. run a cron job that does something similar to the stat command? Are there other options I should consider in order to get sssd-ldap to perform similarily to nss_ldap? NSS_LDAP /etc/ldap.conf base dc=example,dc=com SIZELIMIT 0 scope sub uri ldaps://ldap1 ldaps://ldap2 ldap_version 3 bind_policy soft binddn cn=bind_dn,ou=profile,dc=example,dc=com bindpw PASSWORD DEREF never timelimit 30 bind_timelimit 15 idle_timelimit 3600 nss_base_passwd ou=People,dc=example,dc=com?one nss_base_group ou=group,dc=example,dc=com?one nss_base_netgroup ou=netgroup,dc=example,dc=com?one nss_schema rfc2307 tls_ciphers ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA nss_initgroups_ignoreusers root,bin,daemon,nobody SSSD /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = LDAP [nss] [pam] [domain/LDAP] id_provider = ldap auth_provider = krb5 krb5_realm = EXAMPLE.COM ldap_schema = rfc2307 ldap_uri = ldaps://ldap1, ldaps://ldap2 ldap_search_base = dc=example,dc=com ldap_user_search_base = ou=People,dc=example,dc=com?onelevel? ldap_group_search_base = ou=group,dc=example,dc=com?onelevel? ldap_netgroup_search_base = ou=netgroup,dc=example,dc=com?onelevel? ldap_default_bind_dn = cn=bind_dn,ou=profile,dc=example,dc=com ldap_default_authtok = PASSWORD lookup_family_order = ipv4_only # following set for testing, otherwise 14400 and 10800 respectively entry_cache_timeout = 600 refresh_expired_interval = 450 Thanks, Mark

2 1

sssd not using local sudoers file
by Kevin Vasko 01 Dec '22

01 Dec '22

We have a local user that has an entry in sudoers for a “NOPASSWD”. In /etc/nsswitch.conf we have: sudoers: files sss For some reason sssd is falling back to sssd even though we have the “files” entry first and is checking our FreeIPA instance and rejecting it and prompts for password. if I make it sudoers: files It works. This was working without issue on 18.04, we upgraded to 20.04 and now see the problem. Is there a way to make it prioritize the local sudoers and stop looking on sssd? -Kevin

3 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2022