June 2022 - Sssd-maintainers - Fedora mailing-lists

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

27 Jan '24

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 11

[Bug 1857104] New: Using FreeIPA breaks IPv4/IPv6 flags for SSH
by bugzilla＠redhat.com 14 Sep '23

14 Sep '23

https://bugzilla.redhat.com/show_bug.cgi?id=1857104 Bug ID: 1857104 Summary: Using FreeIPA breaks IPv4/IPv6 flags for SSH Product: Fedora Version: 32 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: ossman(a)cendio.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 Description of problem: If a client is configured using ipa-client-install then the -4 and -6 flags stop working for ssh. Version-Release number of selected component (if applicable): Doesn't matter. Seen on RHEL 6 through 8, and on current Fedora. How reproducible: 100% Steps to Reproduce: 1. ipa-client-install 2. ssh -4 host.example.com Actual results: Connected via IPv6 Expected results: Connected via IPv4 Additional info: The bug is that sss_ssh_knownhostsproxy is configured on the client and that command doesn't respect the flags given to ssh. The issue affects all hosts, not just those part of the same FreeIPA domain. A practical effect of this is that connections get rejected or misbehave because of IP based rules in place for this connection. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 19

[Bug 1965818] New: sssd - failing on "dotted"languages (Example turkish language)
by bugzilla＠redhat.com 20 Jan '23

20 Jan '23

https://bugzilla.redhat.com/show_bug.cgi?id=1965818 Bug ID: 1965818 Summary: sssd - failing on "dotted"languages (Example turkish language) Product: Fedora Version: 34 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: thunderbirdtr(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Description of problem: Hello, SSSD Service isn't starting If we use dotted language in our system. For example, adding "LANG=tr_TR" into "/etc/sysconfig/sssd" makes sssd fails on start. If anyone install Fedora with "turkish" or other dotted language in their pc/laptop, that makes sssd fails on start. After I made little bit research, I notice this issue has been addressed multiple times around RHEL[0] and samba[1] and github[2] as well. So for that reason at least can we add "english" locale setting into rpm spec with "language" check as a workaround has been suggest in github link.That is at least gives us "working" package in dotted languge, and If anyone wants change setting, they can change it. At least for normal users, we can have working sssd service and not complain about fails all the times. I know this isn't the cleanest solution (proper solution is patching libldb package which causing this issue, but at least we can have a "quick&dirty" solution avoid on new installs. Thank you. [0] : https://bugzilla.redhat.com/show_bug.cgi?id=1743531 [1] : https://lists.samba.org/archive/samba-technical/2019-December/134659.html [2] : https://github.com/SSSD/sssd/issues/5285 Version-Release number of selected component (if applicable): sssd-2.5.0-2.fc34.x86_64 libldb-2.3.0-2.fc34.x86_64 How reproducible: Steps to Reproduce: 1. Install Fedora or change language into dotted or change "LANG" env into dotted langauge 2. reset sssd counter 3. start sssd Actual results: sssd fails Expected results: sssd should start clean in default config. Additional info: SSSD Systemctl errors systemd[1]: Starting System Security Services Daemon... sssd[760632]: Starting up systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: sssd.service: Failed with result 'exit-code'. systemd[1]: Failed to start System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' systemd[1]: sssd.service: Scheduled restart job, restart counter is at 1. systemd[1]: Stopped System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' systemd[1]: Starting System Security Services Daemon... sssd[760633]: Starting up systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: sssd.service: Failed with result 'exit-code'. systemd[1]: Failed to start System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' systemd[1]: sssd.service: Scheduled restart job, restart counter is at 2. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' systemd[1]: Stopped System Security Services Daemon. systemd[1]: Starting System Security Services Daemon... sssd[760636]: Starting up systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: sssd.service: Failed with result 'exit-code'. systemd[1]: Failed to start System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' systemd[1]: sssd.service: Scheduled restart job, restart counter is at 3. systemd[1]: Stopped System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' systemd[1]: Starting System Security Services Daemon... sssd[760637]: Starting up systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: sssd.service: Failed with result 'exit-code'. systemd[1]: Failed to start System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' systemd[1]: sssd.service: Scheduled restart job, restart counter is at 4. systemd[1]: Stopped System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' systemd[1]: Starting System Security Services Daemon... sssd[760639]: Starting up systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: sssd.service: Failed with result 'exit-code'. systemd[1]: Failed to start System Security Services Daemon. audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' ----------- /var/log/sssd/sssd.log (last error with LANG setting is tr_TR (LANG=tr_TR) ) ----------- ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2021-05-30 15:46:52): [sssd] [check_file] (0x0400): lstat for [/run/sssd.pid] failed: [2][No such file or directory]. * (2021-05-30 15:46:52): [sssd] [check_file] (0x0400): lstat for [/var/run/nscd/socket] failed: [2][No such file or directory]. * (2021-05-30 15:46:52): [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! * (2021-05-30 15:46:52): [sssd] [sss_ini_open] (0x0400): No /etc/sssd/sssd.conf. * (2021-05-30 15:46:52): [sssd] [sss_ini_read_sssd_conf] (0x0100): File /etc/sssd/sssd.conf does not exist. * (2021-05-30 15:46:52): [sssd] [confdb_ldif_from_ini_file] (0x0100): Value of config_file_version option not found. Assumed to be version 2. * (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [sssd] * (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [services] * (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x4000): services: nss * (2021-05-30 15:46:52): [sssd] [sss_confdb_create_ldif] (0x4000): Section dn dn: cn=sssd,cn=config cn: sssd services: nss * (2021-05-30 15:46:52): [sssd] [confdb_init_db] (0x0100): LDIF file to import: dn: cn=config version: 2 dn: cn=sssd,cn=config cn: sssd services: nss * (2021-05-30 15:46:52): [sssd] [add_implicit_services] (0x0040): No domains configured! * (2021-05-30 15:46:52): [sssd] [get_monitor_config] (0x0040): Failed to add implicit configured services. Some functionality might be missing * (2021-05-30 15:46:53): [sssd] [confdb_expand_app_domains] (0x2000): implicit_files is not an app domain * (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x0400): No enumeration for [implicit_files]! * (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x0400): Please note that when enumeration is disabled `getent passwd` does not return all users by design. See sssd.conf man page for more detailed information * (2021-05-30 15:46:53): [sssd] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1 * (2021-05-30 15:46:53): [sssd] [server_setup] (0x0080): Failed setting process group: Operation not permitted[1]. We might leak processes in case of failure * (2021-05-30 15:46:53): [sssd] [become_user] (0x0200): Trying to become user [0][0]. * (2021-05-30 15:46:53): [sssd] [become_user] (0x0200): Already user [0]. * (2021-05-30 15:46:53): [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! * (2021-05-30 15:46:53): [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb * (2021-05-30 15:46:53): [sssd] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (Böyle bir dosya ya da dizin yok) ********************** BACKTRACE DUMP ENDS HERE ********************************* (2021-05-30 15:46:53): [sssd] [main] (0x0010): No domains configured. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2021-05-30 15:46:53): [sssd] [confdb_get_domains] (0x0080): No domains configured, fatal error! * (2021-05-30 15:46:53): [sssd] [main] (0x0010): No domains configured. ********************** BACKTRACE DUMP ENDS HERE ********************************* -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 14

[Bug 2035625] New: sssd AD auth broken with sssd_be segfault
by bugzilla＠redhat.com 20 Jan '23

20 Jan '23

https://bugzilla.redhat.com/show_bug.cgi?id=2035625 Bug ID: 2035625 Summary: sssd AD auth broken with sssd_be segfault Product: Fedora Version: 35 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: dowdle(a)montanalinux.org QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 All of my F35 hosts no longer have working active directory authentication via sssd... and I'm receiving the following segfault error every few seconds: sssd_be[pid]: segfault at 0 ip 00007f9cfecb00da sp 00007ffd389203e8 error 4 in libc.so.6 In the journal log entries for sssd I see: sssd_be[2341]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type) -- 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=2035625

1 6

[Bug 2088481] New: selinux_child: Cannot beign SELinux transaction
by bugzilla＠redhat.com 05 Jul '22

05 Jul '22

https://bugzilla.redhat.com/show_bug.cgi?id=2088481 Bug ID: 2088481 Summary: selinux_child: Cannot beign SELinux transaction Product: Fedora Version: 34 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: rcritten(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Description of problem: Some logins fail under load due to contention over the SELinux transaction lock in libsemanage. I'm trying to gather scalability information on IPA. The test revolves around bringing up a number of client VMs, enrolling as IPA clients and running a forking client that does a PAM transaction with the login service. Each client has a set of unique users with non-expired passwords to authenticate with. No pre-loading of the cache is done. In this particular case I brought up 10 clients and ran the test tool do to 10 logins. All of these 100 logins happen more or less simultaneously (time is synced). 30 of the authentications failed due to the transaction locking. IPA should be able to handle 100 authentications without breaking a sweat and the server-side logs don't show any issues but it may be somewhat load related. If I re-run the test tool after the fact, even clearing the SSSD cache I can't reproduce the transaction failure. I wonder if a retry could be implemented. The selinux_child log contains the following. It is consistent across all the clients (log level 3): (2022-05-19 13:42:01): [selinux_child[11668]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): selinux_child started. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x2000): Running with effective IDs: [0][0]. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x2000): Running with real IDs [0][0]. * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): context initialized * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): seuser length: 12 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): seuser: unconfined_u * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): mls_range length: 14 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): username length: 23 * (2022-05-19 13:41:56): [selinux_child[11668]] [unpack_buffer] (0x2000): username: user6client000.ipa.test * (2022-05-19 13:41:56): [selinux_child[11668]] [main] (0x0400): performing selinux operations * (2022-05-19 13:41:56): [selinux_child[11668]] [seuser_needs_update] (0x2000): sss_get_seuser: ret: 0 seuser: unconfined_u mls: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11668]] [sss_seuser_exists] (0x0400): seuser exists: no * (2022-05-19 13:41:56): [selinux_child[11668]] [seuser_needs_update] (0x0400): The SELinux user does need an update * (2022-05-19 13:42:01): [selinux_child[11668]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11668]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): Cannot set SELinux login context. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:42:01): [selinux_child[11668]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction * (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): Cannot set SELinux login context. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11668]] [main] (0x0020): selinux_child failed! (2022-05-19 13:42:01): [selinux_child[11671]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): selinux_child started. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x2000): Running with effective IDs: [0][0]. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x2000): Running with real IDs [0][0]. * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): context initialized * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): seuser length: 12 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): seuser: unconfined_u * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): mls_range length: 14 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): username length: 23 * (2022-05-19 13:41:56): [selinux_child[11671]] [unpack_buffer] (0x2000): username: user1client000.ipa.test * (2022-05-19 13:41:56): [selinux_child[11671]] [main] (0x0400): performing selinux operations * (2022-05-19 13:41:56): [selinux_child[11671]] [seuser_needs_update] (0x2000): sss_get_seuser: ret: 0 seuser: unconfined_u mls: s0-s0:c0.c1023 * (2022-05-19 13:41:56): [selinux_child[11671]] [sss_seuser_exists] (0x0400): seuser exists: no * (2022-05-19 13:41:56): [selinux_child[11671]] [seuser_needs_update] (0x0400): The SELinux user does need an update * (2022-05-19 13:42:01): [selinux_child[11671]] [libsemanage] (0x0020): Could not get direct transaction lock at /var/lib/selinux/targeted/semanage.trans.LOCK. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11671]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): Cannot set SELinux login context. ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-05-19 13:42:01): [selinux_child[11671]] [sss_set_seuser] (0x0020): Cannot begin SELinux transaction * (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): Cannot set SELinux login context. ********************** BACKTRACE DUMP ENDS HERE ********************************* (2022-05-19 13:42:01): [selinux_child[11671]] [main] (0x0020): selinux_child failed! Version-Release number of selected component (if applicable): sssd-common-2.5.2-2.fc34 -- 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=2088481

1 7

[Bug 2094685] New: Default of 'pac_check' is too strict
by bugzilla＠redhat.com 17 Jun '22

17 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=2094685 Bug ID: 2094685 Summary: Default of 'pac_check' is too strict Product: Fedora Version: 36 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: sbose(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Description of problem: Default of 'pac_check' is too strict, it currently requires that a PAC is present when using ipa or ad provider. While it would work with the AD provider in most cases for ipa there is a fair chance that the PAC will not be available. If authentication fails and there are messages like "[validate_tgt] ... PAC check failed for principal ..." you are most probably affected by this issue. As a work-around set pac_check = check_upn, check_upn_dns_info_ex in the [pac] section of sssd.conf. -- 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=2094685

1 16

[Bug 2095356] New: Password auth against FreeIPA server no longer works after update to Fedora 36
by bugzilla＠redhat.com 09 Jun '22

09 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=2095356 Bug ID: 2095356 Summary: Password auth against FreeIPA server no longer works after update to Fedora 36 Product: Fedora Version: 36 Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: boroske(a)ida.ing.tu-bs.de QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Created attachment 1888388 --> https://bugzilla.redhat.com/attachment.cgi?id=1888388&action=edit krb5_child.log of attempt to login using password auth I recently upgraded a fedora 35 system to fedora 36. After the upgrade, using any type of password auth against the freeipa server no longer works (ssh, su, sudo), only local user logins or ssh public key login. The problem seems to have to do with the new sssd package. I can see an error message in dmesg: [ 743.242553] sssd_be[848]: segfault at 18 ip 00007f9bd8b5559c sp 00007ffd21604bc0 error 4 in libc.so.6[7f9bd8aeb000+173000] I also enabled debug logging in sssd.conf and got error messages in /var/log/sssd/krb5_child.log excerpt (see attachment for full log of login attempt): [...] (2022-06-09 14:51:22): [krb5_child[1808]] [validate_tgt] (0x0400): [RID#18] TGT verified using key for [host/zeus.net.ida(a)NET.IDA] (2022-06-09 14:51:22): [krb5_child[1808]] [sss_child_krb5_trace_cb] (0x4000): [RID#18] [1808] 1654779082.856019: Retrieving thomasb(a)NET.IDA -> host/zeus.net.ida(a)NET.IDA from MEMORY:rd_req2 with result: 0/Success (2022-06-09 14:51:22): [krb5_child[1808]] [sss_extract_pac] (0x0040): [RID#18] No PAC authdata available. (2022-06-09 14:51:22): [krb5_child[1808]] [validate_tgt] (0x0020): [RID#18] PAC check failed for principal [thomasb(a)NET.IDA] (2022-06-09 14:51:22): [krb5_child[1808]] [sss_child_krb5_trace_cb] (0x4000): [RID#18] [1808] 1654779082.856020: Destroying ccache MEMORY:rd_req2 (2022-06-09 14:51:22): [krb5_child[1808]] [get_and_save_tgt] (0x0020): [RID#18] 2045: [1432158308][Unknown code UUz 100] (2022-06-09 14:51:22): [krb5_child[1808]] [map_krb5_error] (0x0020): [RID#18] [1432158308][PAC check failed]. (2022-06-09 14:51:22): [krb5_child[1808]] [k5c_send_data] (0x0200): [RID#18] Received error code 1432158308 (2022-06-09 14:51:22): [krb5_child[1808]] [pack_response_packet] (0x2000): [RID#18] response packet size: [20] (2022-06-09 14:51:22): [krb5_child[1808]] [k5c_send_data] (0x4000): [RID#18] Response sent. (2022-06-09 14:51:22): [krb5_child[1808]] [main] (0x0400): [RID#18] krb5_child completed successfully I had to rollback the system to before the update for now but am willing to attempt again if additional data is needed. -- 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=2095356

1 1

[Bug 2095086] New: ipa authentication fails after upgrade to 2.7.1
by bugzilla＠redhat.com 09 Jun '22

09 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=2095086 Bug ID: 2095086 Summary: ipa authentication fails after upgrade to 2.7.1 Product: Fedora Version: 36 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: dennis(a)ausil.us QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Description of problem: after upgrade of sssd from 2.7.0-1.fc36 to 2.7.1-1.fc36 I was unable to successfully authenticate. downgrading allowed authentication to work again Version-Release number of selected component (if applicable): sssd-2.7.1-1.fc36 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Jun 08 20:11:11 adria.ausil.us systemd[1]: Started sssd.service - System Security Services Daemon. Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1 Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1 Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 1 Jun 08 20:11:14 adria.ausil.us sssd_be[665011]: GSSAPI client step 2 Jun 08 20:11:35 adria.ausil.us krb5_child[665561]: Unknown code UUz 100 Jun 08 20:12:28 adria.ausil.us krb5_child[665845]: Unknown code UUz 100 Jun 08 20:12:50 adria.ausil.us krb5_child[665987]: Unknown code UUz 100 Expected results: Additional info: -- 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=2095086

1 5

[Bug 2095228] New: sssd_krb5 2.7.1 crashes "PAC check failed"
by bugzilla＠redhat.com 09 Jun '22

09 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=2095228 Bug ID: 2095228 Summary: sssd_krb5 2.7.1 crashes "PAC check failed" Product: Fedora Version: 36 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: seanmottles(a)posteo.net QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, luk.claes(a)gmail.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 Created attachment 1888304 --> https://bugzilla.redhat.com/attachment.cgi?id=1888304&action=edit sssd krb5 log file Description of problem: Attempting to authenticate via password on Fedora 36 host connected to FreeIPA with sssd 2.7.1-1 fails. ID lookups still function as normal. Version-Release number of selected component (if applicable): sssd-2.7.1-1.fc36 How reproducible: Every attempt. Steps to Reproduce: 1. Connect host to FreeIPA 2. Attempt to auth FreeIPA user via password 3. Actual results: "System Error" in /var/log/secure, and "PAC check failed for principal" in /var/log/sssd/krb5_child.log Expected results: Password auth is functional Additional info: Downgrading sssd to 2.7.0 resolves the issue and users can login as normal. -- 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=2095228

1 1

[Bug 2095176] New: sssd 2.7.1 cannot do Kerberos authentication [regression]
by bugzilla＠redhat.com 09 Jun '22

09 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=2095176 Bug ID: 2095176 Summary: sssd 2.7.1 cannot do Kerberos authentication [regression] Product: Fedora Version: 36 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: ossman(a)cendio.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, luk.claes(a)gmail.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 Description of problem: There is unfortunately something seriously broken in Kerberos part in sssd 2.7.1. We get the following in the auth log: > jun 09 08:43:48 samuel krb5_child[259734]: Unknown code UUz 100 > jun 09 08:43:48 samuel gdm-password][259724]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=samuel > jun 09 08:43:48 samuel gdm-password][259724]: pam_sss(gdm-password:auth): received for user samuel: 4 (System error) In sssd's log: > (2022-06-09 8:43:48): [be[cendio.se]] [krb5_auth_done] (0x3f7c0): [RID#331] The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information And in the krb5 child log: > (2022-06-09 8:43:57): [krb5_child[259752]] [sss_extract_pac] (0x0040): [RID#333] No PAC authdata available. > ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: > * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] krb5_child started. > * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x1000): [RID#333] total buffer size: [109] > * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x0100): [RID#333] cmd [241 (auth)] uid [4036] gid [21031] validate [true] enterprise principal [false] offline [false] UPN [samuel(a)CENDIO.SE] > * (2022-06-09 8:43:57): [krb5_child[259752]] [unpack_buffer] (0x0100): [RID#333] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab] > * (2022-06-09 8:43:57): [krb5_child[259752]] [switch_creds] (0x0200): [RID#333] Switch user to [4036][21031]. > * (2022-06-09 8:43:57): [krb5_child[259752]] [switch_creds] (0x0200): [RID#333] Switch user to [0][0]. > * (2022-06-09 8:43:57): [krb5_child[259752]] [k5c_check_old_ccache] (0x4000): [RID#333] Ccache_file is [KCM:] and is active and TGT is valid. > * (2022-06-09 8:43:57): [krb5_child[259752]] [k5c_setup_fast] (0x0100): [RID#333] Fast principal is set to [host/samuel.lkpg.cendio.se(a)CENDIO.SE] > * (2022-06-09 8:43:57): [krb5_child[259752]] [find_principal_in_keytab] (0x4000): [RID#333] Trying to find principal host/samuel.lkpg.cendio.se(a)CENDIO.SE in keytab. > * (2022-06-09 8:43:57): [krb5_child[259752]] [match_principal] (0x1000): [RID#333] Principal matched to the sample (host/samuel.lkpg.cendio.se(a)CENDIO.SE) > * (2022-06-09 8:43:57): [krb5_child[259752]] [check_fast_ccache] (0x0200): [RID#333] FAST TGT is still valid. > * (2022-06-09 8:43:57): [krb5_child[259752]] [become_user] (0x0200): [RID#333] Trying to become user [4036][21031]. > * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x2000): [RID#333] Running as [4036][21031]. > * (2022-06-09 8:43:57): [krb5_child[259752]] [set_lifetime_options] (0x0100): [RID#333] No specific renewable lifetime requested. > * (2022-06-09 8:43:57): [krb5_child[259752]] [set_lifetime_options] (0x0100): [RID#333] No specific lifetime requested. > * (2022-06-09 8:43:57): [krb5_child[259752]] [set_canonicalize_option] (0x0100): [RID#333] Canonicalization is set to [true] > * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] Will perform auth > * (2022-06-09 8:43:57): [krb5_child[259752]] [main] (0x0400): [RID#333] Will perform online auth > * (2022-06-09 8:43:57): [krb5_child[259752]] [tgt_req_child] (0x1000): [RID#333] Attempting to get a TGT > * (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0400): [RID#333] Attempting kinit for realm [CENDIO.SE] > * (2022-06-09 8:43:57): [krb5_child[259752]] [sss_krb5_responder] (0x4000): [RID#333] Got question [password]. > * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x2000): [RID#333] Found keytab entry with the realm of the credential. > * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0400): [RID#333] TGT verified using key for [host/samuel.lkpg.cendio.se(a)CENDIO.SE] > * (2022-06-09 8:43:57): [krb5_child[259752]] [sss_extract_pac] (0x0040): [RID#333] No PAC authdata available. > ********************** BACKTRACE DUMP ENDS HERE ********************************* > > (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0020): [RID#333] PAC check failed for principal [samuel(a)CENDIO.SE] > (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0020): [RID#333] 2045: [1432158308][Unknown code UUz 100] > ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: > * (2022-06-09 8:43:57): [krb5_child[259752]] [validate_tgt] (0x0020): [RID#333] PAC check failed for principal [samuel(a)CENDIO.SE] > * (2022-06-09 8:43:57): [krb5_child[259752]] [get_and_save_tgt] (0x0020): [RID#333] 2045: [1432158308][Unknown code UUz 100] > ********************** BACKTRACE DUMP ENDS HERE ********************************* > > (2022-06-09 8:43:57): [krb5_child[259752]] [map_krb5_error] (0x0020): [RID#333] [1432158308][PAC check failed]. Version-Release number of selected component (if applicable): sssd-2.7.1-1.fc36.x86_64 How reproducible: 100% Steps to Reproduce: 1. Upgrade sssd 2. Try to log in Actual results: Login fails Expected results: Login succeeds Additional info: Also reported to debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012502 Which also references this upstream PR: https://github.com/SSSD/sssd/pull/6204 -- 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=2095176

1 1

2024

2023

2022

2021

2020

Sssd-maintainers June 2022