What were you trying to do that didn't work?

In Cockpit we regularly build CentOS 10 stream images (not yet RHEL 10) for regression testing. The most recent refresh found a regression in sssd.

That test is unfortunately very complex: it sets up a FreeIPA server and an "alice" IdM user, and a delegation rule for sudo:

ipa servicedelegationtarget-add cockpit-target
ipa servicedelegationtarget-add-member cockpit-target --principals="host/x0.cockpit.lan@COCKPIT.LAN"

Then it logs in as alice (which works), and then tries sudo -A whoami, which is supposed to work without password due to the delegation rule. But that regressed.

Please provide the package NVR for which bug is seen:

sssd-krb5-2.10.0~beta1-1.el10.x86_64

I re-tested this on the previous image where the test works. Merely updating sssd* from 2.9.4-6.el10 to 2.10.0~beta1-1.el10 and sudo -K is enough to break it.

How reproducible:

Always

Steps to reproduce

This is very hard to produce from scratch, as you need a FreeIPA server, two VMs communicating with each other, and so on. This is probably easiest to reproduce with the actual cockpit test.

git clone https://github.com/cockpit-project/cockpit
cd cockpit
COCKPIT_BOTS_REF=3bdf1517a07b7e24b4ad76e58bf26006effdd68b test/image-prepare -q centos-10
TEST_OS=centos-10 test/verify/check-system-realms TestIPA.testClientCertAuthentication -stv

then it'll wait on the failure, and it's possible to log into the c10 machine with the shown ssh command. The above requires qemu/libvirt and such, you can run the test in toolbox to avoid installing anything on your machine.

Expected results

passwordless sudo works with a delegated ticket.

Actual results

sudo fails:

$ sudo -A whoami

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

sudo: no askpass program specified, try setting SUDO_ASKPASS

During this, tail -f /var/log/sssd/* only shows

==> /var/log/sssd/sssd_pam.log <==
   *  ... skipping repetitive backtrace ...
(2024-06-18  5:34:22): [pam] [gssapi_get_creds] (0x0040): [CID#8] Unable to read credentials from [default] [maj:0x70000, min:0xd]
   *  ... skipping repetitive backtrace ...
(2024-06-18  5:34:22): [pam] [gssapi_log_status] (0x0040): [CID#8] GSSAPI: No credentials were supplied, or the credentials were unavailable or inaccessible
   *  ... skipping repetitive backtrace ...
(2024-06-18  5:34:22): [pam] [gssapi_log_status] (0x0040): [CID#8] GSSAPI: Permission denied

journalctl -f doesn't show anything during a sudo attempt. setenforce 0 doesn't help, so it's not SELinux.