sssd-users June 2024

sssd-users@lists.fedorahosted.org

7 participants
13 discussions

2FA is being enforced after upgrading 2.9.1->2.9.4
by Grzegorz Sobański 18 Jun '24

18 Jun '24

Hi, after updating Rocky Linux from 9.3 to 9.4 sssd started to enforce 2FA for our sudo configuration, while before it was optional, and we can’t find why did it change. We downgraded sssd packages from 2.9.4 to 2.9.1 and 2FA went back to being optional, so we are sure it’s because sssd version change from 2.9.1->2.9.4, all other configuration is the same. I looked through changelogs and skimmed through the list of commits, but I couldn’t find anything obvious that should change this. Has anyone seen something similar? Do you know if it’s a result of an intended change or some side-effect of other changes? Or a bug? We are using IPA as Kerberos provider, users do have OTP set up. Up to 2.9.1 sudoing worked either with only password or password+otp. On 2.9.4 (and 2.9.5) sudoing is not working with only password, both password+otp are required. I attach excerpts from logs, they are similar for both 2.9.1 and 2.9.4, with one difference standing out: On 2.9.1: (2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD. On 2.9.4: * (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp]. Although one is in loglines other in backtrace. Logs: On 2.9.1: (2024-06-17 12:07:45): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): domain: realm (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): service: sudo (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1 (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): rhost: (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password) (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): priv: 0 (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): cli_pid: 3400909 (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): child_pid: 0 (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): logon name: not set (2024-06-17 12:07:45): [be[realm]] [pam_print_data] (0x0100): flags: 0 [...] (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform auth (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] Will perform online auth (2024-06-17 12:07:45): [krb5_child[3400913]] [get_and_save_tgt] (0x0400): [RID#729] Attempting kinit for realm [realm] (2024-06-17 12:07:45): [krb5_child[3400913]] [sss_krb5_prompter] (0x0200): [RID#729] Prompter interface isn't used for password prompts by SSSD. (2024-06-17 12:07:45): [krb5_child[3400913]] [validate_tgt] (0x0400): [RID#729] TGT verified using key for [host/hostname@realm]. (2024-06-17 12:07:45): [krb5_child[3400913]] [safe_remove_old_ccache_file] (0x0400): [RID#729] New and old ccache file are the same, none will be deleted. (2024-06-17 12:07:45): [krb5_child[3400913]] [k5c_send_data] (0x0200): [RID#729] Received error code 0 (2024-06-17 12:07:45): [krb5_child[3400913]] [main] (0x0400): [RID#729] krb5_child completed successfully On 2.9.4: (2024-06-17 12:12:23): [be[realm]] [dp_pam_handler_send] (0x0100): Got request with the following data (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): domain: realm (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): user: gsobanski@realm (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): service: sudo (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): tty: /dev/pts/1 (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): ruser: gsobanski (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): rhost: (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): authtok type: 1 (Password) (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): priv: 0 (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): cli_pid: 1757901 (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): child_pid: 0 (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): logon name: not set (2024-06-17 12:12:23): [be[realm]] [pam_print_data] (0x0100): flags: 0 [...] (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm] (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed] ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child started. * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x1000): [RID#38] total buffer size: [179] * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] cmd [241 (auth)] uid [123456] gid [1002] validate [true] enterprise principal [false] offline [false] UPN [gsobanski@realm] * (2024-06-17 12:12:23): [krb5_child[1757979]] [unpack_buffer] (0x0100): [RID#38] ccname: [FILE:/tmp/krb5cc_123456_XXXXXX] old_ccname: [FILE:/tmp/krb5cc_123456_3UVHOp] keytab: [/etc/krb5.keytab] * (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [123456][1002]. * (2024-06-17 12:12:23): [krb5_child[1757979]] [switch_creds] (0x0200): [RID#38] Switch user to [0][0]. * (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_check_old_ccache] (0x4000): [RID#38] Ccache_file is [FILE:/tmp/krb5cc_123456_3UVHOp] and is active and TGT is valid. * (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_setup_fast] (0x0100): [RID#38] Fast principal is set to [host/hostname@realm] * (2024-06-17 12:12:23): [krb5_child[1757979]] [find_principal_in_keytab] (0x4000): [RID#38] Trying to find principal host/hostname@realm in keytab. * (2024-06-17 12:12:23): [krb5_child[1757979]] [match_principal] (0x1000): [RID#38] Principal matched to the sample (host/hostname@realm). * (2024-06-17 12:12:23): [krb5_child[1757979]] [check_fast_ccache] (0x0200): [RID#38] FAST TGT is still valid. * (2024-06-17 12:12:23): [krb5_child[1757979]] [become_user] (0x0200): [RID#38] Trying to become user [123456][1002]. * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x2000): [RID#38] Running as [123456][1002]. * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific renewable lifetime requested. * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_lifetime_options] (0x0100): [RID#38] No specific lifetime requested. * (2024-06-17 12:12:23): [krb5_child[1757979]] [set_canonicalize_option] (0x0100): [RID#38] Canonicalization is set to [true] * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform auth * (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] Will perform online auth * (2024-06-17 12:12:23): [krb5_child[1757979]] [tgt_req_child] (0x1000): [RID#38] Attempting to get a TGT * (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0400): [RID#38] Attempting kinit for realm [realm] * (2024-06-17 12:12:23): [krb5_child[1757979]] [sss_krb5_responder] (0x4000): [RID#38] Got question [otp]. * (2024-06-17 12:12:23): [krb5_child[1757979]] [get_and_save_tgt] (0x0020): [RID#38] 2367: [-1765328360][Preauthentication failed] ********************** BACKTRACE DUMP ENDS HERE ********************************* (2024-06-17 12:12:23): [krb5_child[1757979]] [map_krb5_error] (0x0040): [RID#38] 2496: [-1765328360][Preauthentication failed] (2024-06-17 12:12:23): [krb5_child[1757979]] [k5c_send_data] (0x0200): [RID#38] Received error code 1432158222 (2024-06-17 12:12:23): [krb5_child[1757979]] [main] (0x0400): [RID#38] krb5_child completed successfully Grzegorz Sobański www.payu.com<http://www.payu.com/>

1 0

looks like bug https://bugzilla.redhat.com/show_bug.cgi?id=1984591 is back...
by Spike White 14 Jun '24

14 Jun '24

sssd personnel, In RHEL7, sssd was auto-discovering AD domains that trusted this domain, but that this domain did not trust. i.e., it was over-discovering AD domains. For a large company, you'll have one or more prod AD domain. That all trust each other. Then you'll likely have an engineering and possibly a test AD domain. These engineering and test domains would trust the prod domain(s), but the prod domain(s) wouldn't trust these engineering/test domains (nor should they). So if sssd were AD-integrated to one of the prod domains, it should auto-discover the prod domains only. It's true that buried deep in AD's data structures, there is a trust relationship with the test domain and the engineering domain. But it's a trust going the wrong way. Sumit fixed this for RHEL7, it seems the fix was first pushed out in sssd-1.16.5-10.el7_9.11. RHEL7 seems to still be fixed as of today. At least on RHEL8 and RHEL9, it seems to have reverted. There is a work-around. in /etc/sssd/sssd.conf file, you can add: [domain/prod1.company.com] .... ad_enabled_domains = prod1.company.com, prod2.company.com, prod3.company.com So while all these extraneous auto-discovered AD domains still show in 'sssctl domain-list', they no longer cause problems. Spike

1 0

[SSSD] Announcing SSSD 2.10.0-beta1
by Pavel Březina 07 Jun '24

07 Jun '24

# SSSD 2.10.0-beta1 The SSSD team is announcing the release of version 2.10.0-beta1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.10.0-beta1 See the full release notes at: https://sssd.io/release-notes/sssd-2.10.0-beta1.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users # SSSD 2.10-beta1 Release Notes ## Highlights ### General information * **IMPORTANT note for downstream maintainers!** This release features significant improvements of "running with less privileges (under unprivileged service user)" feature. There is still a `./configure` option `--with-sssd-user=` available that allows downstream package maintainers to choose if support of non-root service user should be built. In case such support is built, a preferred way to configure service user is simply by starting SSSD under this user; for example, using `User=/Group=` options of systemd sssd.service file. Upstream defaults are to build `--with-sssd-user=sssd` and to install systemd service with `User=/Group=sssd`. In this case, only several helper processes - `ldap_child`, `krb5_child` and `selinux_child` - are executed with elevated capabilities (that are now granted using fine grained file capabilities instead of SUID bit). All other SSSD components run without any capabilities. In this scenario it's still possible to re-configure SSSD to run under `root` (if needed for some reason): besides changing `User/Group=` options, some other tweaks of systemd service files are required. A legacy method to configure a service user - sssd.conf `user` option - is now deprecated and its support isn’t built by default. It can be enabled using `--with-conf-service-user-support` `./configure` option if needed (for example, due to backward compatibility requirements of stable releases). Further, no matter if SSSD is built `--with-sssd-user=sssd` or `--with-sssd-user=root`, when it's configured to run under `root` (in both cases) it still runs without capabilities, the same way as when it's configured to run under `sssd` user. The only difference is from the DAC perspective. Important note: owner of `/etc/sssd/sssd.conf` file (and snippets) should match the user configured to start SSSD service. Upstream spec file changes ownership of existing `sssd.conf` to `sssd` during package installation for seamless upgrades. Additionally, this release fixes a large number of issues with "socket activation of responders" feature, making it operable out-of-the-box when the package is built `--with-sssd-user=sssd`. Please take a note, that user configured to run main sssd.service and socket activated responders (if used) should match (i.e. if sssd.service is re-configured from upstream defaults to `root` then responders services also should be re-configured). Downstream package maintainers are advised to carefully inspect changes in `contrib/sssd.spec.in`, `src/sysv/systemd/*` and `./configure` options that this release brings! * sssctl `cache-upgrade` command was removed. SSSD performs automatic upgrades at startup when needed. * Support of `enumeration` feature (i.e. ability to list all users/groups using `getent passwd/group` without argument) for AD/IPA providers is deprecated and might be removed in further releases. Those who are interested to keep using it awhile should configure its build explicitly using `--with-extended-enumeration-support` ./configure option. ### New features * The new tool `sss_ssh_knownhosts` can be used with ssh's KnownHostsCommand configuration option to retrieve the host's public keys from a remote server (FreeIPA, LDAP, etc.). This new tool, which is more reliable, replaces `sss_ssh_knownhostsproxy`. Please consider switching to using the new tool as the old one will be removed. ### Packaging changes * Building SSSD now unconditionally requires availability of `ucred`/ `SO_PEERCRED` to enforce certain security checks at runtime (see `man 7 unix` for details). * SSSD now requires `libini` not older than v1.3 * Explicit `--with-semanage` ./configure switch was removed, going forward `--with-selinux` includes this. ### Configuration changes * Default `ldap_id_use_start_tls` value changed from `false` to `true` for improved security. * Added a `ldap_use_ppolicy` option for backends with broken ppolicy extension handling. * Obsolete `config_file_version` option was removed.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users June 2024