sssd-users November 2024

sssd-users@lists.fedorahosted.org

6 participants
6 discussions

Slowness with freeipa and sudorules involving large hostgroups
by Richard Doerwaldt 06 Dec '24

06 Dec '24

I've configured sudo to use the ipa backend basically using the config ipa-client-install generated for me and it's mostly working. However, when I configure sudo rules in FreeIPA with hostgroups containing a large amount of hosts, and I attempt to run sudo with an emptied sssd cache I get delays as sssd looks up the hosts in those netgroups, sometimes leading to timeouts when these lookups exceed ldap_search_timeout. I don't think looking up the hosts the netgroups should be required to evaluate the sudo rules. Configuring ignore_group_members=True unfortunately doesn't seem to help me here. Is there any way I can avoid sssd looking up these large netgroups?

4 4

Any way to take down historical posts?
by Spike White 27 Nov '24

27 Nov '24

All, Is there any way for somone to take down historical posts that same someone has previously posted to this mailing list? Inquiring for a friend. :-) Spike

2 1

password and otp validation in SSSD offline authentication mode
by seojeong kim 22 Nov '24

22 Nov '24

If I enable multi factor prompt for SSSD offline authentication, I see like below. First Factor: Second Factor: but i have a question about the following case. When I put input like below, it also authenticates user. First Factor: pwd+otp Second Factor: pwd+otp So, I can tell if it's working normally?

2 7

In which PAM phase are the UID/GID in AD required?
by Spike White 20 Nov '24

20 Nov '24

Sssd experts, We have an app that’s having AD users connect to their app -- users that don’t have UIDs and GIDs stored in AD. They’re allowing these remote connections for DB queries and our cybersecurity team wants to see the username/ip addresses from which these queries originate. That is, the app team has this. In /etc/pam.d/krb5 file: auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= APAC.COMPANY.COM try_first_pass auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= EMEA.COMPANY.COM try_first_pass auth sufficient /usr/lib64/security/pam_krb5.so no_user_check realm= AMER.COMPANY.COM use_first_pass Our company has 3 regional AD domains. AMER, EMEA, APAC. Here’s the logs from /var/log/secure. Cybersecurity is happy with these logs, because they give the incoming AD account and the remote IP address. Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown option no_user_check Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): authentication failure; logname=karunakanti_chiranje uid=7202893 euid=7202893 tty= ruser= rhost=10.107.18.78 Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown option no_user_check Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): authentication failure; logname=karunakanti_chiranje uid=7202893 euid=7202893 tty= ruser= rhost=10.107.18.78 Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): unknown option no_user_check Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:auth): user karunakanti_chiranje authenticated as karunakanti_chiranje(a)AMER.COMPANY.COM Nov 19 07:17:26 cepnlmemf01 memsqld[159234]: pam_krb5(krb5:account): unknown option no_user_check This approach is functional, but has several drawbacks. 1. If the incoming user is in AMER, this login will fail twice (APAC, EMEA), then finally succeed for user(a)AMER.COMPANY.COM 2. Pam_krb5 has no caching, so every DB query results in hitting the AD domain controllers. (Multiple times, if user in EMEA or AMER). We’re using pam_sss successfully for ssh logins. It works great! With the caveat that all AD users and groups have to have a UID and GID. Otherwise the AD user cannot login via ssh. They have to be realm permitted also (usually by group). Can the above pam file be replaced by similar pam_sss.so invocations? I.e., at which PAM phase is the UID and GID required? Is it required in the auth phase? Account phase? Or only in the session phase? Spike

2 1

sssd - ssh prompt
by seojeong kim 19 Nov '24

19 Nov '24

seojeong.kim is a 2fa user. so, I can see prompt is like below. but the current max failure attempt is 4. so after I have 4 times failed attempts, ssh prompt changes to Password : Is this normal working? Can I keep First Factor/Second Factor prompt for 2fa user even when failure attempts reach to the max count ? (seojeong.kim@myhost) First Factor: (seojeong.kim@myhost) Second Factor: (seojeong.kim@myhost) First Factor: (seojeong.kim@myhost) Second Factor: (seojeong.kim@myhost) First Factor: (seojeong.kim@myhost) Second Factor: (seojeong.kim@myhost) First Factor: (seojeong.kim@myhost) Second Factor: (seojeong.kim@myhost) First Factor: (seojeong.kim@myhost) Password : /etc/sssd/sssd.conf is like below. [prompting/password] password_prompt = Password : [prompting/2fa] single_prompt = False first_prompt = First Factor: second_prompt = Second Factor:

2 2

Should ad_use_ldaps need additional work/settings to support LDAPS?
by Kodiak Firesmith 14 Nov '24

14 Nov '24

Hi Folks, We need to start using LDAPS rather than non-TLS LDAP in our SSSD AD environment. I only have a single AD domain so I can't test with other domains to see if the problem is on the SSSD client side or AD server side. When we set ad_use_ldaps = True, we lose enumeration, and regardless of debug level, all we see related to the issue is the following: Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Could not start TLS encryption. Error in the pull function. Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Could not start TLS encryption. Error in the pull function. Nov 13 14:28:37 u20-test.college.edu sssd_be[125884]: Backend is offline Documentation is a bit scant, which led me to believe that this would be a simple matter of setting a single setting, but this didn't work out. After that I poked around on the internet and ended up trying the following additional sssd.conf settings: ldap_id_use_start_tls = False ldap_uri = ldaps://ad1.college.edu,ldaps://ad2.college.edu ldap_tls_cacert = /etc/sssd/certs/ad_ca.pem Unfortunately this resulted in the same error. When googling around for the specific error, there were no exact matches which makes me think I've encountered something sort of rare. I've been able to infer from searching that Error in the pull function. is an error message from GnuTLS which I assume SSSD wraps for LDAPS, but there are no hits for the full error message above with the sssd_be syslog label. The AD environment is 2016, the client is a Ubuntu 20.04 LTS system. The versions in use are requirements of the environment and I am unable to test against newer releases. I hesitate to mention it in case it creates false leads, but the system is largely compliant with the DoD MAC-1 Classified STIG, with all of the controls that brings over. Surprisingly there were no controls that directly affected SSSD or any LDAP libraries, and we're not enforcing FIPS validated cryptographic modules so it's unlikely due to STIG controls IMO. Questions: - Under normal circumstances, should the ad_use_ldaps setting be all we need for this to "just work"? - Any ideas what we might be able to try in order to further root out the issue? Thanks! - Kodiak Sent with [Proton Mail](https://proton.me/mail/home) secure email.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users November 2024