April 2023 - 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 2168743] New: Known valid Windows AD Domain credential refused for domain "joined" F37 workstation
by bugzilla＠redhat.com 13 Jan '24

13 Jan '24

https://bugzilla.redhat.com/show_bug.cgi?id=2168743 Bug ID: 2168743 Summary: Known valid Windows AD Domain credential refused for domain "joined" F37 workstation Product: Fedora Version: 37 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: cjm(a)tryx.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 Created attachment 1943194 --> https://bugzilla.redhat.com/attachment.cgi?id=1943194&action=edit /var/log/sssd/sssd_TCLC.org.log Description of problem: login:cjm@tclc.org Password: Permission denied Version-Release number of selected component (if applicable): sssd version: 2.8.2 How reproducible: 100% Steps to Reproduce: 1. Join the Fedora workstation to the Windows AD Domain 2. Log in as a user with known valid credentials. Credentials are known to be good because they have worked for ten years on a Windows workstation domain member. Actual results: login:cjm@tclc.org Password: Permission denied Expected results: login:cjm@tclc.org Password: $ Additional info: # adcli info adcli: specify a domain to discover [root@worx ~]# adcli info tclc.org [domain] domain-name = TCLC.org domain-short = TCLC domain-forest = TCLC.org domain-controller = Aequitas.TCLC.org domain-controller-site = Default-First-Site-Name domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret ads-web domain-controller-usable = yes domain-controllers = Aequitas.TCLC.org [computer] computer-site = Default-First-Site-Name # adcli show-computer -U sa Password for sa(a)TCLC.ORG: sAMAccountName: WORX$ userPrincipalName: - not set - msDS-KeyVersionNumber: 3 msDS-supportedEncryptionTypes: 24 dNSHostName: worx.tclc.org servicePrincipalName: RestrictedKrbHost/worx.tclc.org RestrictedKrbHost/WORX host/worx.tclc.org host/WORX operatingSystem: redhat-linux-gnu operatingSystemVersion: - not set - operatingSystemServicePack: - not set - pwdLastSet: 133204401440679346 userAccountControl: 69632 description: - not set - -- 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=2168743

1 22

[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 2185785] New: sss_ssh_knownhostsproxy does not exit after disconnect from libssh, leaks memory
by bugzilla＠redhat.com 28 Apr '23

28 Apr '23

https://bugzilla.redhat.com/show_bug.cgi?id=2185785 Bug ID: 2185785 Summary: sss_ssh_knownhostsproxy does not exit after disconnect from libssh, leaks memory Product: Fedora Version: 37 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: mpitt(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: In https://github.com/cockpit-project/cockpit/issues/18310 we got a report of leaked sss_ssh_knownhostsproxy processes which eat up quite a lot of RAM and keep SSH connections open to target hosts even after the parent ssh client went away. The user logs in to cockpit locally, then starts a remote cockpit session through SSH (cockpit-ssh in particular, which uses libssh), then logs out. Logging out SIGTERMs the cockpit-ssh process. That then goes away, but the sss_ssh_knownhostsproxy child doesn't exit, but gets reparented to pid 1. It also keeps the SSH connection open still. Version-Release number of selected component (if applicable): sssd-common-2.8.2-1.fc37.x86_64 libssh-0.10.4-2.fc37.x86_64 cockpit-bridge-289-1.fc37.x86_64 How reproducible: Always Steps to Reproduce: 1. Join a machine to a FreeIPA domain, and log in as IPA user. This should create /etc/ssh/ssh_config.d/04-ipa.conf with a ProxyCommand for sss_ssh_knownhostsproxy 2. Set up an SSH key and add it to ~/.ssh/authorized_keys; you should be able to do "ssh `hostname`" *without* an "unknown host key" prompt (thanks to sss_ssh_knownhostsproxy) and *without* a password prompt (due to using key login). 3. dnf install cockpit-bridge 3. Run an SSH session through libssh, and kill it: (printf '\n\n\n\n\n\n'; sleep 20) | /usr/libexec/cockpit-ssh `hostname` & sleep 1 && pkill -e cockpit-ssh Actual results: The SSH logind session hangs on shutdown: Since: Tue 2023-04-11 05:22:06 UTC; 1min 36s ago Leader: 2935 TTY: web console Remote: ::ffff:172.27.0.2 Service: cockpit; type web; class user State: closing Unit: session-11.scope └─3025 /usr/bin/sss_ssh_knownhostsproxy -p 22 x0.cockpit.lan The cockpit-ssh process is gone, but there are three leaked processes: admin@c+ 5572 0.0 0.8 16624 5632 pts/1 S 07:40 0:00 /usr/bin/sss_ssh_knownhostsproxy -p 22 x0.cockpit.lan root 5573 0.0 2.0 47060 13184 ? Ss 07:40 0:00 sshd: admin(a)cockpit.lan [priv] admin@c+ 5594 0.0 1.1 47060 7320 ? S 07:40 0:00 sshd: admin@cockpit.lan@notty strace -p 5572 says restart_syscall(<... resuming interrupted read ...> but it's not clear from what it tries to read. This does *not* reproduce with "ssh `hostname` sleep 20" and killing that ssh process. So this is some condition that only libssh triggers. I know that this isn't an ideal reproducer for you. Do you have some idea how to debug that further? Enable some debug logging or so? (it's an user process, so it can't log to /var/log/sssd/) Thanks! -- 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=2185785

1 8

[Bug 2107824] New: User logins doesn't use right kerberos tickets for cifs.upcall
by bugzilla＠redhat.com 26 Apr '23

26 Apr '23

https://bugzilla.redhat.com/show_bug.cgi?id=2107824 Bug ID: 2107824 Summary: User logins doesn't use right kerberos tickets for cifs.upcall Product: Fedora Version: 36 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: low Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: kamarasu(a)aol.in 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 1897647 --> https://bugzilla.redhat.com/attachment.cgi?id=1897647&action=edit ssd_gdm_cifs_autofs Description of problem: User logins doesn't use right kerberos tickets for cifs.upcall at first attempt, I've noticed this issue while login through GDM, I think it happens same with ssh as well. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Setup multiuser cifs automount map served from NAS 2. Install fedora 36 linux and perform realm join to SAMBA(AD role) 3. update /etc/dconf/profile/user with service-db:keyfile/user 4.Login through GDM Actual results: Jul 16 12:35:48 bullseye.int.lan kernel: FS-Cache: Loaded Jul 16 12:35:48 bullseye.int.lan kernel: Key type dns_resolver registered Jul 16 12:35:48 bullseye.int.lan kernel: Key type cifs.spnego registered Jul 16 12:35:48 bullseye.int.lan kernel: Key type cifs.idmap registered Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount. Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: Attempting to mount \\nas.int.lan\home Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=nas.int.lan;ip4=192.168.1.10;sec=krb5;uid=0x0;creduid=0x2a;user=gdm;pid=0x636 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: ver=2 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: host=nas.int.lan Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: ip=192.168.1.10 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: sec=1 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: uid=0 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: creduid=42 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: user=gdm Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1604]: pid=1590 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_cachename_from_process_env: pathname=/proc/1590/environ Jul 16 12:35:48 bullseye.int.lan systemd[1]: Starting sssd-kcm.service - SSSD Kerberos Cache Manager... Jul 16 12:35:48 bullseye.int.lan systemd[1]: Started sssd-kcm.service - SSSD Kerberos Cache Manager. Jul 16 12:35:48 bullseye.int.lan audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jul 16 12:35:48 bullseye.int.lan sssd_kcm[1606]: Starting up Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_existing_cc: default ccache is KCM:42 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: get_tgt_time: unable to get principal Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: krb5_get_init_creds_keytab: -1765328378 Jul 16 12:35:48 bullseye.int.lan cifs.upcall[1603]: Exit status 1 Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: \\nas.int.lan Send error in SessSetup = -126 Jul 16 12:35:48 bullseye.int.lan kernel: CIFS: VFS: cifs_mount failed w/return code = -126 Expected results: cifs.spnego user suppose to be the one specified at login prompt and it should not be user=gdm Additional info: But few seconds later the mount cifs.upcall goes well as below Jul 16 12:36:55 bullseye.int.lan kernel: CIFS: Attempting to mount \\nas.int.lan\home Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=nas.int.lan;ip4=192.168.1.10;sec=krb5;uid=0x0;creduid=0x48d02750;user=kamarasu;pid=0xb48 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: ver=2 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: host=nas.int.lan Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: ip=192.168.1.10 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: sec=1 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: uid=0 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: creduid=1221601104 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: user=kamarasu Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2892]: pid=2888 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: get_cachename_from_process_env: pathname=/proc/2888/environ Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: get_existing_cc: default ccache is KCM:1221601104:18284 Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: handle_krb5_mech: getting service ticket for nas.int.lan Jul 16 12:36:55 bullseye.int.lan cifs.upcall[2891]: handle_krb5_mech: ob Please see the attachment ssd_gdm_cifs_autofs [root@bullseye cloud-user]# automount -m Mount point: /home/int.lan source(s): instance type(s): sss map: auto.home * | -fstype=cifs -rw -sec=krb5i -multiuser -user=$USER -cruid=$UID -cifsacl ://nas.int.lan/home [root@bullseye cloud-user]# cat /etc/sssd/sssd.conf [sssd] domains = int.lan config_file_version = 2 services = nss, pam, autofs [domain/int.lan] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = INT.LAN realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%d/%u ad_domain = int.lan use_fully_qualified_names = False ldap_id_mapping = True #access_provider = ad autofs_provider = ad [root@bullseye cloud-user]# mount |grep nas //nas.int.lan/home on /home/int.lan/kamarasu type cifs (rw,relatime,vers=3.1.1,sec=krb5i,cruid=1221601104,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.10,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,cifsacl,noperm,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=kamarasu) -- 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=2107824

1 4

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 25 Apr '23

25 Apr '23

https://bugzilla.redhat.com/show_bug.cgi?id=2111582 Alexey Tikhonov <atikhono(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution|--- |CURRENTRELEASE Last Closed| |2023-04-25 18:55:15 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2111582

1 0

[Bug 2111582] virtqemud deadlocking
by bugzilla＠redhat.com 25 Apr '23

25 Apr '23

https://bugzilla.redhat.com/show_bug.cgi?id=2111582 --- Comment #18 from Ben Cotton <bcotton(a)redhat.com> --- This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2111582

1 0

2024

2023

2022

2021

2020

Sssd-maintainers April 2023