July 2025 - Sssd-maintainers - Fedora mailing-lists

[Bug 2333179] New: ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE)
by bugzilla＠redhat.com 11 Jun '26

11 Jun '26

https://bugzilla.redhat.com/show_bug.cgi?id=2333179 Bug ID: 2333179 Summary: ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE) Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: Upgrades Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: gregory.lee.bartholomew(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora sssd.service fails to start when the /var/lib/sss/gpo_cache directory is empty. Reproducible: Always Steps to Reproduce: # This happened on two servers that I just updated. 0. have sssd configured as a ldap client 1. dnf update --releasever=41 && reboot Actual Results: [root@redacted gpo_cache]# systemctl status sssd.service × sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf, 50-keep-warm.conf Active: failed (Result: exit-code) since Wed 2024-12-18 19:57:28 CST; 1min 56s ago Duration: 34.808s Invocation: b86216780f7849ec9a6c69a271a88fe9 Process: 672112 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd (code=exited, status=0/SUCCESS) Process: 672114 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd/sssd.conf (code=exited, status=0/SUCCESS) Process: 672116 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/conf.d (code=exited, status=0/SUCCESS) Process: 672118 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/pki (code=exited, status=0/SUCCESS) Process: 672120 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS) Process: 672123 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE) Process: 672125 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS) Process: 672127 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE) Main PID: 672127 (code=exited, status=1/FAILURE) IO: 0B read, 0B written Mem peak: 43.5M CPU: 505ms Dec 18 19:56:53 redacted.com sssd_pam[672133]: Starting up Dec 18 19:57:00 redacted.com sssd_be[672182]: Starting up Dec 18 19:57:03 redacted.com sssd_be[672262]: Starting up Dec 18 19:57:17 redacted.com sssd_be[672374]: Starting up Dec 18 19:57:28 redacted.com sssd[672127]: Exiting the SSSD. Could not restart criti…dap]. Dec 18 19:57:28 redacted.com sssd_ssh[672134]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com sssd_pam[672133]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com sssd_nss[672132]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com systemd[1]: sssd.service: Main process exited, code=exi…ILURE Dec 18 19:57:28 redacted.com systemd[1]: sssd.service: Failed with result 'exit-code'. Expected Results: [root@redacted gpo_cache]# systemctl status sssd.service ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf, 50-keep-warm.conf Active: active (running) since Wed 2024-12-18 20:00:07 CST; 4s ago Invocation: 724c16248ba44bd681be6e4baeef858e Process: 673775 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd (code=exited, status=0/SUCCESS) Process: 673777 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd/sssd.conf (code=exited, status=0/SUCCESS) Process: 673779 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/conf.d (code=exited, status=0/SUCCESS) Process: 673782 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/pki (code=exited, status=0/SUCCESS) Process: 673784 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS) Process: 673786 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=0/SUCCESS) Process: 673788 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS) Main PID: 673790 (sssd) IO: 0B read, 0B written Tasks: 5 (limit: 153881) Memory: 42M (peak: 42.7M) CPU: 274ms CGroup: /system.slice/sssd.service ├─673790 /usr/sbin/sssd -i --logger=files ├─673799 /usr/libexec/sssd/sssd_be --domain ldap --logger=files ├─673800 /usr/libexec/sssd/sssd_nss --logger=files ├─673801 /usr/libexec/sssd/sssd_pam --logger=files └─673802 /usr/libexec/sssd/sssd_ssh --logger=files Dec 18 20:00:07 redacted.com sssd[673790]: Starting up Dec 18 20:00:07 redacted.com sssd_be[673799]: Starting up Dec 18 20:00:07 redacted.com sssd_nss[673800]: Starting up Dec 18 20:00:07 redacted.com sssd_ssh[673802]: Starting up Dec 18 20:00:07 redacted.com sssd_pam[673801]: Starting up I was able to work around the problem by running the following command: touch /var/lib/sss/gpo_cache/dummy -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2333179 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 32

[Bug 1886841] New: Pinpad card reader for login authentication yet you are asked also enter pin on pc keyboard
by bugzilla＠redhat.com 09 Jun '26

09 Jun '26

https://bugzilla.redhat.com/show_bug.cgi?id=1886841 Bug ID: 1886841 Summary: Pinpad card reader for login authentication yet you are asked also enter pin on pc keyboard Product: Fedora Version: 32 Hardware: x86_64 URL: https://lists.fedoraproject.org/archives/list/freeipa- users(a)lists.fedorahosted.org/thread/FLLIA5RLHT3MO4NI2F 3MJNMBBNGGZA4Z/ OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: peter(a)unix-edu.se QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Build Identifier: Hello Folks! We are working on getting smart card authentication working using pinpad card readers for improved security. To do this we use: FreeIPA Server is running on Fedora 32 with latest updates. FreeIPA Clients is Fedora 32 Workstation installed on pc with latest updates with connected usb card reader. The card reader is Gemalto CT700 with pinpad, we use several user individual SmartCard HSM 4K with FreeIPA signed certificates on them. FreeIPA Clients run OpenSC and are configured to use smartcard certificate based authentication, setup per Smartare HSM best practice. Further clients are using SSSD and not PAM_PKCS#11. All working great using smartcard for authentication, as long not enabling the pinpad in opensc. If doing so we are prompted for the PIN not only in the pinpad reader but also GDM prompts you to enter PIN on keyboard. Expected result is to be logged in directly after entering correct PIN code on pinpad reader, not being prompted by GDM to enter PIN on keyboard as well. If enabling pinpad in opensc, login gets a bit odd: 1. Fedora 32 Workstation GDM menu prompts a few users that can login. 2. Smartcard is inserted in reader. 3. GDM blanks out the screen and smartcard reader prompts to enter PIN in its lcd display. 4. Entering pin on smartcard reader followed by pressing ok button on smartcard reader at getting result Pin OK in reader display. 5. GDM now prompts for entering PIN on keyboard, this is unexpected, instead of directly being logged in to the window manager, here Gnome (or xfce, whatever window manager you selected to use). 6. You have to enter the PIN now on keyboard, followed by hitting enter. 7. Once again smartcard reader now prompts for PIN in its lcd display. 8. Entering PIN on the smartcard pinpad reader followed by pressing pinpad ok button. 9. You are now logged in, and all is normal. If ripping out the smartcard from reader the screen locks, as expected. Sometimes, but not always, you are logged in to window manager directly after step 5. What could this be, anyone who have seen this before or know how to set it up ? Reproducible: Always Steps to Reproduce: 1. Install and setup FreeIPA server and client on Fedora32 latest updates to use smartcard authentication for login. Work on IPA Server: ------------------- Install Fedora 32 server minimal installation all excluded, update to latest version (dnf update -y), set hostname, enter server hostname (ipaserver.mydomain.com) and ip in /etc/hosts, enable and start chrony, reboot. (As root user) dnf install ipa-server bind-dyndb-ldap ipa-server-dns -y for SERVICES in ntp http https ldap ldaps kerberos kpasswd dns; do firewall-cmd --permanent --add-service=$SERVICES; done ipa-server-install --setup-dns . . . Add one secondary DNS in /etc/NetworkManager/conf.d/zzz-ipa.conf klist kinit admin authselect select sssd with-sudo with-mkhomedir ipa user-add user3 --first=user3 --last=test --email=user3(a)mydomain.com --shell=/bin/bash --password id user3 ipa user-find user3 ssh user3(a)ipaserver.mydomain.com (change password) reboot (As root user) klist kinit admin ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh chmod u+x config-server-for-smart-card-auth.sh ./config-server-for-smart-card-auth.sh /etc/ipa/ca.crt . . reboot ipa-advise config-client-for-smart-card-auth > /tmp/config-client-for-smart-card-auth.sh chmod a+r /tmp/config-client-for-smart-card-auth.sh Work on Fedora 32 workstation: ------------------------------ Install Fedora 32 Workstation from live dvd to PC, update to latest version (dnf update -y), set hostname, enter server hostname (workstation.mydomain.com) and ip in /etc/hosts, enable and start chrony. change/add to /etc/sysconfig/network-scripts/reboot, so IPA server becomes primary DNS for the Fedora 32 Workstation: PEERDNS=no DNS1=<ipa server ip address> DNS2=<second dns server> SEARCH=mydomain.com DOMAIN=mydomain.com Then reboot Login and check that DNS is working. (as root user) dnf install freeipa-client.x86_64 -y ipa-client-install --mkhomedir id user3 reboot Connect gemalto CT700 card reader to pc/Fedora Workstation. lsusb dnf install opensc ccid pcsc-tools -y systemctl enable pcscd systemctl start pcscd scp user3@ipaserver:/tmp/config-client-for-smart-card-auth.sh . chmod +x config-client-for-smart-card-auth.sh ./config-client-for-smart-card-auth.sh /etc/ipa/ca.crt . . . In /etc/opensc.conf enable pinpad by uncommenting enable_pinpad = true; Ensure pam_cert_auth is true in sssd.conf: grep ^pam_cert_auth /etc/sssd/sssd.conf pam_cert_auth = True authselect select sssd with-mkhomedir with-sudo with-smartcard with-smartcard-lock-on-removal --force authselect current reboot 2. Prepare smartcard-hsm with user3 certificate using (as root user) kinit admin Insert smartcard-hsm in gemalto ct700 card reader! pcsc_scan Using reader plug'n play mechanism Scanning present readers... 0: Gemalto Ezio Shield (I<some number>) 00 00 Wed Sep 23 14:12:27 2020 Reader 0: Gemalto Ezio Shield (I<some number>) 00 00 . . . Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): <some hex number> Smartcard-HSM http://www.cardcontact.de/products/sc-hsm.html pensc-tool --list-readers # Detected readers (pcsc) Nr. Card Features Name 0 Yes PIN pad Gemalto Ezio Shield (I<some number>) 00 00 pkcs11-tool --list-slots Available slots: Slot 0 (0x0): Gemalto Ezio Shield (I<some number>) 00 00 token label : UserPIN (SmartCard-HSM) token manufacturer : www.CardContact.de token model : PKCS#15 emulated token flags : login required, PIN pad present, rng, token initialized, PIN initialized hardware version : 24.13 firmware version : 2.5 serial num : DECM<some number> pin min/max : 6/15 sc-hsm-tool --create-dkek-share dkek-share-1.pbe . . . sc-hsm-tool --initialize --so-pin <long pincode> --pin <pincode> --dkek-shares 1 sc-hsm-tool . . . DKEK shares : 1 DKEK import pending, 1 share(s) still missing sc-hsm-tool --import-dkek-share dkek-share-1.pbe . . . Enter password to decrypt DKEK share : <pincode> sc-hsm-tool . . . DKEK shares : 1 DKEK key check value : <some hex code> # generate keypair pkcs11-tool --module opensc-pkcs11.so --login --pin <pincode> --keypairgen --key-type rsa:2048 --id 10 --label "HSM RSA Key user3" pkcs11-tool --list-objects . . . pkcs11-tool --test --login --pin <pincode> . . . # Backup DKEK sc-hsm-tool --wrap-key wrap-key-1.bin --key-reference 1 --pin <pincode> # Extract card public key for slot 10 pkcs15-tool --read-public-key 10 > user3.pub # Prepping for and Create CSR to sign by IPA for user3 # Create a file hsm.conf with the content below cat hsm.conf # PKCS11 engine config openssl_conf = openssl_def [openssl_def] engines = engine_section [req] distinguished_name = req_distinguished_name [req_distinguished_name] # empty. [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 PIN = init = 0 # Test that hsm.conf is working, and find pkcs11 engine OPENSSL_CONF=./hsm.conf openssl engine (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support (pkcs11) pkcs11 engine # Create CSR to sign by IPA for user3 OPENSSL_CONF=./hsm.conf openssl req -engine pkcs11 -keyform engine -new -key 10 -sha256 -out user3.csr -subj "/CN=user3" Login to IPA server using the web interface https://ipaserver.mydomain.com (this can be performed from command line as well, but we did use the web interface to IPA) user user3 Actions -> new certificate select profile IECuserRoles copy "user3.csr" from above and paste it in and click "issue" (IPA now sign the CSR) To retrieve the signed certificate for user3: user user3 by Certificates click Actions -> Download and save as. (it downloads as cert.pem) Copy the downloaded cerificate (cert.pem) to host with card reader (Fedora 32 Workstation) Rename it: mv cert.pem user3.pem # convert to der format: openssl x509 -in user3.pem -out user3.der -outform der # write it to the card in slot 10 pkcs11-tool --module opensc-pkcs11.so --login --pin <pincode> --write-object user36.der --type cert --id 10 # check that it is there: pkcs11-tool --list-objects Using slot 0 with a present token (0x0) Certificate Object; type = X.509 cert label: Certificate subject: DN: O=MYDOMAIN.COM, CN=user3 ID: 10 Public Key Object; RSA 2048 bits label: Certificate ID: 10 Usage: encrypt, verify Smartcard should now be ready for use with IPA. 3. Now try login to workstation.mydomain.com using GDM using the smartcard issued for user3 Note! user3 password must not have been expired, it should be fixed by the initial login test above. As per details above: 1. Fedora 32 Workstation GDM menu prompts a few users that can login. 2. Smartcard is inserted in reader. 3. GDM blanks out the screen and smartcard reader prompts to enter PIN in its lcd display. 4. Entering pin on smartcard reader followed by pressing ok button on smartcard reader at getting result Pin OK in reader display. 5. GDM now prompts for entering PIN on keyboard, this is unexpected, instead of directly being logged in to the window manager, here Gnome (or xfce, whatever window manager you selected to use). 6. You have to enter the PIN now on keyboard, followed by hitting enter. 7. Once again smartcard reader now prompts for PIN in its lcd display. 8. Entering PIN on the smartcard pinpad reader followed by pressing pinpad ok button. 9. You are now logged in, and all is normal. If ripping out the smartcard from reader the screen locks, as expected. Sometimes, but not always, you are logged in to window manager directly after step 5. Actual Results: You are asked to enter PIN using pinpad on card reader followed by enter PIN using the keyboard, then you are logged in. Sometimes you need to enter PIN on pinpad once more after entering PIN using the keyboard. Expected Results: Directly after entering correct PIN using pinpad on card reader you should be logged in. Versions: Fedora32 with latest updates per Oct 9 2020. freeipa-server-4.8.10-5.fc32.x86_64 freeipa-client-4.8.10-5.fc32.x86_64 sssd-client-2.3.1-2.fc32.x86_64 opensc-0.20.0-6.fc32.x86_64 pcsc-lite-libs-1.9.0-1.fc32.x86_64 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 17

[Bug 2372533] New: Use `systemctl kill` in logrotate postrotate script
by bugzilla＠redhat.com 07 May '26

07 May '26

https://bugzilla.redhat.com/show_bug.cgi?id=2372533 Bug ID: 2372533 Summary: Use `systemctl kill` in logrotate postrotate script Product: Fedora Version: 42 OS: Linux Status: NEW Component: sssd Severity: low Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: marcosfrm(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora `systemctl kill` leverages systemd's knowledge of the daemon's main PID, eliminating the need to rely on PID files or external tools like `killall` or `pkill`. This ensures precise signal sending to the intended process, reducing the risk of errors in process identification. Additionally, using `systemctl kill` logs the signal sending in the service's journal, providing a record of actions taken. Requires selinux-policy-41.43 or higher (see https://bugzilla.redhat.com/show_bug.cgi?id=2369644) available as an update for F41, F42, and Rawhide. https://bodhi.fedoraproject.org/updates/FEDORA-2025-eb98eb9e24 (F41 -- will go to stable in a few days) https://bodhi.fedoraproject.org/updates/FEDORA-2025-f9f097f491 (F42 -- stable) https://bodhi.fedoraproject.org/updates/FEDORA-2025-3db4c0ec1c (Rawhide) The logrotate configuration snippet: # cat /etc/logrotate.d/sssd /var/log/sssd/*.log { weekly missingok notifempty sharedscripts rotate 2 compress delaycompress su sssd sssd postrotate /bin/kill -HUP `cat /run/sssd/sssd.pid 2>/dev/null` 2> /dev/null || true /bin/pkill -HUP sssd_kcm 2> /dev/null || true endscript } In the postrotate script, kill and pkill can be replaced by: /usr/bin/systemctl kill --signal=HUP --kill-whom=main sssd.service sssd-kcm.service 2>/dev/null || true Because: # systemctl show -P MainPID sssd.service 1225 # cat /run/sssd/sssd.pid 1225 # systemctl show -P MainPID sssd-kcm.service 1447 # pgrep sssd_kcm 1447 Reproducible: Always Additional Information: sssd-common-2.11.0-1.fc42.x86_64 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2372533 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 6

[Bug 2375570] New: Sssd 2.11.x doesn't use Kerberos cached auth: get_password_for_cache_auth: Unsupported auth token type [17]
by bugzilla＠redhat.com 22 Dec '25

22 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2375570 Bug ID: 2375570 Summary: Sssd 2.11.x doesn't use Kerberos cached auth: get_password_for_cache_auth: Unsupported auth token type [17] Product: Fedora Version: 42 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: Regression Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: ksuszyns(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora After upgrading Fedora 42, the sssd has been upgraded to 2.11.0-1.fc42 and with that, the caching of the auth broke. Without a connection to the Kerberos server, the user can't authenticate/log in to the machine. Downgrading to 2.10.2-3.fc42 solves the issue. Lots of logs (hundreds of megabytes) like the following (from /var/log/sssd/sssd_ipa.redhat.com.log): (2025-06-23 19:06:39): [be[ipa.redhat.com]] [sbus_issue_request_done] (0x0040): sssd.dataprovider.getAccountInfo: Error [1432158212]: SSSD is offline and also from /var/log/sssd/sssd_nss.log: (2025-06-23 19:06:39): [nss] [cache_req_common_process_dp_reply] (0x3f7c0): [CID#7] CR #769: Could not get account info [1432158212]: SSSD is offline While authentication without VPN I also see (in /var/log/sssd/sssd_pam.log): (2025-06-23 19:05:52): [pam] [get_password_for_cache_auth] (0x0010): [CID#3] Unsupported auth token type [17]. * ... skipping repetitive backtrace ... (2025-06-23 19:05:52): [pam] [get_password_for_cache_auth] (0x0010): [CID#3] Failed to get password. * ... skipping repetitive backtrace ... (2025-06-23 19:05:52): [pam] [pam_reply] (0x0010): [CID#3] get_password_and_type_for_cache_auth failed. * ... skipping repetitive backtrace ... (2025-06-23 19:05:52): [pam] [client_send] (0x0010): [CID#3] Failed to send data, aborting client! Reproducible: Always Steps to Reproduce: 1. Have a Kerberos auth setup and working both with connection and without it, running on sssd < 2.11.0 2. Upgrade to 2.11.x Actual Results: Without the network connection, the auth does not work Expected Results: The auth should work regardless of the network connection. Credentials should be cached. Additional Information: Possible upstream issue: https://github.com/SSSD/sssd/issues/7968 More info: https://redhat-internal.slack.com/archives/C05AWLALLP6/p1749486720894889 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2375570 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 20

[Bug 2351336] New: /etc/krb5.conf.d/enable_sssd_conf_dir is mistakenly in package sssd-krb5, not in sssd-krb5-common
by bugzilla＠redhat.com 02 Dec '25

02 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2351336 Bug ID: 2351336 Summary: /etc/krb5.conf.d/enable_sssd_conf_dir is mistakenly in package sssd-krb5, not in sssd-krb5-common Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: hey(a)runiq.de QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora I have used realmd to join a host to an Active Directory domain. Realmd uses sssd-ad for this, which pulls in sssd-krb5-common but _not_ sssd-krb5. Unfortunately, sssd-krb5-common does not install the snippet /etc/krb5.conf.d/enable_sssd_conf_dir. This results in SSH refusing gssapi-with-mic authentication. When I additionally install the sssd-krb5 package (which includes the snippet), or create the snippet manually, SSH logins use my SSSD config and GSSAPI authentication goes through. Reproducible: Always Steps to Reproduce: 1. Install realmd on a host 2. Join host to Active Directory domain 3. Enable SSH daemon 4. ssh -l user@realm -o preferredauthentications=gssapi-with-mic host Actual Results: Authentication is denied, no SSH session opened Expected Results: Authentication goes through, SSH session is opened -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2351336 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2325893] New: sssd gpo_child doesn't have sufficient rights to populate GPO policies
by bugzilla＠redhat.com 02 Dec '25

02 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2325893 Bug ID: 2325893 Summary: sssd gpo_child doesn't have sufficient rights to populate GPO policies Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: CommonBugs, Desktop Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: nekopilot(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora # 1. Issue After upgrade from F39 to F41 via UI path the login to the system with AD account is not possible. Local account works well. # 2. Workaround sssd service works under sssd user in Fedora 41. The folder with GPO policies has wrong rights with owner root: ls -lah /var/lib/sss/gpo_cache/example.com/Policies/ total 0 drwx------. 4 root root 98 Jan 10 2024 . drwx------. 3 sssd sssd 22 Jan 10 2024 .. drwx------. 3 root root 36 Nov 13 07:33 {31B2F332-016D-11D2-945F-00C04FBB84F9} drwx------. 3 root root 36 Nov 13 07:33 {7E50761D-1E4D-4D2B-BD86-E667EED3DF1E} It is possible to change the owner of the directories. After that the login with AD account works well. chown -R sssd:sssd /var/lib/sss/gpo_cache Reproducible: Always Steps to Reproduce: 1. Your F39 system must be joined to AD with sssd and you can login to the system with AD account. 2. Upgrade from F39 to F41. 3. Try to login with AD account. Actual Results: Login from Gnome UI is not possible with error: "Wrong user name or password". Expected Results: You can login to the system with AD account. Your F39 system must be joined to AD with sssd and you can login to the system with AD account. After upgrade you can't login from UI with AD account but: 1. kinit user.name(a)example.com - works well. 1. id user.name(a)example.com - works well. 1. realm list - looks good. In logs you can find error message: cat /var/log/sssd/gpo_child.log ``` [gpo_child[4066]] [prepare_gpo_cache] (0x0020): [RID#23] mkdir(/var/lib/sss/gpo_cache/example.com/Policies/{31B2F332-016D-11D2-945F-… failed: 13 ``` -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2325893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2373979] New: python3-sssdconfig packs outdated .pyc files
by bugzilla＠redhat.com 16 Sep '25

16 Sep '25

https://bugzilla.redhat.com/show_bug.cgi?id=2373979 Bug ID: 2373979 Summary: python3-sssdconfig packs outdated .pyc files Product: Fedora Version: rawhide Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: adelton(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Reoccurence of bug #2319608: The /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/*.cpython-314.pyc /usr/lib/files get regenerated when SSSDConfig module is used. Reproducible: Always Steps to Reproduce: 1. dnf install -y python3-sssdconfig 2. stat /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc 3. python3 -c 'import SSSDConfig' 4. stat /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc Actual Results: bash-5.2# stat /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc File: /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc Size: 59904 Blocks: 120 IO Block: 4096 regular file Device: 0,142 Inode: 1085021 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-06-06 00:00:00.000000000 +0000 Modify: 2025-06-06 00:00:00.000000000 +0000 Change: 2025-06-20 05:52:59.146656555 +0000 Birth: 2025-06-20 05:52:59.146512950 +0000 bash-5.2# python3 -c 'import SSSDConfig' bash-5.2# stat /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc File: /usr/lib/python3.14/site-packages/SSSDConfig/__pycache__/__init__.cpython-314.pyc Size: 61398 Blocks: 120 IO Block: 4096 regular file Device: 0,142 Inode: 1081628 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-06-20 05:53:34.790753836 +0000 Modify: 2025-06-20 05:53:34.792024966 +0000 Change: 2025-06-20 05:53:34.792024966 +0000 Birth: 2025-06-20 05:53:34.790753836 +0000 Expected Results: The Size and Modify time in the second stat run should match the output from the first one. First found by https://github.com/freeipa/freeipa-container/actions/runs/15771389975. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2373979 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2375213] New: Transition of log file ownership to sssd user/group does not fix logrotated files, which breaks logrotate
by bugzilla＠redhat.com 05 Aug '25

05 Aug '25

https://bugzilla.redhat.com/show_bug.cgi?id=2375213 Bug ID: 2375213 Summary: Transition of log file ownership to sssd user/group does not fix logrotated files, which breaks logrotate Product: Fedora Version: 42 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: jbilling(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora When the sssd-common package introduced a change to the permissions of the log files in /var/log/sssd/, this was added to the RPM %postinstall scriptlet: /usr/bin/chown -f sssd:sssd /var/log/sssd/*.log || true (Ref: https://src.fedoraproject.org/rpms/sssd/blob/f42/f/sssd.spec#_1119 ) However, there is also a logrotate configuration in sssd-common that rotates and compresses the log files /var/log/sssd/*.log, and it also has "su sssd sssd" in the configuration. (Ref: https://github.com/SSSD/sssd/blob/master/src/examples/logrotate.in) If sssd had been running before the transition to using sssd user/groups for log file ownership, there were several root:root owned files that had been rotated earlier. However, logrotate can no longer rotate them because their permissions were restricted to root and logrotate is running as sssd:sssd. You'll get an error that looks like: logrotate[61244]: error: unable to open /var/log/sssd/sssd_pam.log-20250511 (read-only) for compression: Permission denied This causes the logrotate.service to error out immediately, rather than continuing to rotate log files. I think the glob in the rpm %post install scriptlet should be changed to /var/log/sssd/*.log* to address this. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2375213 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2379224] New: sssd-ad does not rotate machine account password
by bugzilla＠redhat.com 11 Jul '25

11 Jul '25

https://bugzilla.redhat.com/show_bug.cgi?id=2379224 Bug ID: 2379224 Summary: sssd-ad does not rotate machine account password Product: Fedora Version: 42 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: luca.cavana(a)cavanasystems.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: In a Fedora 42 machine joined to AD DS by sssd and realmd (Windows Server 2022 DCs with Server 2016 Functional Level), sssd fails to rotate the machine account password, as dictated by: ad_maximum_machine_account_password_age = 30 days (default configuration) ad_machine_account_password_renewal_opts = 86400:750:300:realm (default configuration) Version-Release number of selected component (if applicable): sssd-ad.x86_64 2.11.0-1.fc42 realmd.x86_64 0.17.1-15.fc42 How reproducible: Always Steps to Reproduce: 1. Install a Fedora 42 host, patch it and join to AD DS domain 2. Wait for the default 30 days of time to pass, or modify ad_maximum_machine_account_password_age to shorter value 3. Monitor PasswordLastSet/msDS-KeyVersionNumber attributes in AD DS, they never change Actual results: The password is never rotated. Expected results: The password is rotated. Additional info: In sssd_domain_name.log you can see sssd trying to rotate the password by calling realm command and failing. Here is a snippet of my log: * (2025-07-10 9:56:33): [be[corp.cavanasystems.com]] [ad_machine_account_password_renewal_done] (0x1000): --- adcli output start--- realm discover -v [realm-name] Discover available realm realm join -v [-U user] realm-name Enroll this machine in a realm realm leave -v [-U user] [realm-name] Unenroll this machine from a realm realm list List known realms realm permit [-ax] [-R realm] user ... Permit user logins realm deny --all [-R realm] Deny user logins ---adcli output end--- * (2025-07-10 9:56:33): [be[corp.cavanasystems.com]] [be_ptask_done] (0x0400): Task [AD machine account password renewal]: finished successfully * (2025-07-10 9:56:33): [be[corp.cavanasystems.com]] [be_ptask_schedule] (0x0400): Task [AD machine account password renewal]: scheduling task 60 seconds from last execution time [1752134253] * (2025-07-10 9:56:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x1000): Waiting for child [86188]. * (2025-07-10 9:56:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x0020): child [86188] failed with status [2]. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2025-07-10 9:57:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x0020): child [86192] failed with status [2]. * ... skipping repetitive backtrace ... (2025-07-10 9:58:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x0020): child [86205] failed with status [2]. * ... skipping repetitive backtrace ... (2025-07-10 9:59:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x0020): child [86211] failed with status [2]. * ... skipping repetitive backtrace ... (2025-07-10 10:00:33): [be[corp.cavanasystems.com]] [child_sig_handler] (0x0020): child [86218] failed with status [2]. * ... skipping repetitive backtrace ... You can see it is calling the realm command to do the rotation but the latter is returning like it is being called with the wrong parameters. It is then retrying every minute because I've altered my configuration as such, for debugging purposes: ad_maximum_machine_account_password_age = 30 ad_machine_account_password_renewal_opts = 60:5 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2379224 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 9

2026

2025

2024

2023

2022

2021

2020

Sssd-maintainers July 2025