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.comDOMAIN=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.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1886816
Bug ID: 1886816
Summary: [abrt] sssd-common: sss_mmap_cache_pw_store():
sssd_nss killed by SIGBUS
Product: Fedora
Version: 33
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:cd13c552f85949e67c1f8b9066dc4393eee0ce85;VAR
IANT_ID=workstation;
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: kparal(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,
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
Version-Release number of selected component:
sssd-common-2.3.1-4.fc33
Additional info:
reporter: libreport-2.14.0
backtrace_rating: 4
cgroup: 0::/system.slice/sssd.service
cmdline: /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
crash_function: sss_mmap_cache_pw_store
executable: /usr/libexec/sssd/sssd_nss
journald_cursor:
s=b2e7c0583c004ae8bd317a4440255076;i=2ee4a7;b=7c261537394f4d169971a59cd1761dfe;m=55626889;t=5b13c2149d0cf;x=8fed0b78d48ecd6c
kernel: 5.8.14-300.fc33.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 0
Truncated backtrace:
Thread no. 1 (10 frames)
#0 sss_mmap_cache_pw_store at src/responder/nss/nsssrv_mmap_cache.c:769
#1 nss_protocol_fill_pwent at src/responder/nss/nss_protocol_pwent.c:308
#2 nss_protocol_reply at src/responder/nss/nss_protocol.c:91
#3 nss_getby_done at src/responder/nss/nss_cmd.c:626
#4 tevent_common_invoke_immediate_handler at ../../tevent_immediate.c:166
#5 tevent_common_loop_immediate at ../../tevent_immediate.c:203
#6 epoll_event_loop_once at ../../tevent_epoll.c:917
#7 std_event_loop_once at ../../tevent_standard.c:110
#8 _tevent_loop_once at ../../tevent.c:772
#9 tevent_common_loop_wait at ../../tevent.c:895
--
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=1853261
Bug ID: 1853261
Summary: sssd fails to start on read-only filesystem
Product: Fedora
Version: rawhide
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: zbyszek(a)in.waw.pl
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:
sssd refuses to start when /var/log is read-only. It is obviously a problem
when trying to recover
from a file system issue. Since logging is non-essential, sssd should just
continue. At most is
should emit a warning.
$ touch /var/tmp/foo
touch: cannot touch '/var/tmp/foo': Read-only file system
$ sudo systemctl start sssd.service
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.
[fedora@workstation-uefi ~]$
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:46 CEST):
sssd[900]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[903]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[905]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[906]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[907]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
We see multiple issues here:
- the main one is that sssd should not fail to start as described above
- but also, why is sssd not just logging to the journal? Why is it spamming
with broadcast messages?
If sssd would just log to the journal like any modern service, all those
problems
would be avoided.
Version-Release number of selected component (if applicable):
sssd-2.3.0-2.fc33.x86_64
How reproducible:
Deterministic
Steps to Reproduce:
1. Make /var/log read-only, either by not remounting the filesystems rw, or by
using udev.blockdev-read-only with systemd-246+
2. Try to start sssd
--
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=1868696
Bug ID: 1868696
Summary: sssd_kcm loops on NFS server occasionally after an
NFSv4.0 mount using Kerberos
Product: Fedora
Version: 32
Hardware: All
OS: Linux
Status: NEW
Component: sssd
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: chuck.lever(a)oracle.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,
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:
Multi-homed Fedora 32 NFS client and server, both with keytabs. Sometimes after
performing an NFSv4.0 mount, the sssd_kcm daemon on the server runs at 100% and
fills up the sssd_kcm.log file (and eventually, the root partition).
(2020-08-10 15:03:04:680265): [kcm] [kcm_input_parse] (0x1000): Received
message with length 0
(2020-08-10 15:03:04:680284): [kcm] [kcm_input_parse] (0x0020): Illegal
zero-length message
(2020-08-10 15:03:04:680302): [kcm] [kcm_recv] (0x0010): Failed to parse
data (74, Bad message), aborting client
(2020-08-10 15:03:04:680319): [kcm] [kcm_reply_error] (0x0040): KCM
operation returs failure [74]: Bad message
(2020-08-10 15:03:04:680353): [kcm] [kcm_failbuf_construct] (0x1000): Sent
reply with error -1765328188
Version-Release number of selected component (if applicable):
sssd-kcm-2.3.1-2.fc32.x86_64
How reproducible:
Happens every second or third mount operation.
Steps to Reproduce:
1. Set up NFS client and server with keytabs
2. Repeat: "mount -o vers=4.0,sec=sys" / do some operations / umount
3. Watch the server with "top"
Actual results:
Sometimes sssd_kcm goes to 100% of a CPU and must be killed.
Expected results:
No looping.
Additional info:
The NFSv4.0 backchannel, in this case, is secured with GSS krb5i. It appears
that gssd on the server is accessing the Kerberos ticket cache while setting up
the backchannel, and sometimes this triggers the kcm loop.
--
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=1884912
Bug ID: 1884912
Summary: [abrt] sssd-common: __strcmp_avx2(): sssd_be killed by
SIGSEGV
Product: Fedora
Version: 32
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:a07038fd78acc47fd66b266203cafebd50509e00;VAR
IANT_ID=workstation;
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: rbrattai(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,
mzidek(a)redhat.com, pbrezina(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com
Target Milestone: ---
Group: fedora_contrib_private
Classification: Fedora
Description of problem:
Always happens when the Kerberos tickets expire after letting the system sit
overnight.
Log in to Redhat krbtgt/REDHAT.COM(a)REDHAT.COM
let the system sit overnight, or until ticket expires
try to login via gdm or vt
login fails
Version-Release number of selected component:
sssd-common-2.3.1-2.fc32
Additional info:
reporter: libreport-2.13.1
backtrace_rating: 4
cgroup: 0::/system.slice/sssd.service
cmdline: /usr/libexec/sssd/sssd_be --domain redhat.com --uid 0 --gid 0
--logger=files
crash_function: __strcmp_avx2
executable: /usr/libexec/sssd/sssd_be
journald_cursor:
s=a7dff00ea3904bcf94e9c47f3af11249;i=99168;b=d69fa027bac74e0c82bae802fce15dc2;m=8e9b12f6b4;t=5b0c43dd4cdcb;x=5af4a1ece75efc5a
kernel: 5.7.17-200.fc32.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 0
Truncated backtrace:
Thread no. 1 (10 frames)
#0 __strcmp_avx2 at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:101
#1 be_resolve_server_process at src/providers/data_provider_fo.c:671
#2 be_resolve_server_done at src/providers/data_provider_fo.c:555
#3 fo_resolve_service_server at src/providers/fail_over.c:1165
#4 _tevent_req_error at ../../tevent_req.c:211
#5 resolve_srv_done at src/providers/fail_over.c:1466
#6 fo_discover_srv_done at src/providers/fail_over_srv.c:141
#7 resolv_discover_srv_done at src/resolv/async_resolv_utils.c:302
#8 resolv_getsrv_done at src/resolv/async_resolv.c:1762
#9 qcallback at /usr/src/debug/c-ares-1.15.0-5.fc32.x86_64/ares_query.c:183
Potential duplicate: bug 1773488
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1910169
Bug ID: 1910169
Summary: sssd-kcm causing periodic auth failures after 2.4.0-2
Product: Fedora
Version: 33
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: rwf(a)loonybin.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,
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
sssd-kcm is causing periodic auth failures on builds newer than 2.4.0-2,
presumably due to an issue introduced with the (surprising number of) patches
applied in 2.4.0-3. (Incidentally, CPU usage by the process has gotten
substantially worse in these versions, as well.)
This manifests as all plaintext auth failing on Fedora 33 systems running sssd
2.4.0-4, joined to a FreeIPA domain and authenticating domain users, which will
emit errors like the following examples for the lifetime of the sssd-kcm
process that incurred the problem:
Dec 22 17:59:11 fedora33 systemd[1]: Starting SSSD Kerberos Cache Manager...
Dec 22 17:59:11 fedora33 systemd[1]: Started SSSD Kerberos Cache Manager.
Dec 22 17:59:11 fedora33 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'
Dec 22 17:59:11 fedora33 kcm[10556]: Starting up
Dec 22 17:59:11 fedora33 krb5_child[10554][10554]: Generic error (see e-text)
Dec 22 17:59:11 fedora33 krb5_child[10554][10554]: Generic error (see e-text)
Dec 22 17:59:11 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication
failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1
user=rob
Dec 22 17:59:11 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user
rob: 4 (System error)
Dec 22 17:59:19 fedora33 krb5_child[10559][10559]: Generic error (see e-text)
Dec 22 17:59:19 fedora33 krb5_child[10559][10559]: Generic error (see e-text)
Dec 22 17:59:19 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication
failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1
user=rob
Dec 22 17:59:19 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user
rob: 4 (System error)
Dec 22 17:59:29 fedora33 krb5_child[10562][10562]: Generic error (see e-text)
Dec 22 17:59:29 fedora33 krb5_child[10562][10562]: Generic error (see e-text)
Dec 22 17:59:29 fedora33 auth[10552]: pam_sss(dovecot:auth): authentication
failure; logname= uid=97 euid=97 tty=dovecot ruser=rob rhost=2001:db8::1
user=rob
Dec 22 17:59:29 fedora33 auth[10552]: pam_sss(dovecot:auth): received for user
rob: 4 (System error)
Nothing else is logged anywhere. Also affected are sudo and the like, but not
any authentication using Kerberos tickets. Relatively short-lived workarounds
include waiting it out (sssd-kcm process exits, next auth attempt spawns a new
one and succeeds) or rebooting the host. klist as affected users during these
events reports no KCM cache for the respective UID available, and kinit also
usually fails with the same 'Generic error' text until the sssd-kcm process
goes away. Downgrading sssd* packages to 2.4.0-2 restores correct behavior.
--
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=1881630
Bug ID: 1881630
Summary: ipatests-only: kinit_as_user should collect
kdcinfo.REALM on failure
Product: Red Hat Enterprise Linux 8
Version: 8.3
Status: NEW
Component: ipa
Assignee: twoerner(a)redhat.com
Reporter: fcami(a)redhat.com
QA Contact: ipa-qe(a)redhat.com
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
extras-qa(a)fedoraproject.org, jhrozek(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
nalin(a)redhat.com, npmccallum(a)redhat.com,
pbrezina(a)redhat.com, rcritten(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org,
tibbs(a)math.uh.edu, tscherf(a)redhat.com
Depends On: 1850445
Target Milestone: rc
Classification: Red Hat
Pool ID: sst_identity_management_rhel_8
When requesting a tgt fails after a password reset, collecting:
/var/lib/sss/pubconf/kdcinfo.$REALM
will help determine how SSSD was selecting which KRB5KDC to use.
See https://pagure.io/freeipa/issue/8510 for details.
+++ This bug was initially created as a clone of Bug #1850445 +++
kinit switches KDC for each action.
It would be better if it kept track of which KDC to use, because on password
change, it sometimes contacts one KDC to change the password and then another
one, immediately, to get a TGT, which fails because replication between the two
KDCs has not completed yet.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:513 RUN
KRB5_TRACE=/dev/stdout kinit nonadmin
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325347: Resolving unique ccache of type KCM
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325348: Getting initial credentials for nonadmin(a)IPA.TEST
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325350: Sending unauthenticated request
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325351: Sending request (172 bytes) to IPA.TEST
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325352: Resolving hostname master.ipa.test
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325353: Initiating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325354: Sending TCP request to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325355: Received answer (147 bytes) from stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325356: Terminating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325357: Response was from master KDC
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325358: Received error from KDC: -1765328361/Password has expired
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325359: Principal expired; getting changepw ticket
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325360: Getting initial credentials for nonadmin(a)IPA.TEST
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325361: Setting initial creds service to kadmin/changepw
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325363: Sending unauthenticated request
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325364: Sending request (172 bytes) to IPA.TEST (master)
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325365: Resolving hostname master.ipa.test
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325366: Initiating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325367: Sending TCP request to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325368: Received answer (496 bytes) from stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325369: Terminating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325370: Received error from KDC: -1765328359/Additional
pre-authentication required
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325373: Preauthenticating using KDC method data
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325374: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST
(136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151),
PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325375: Selected etype info: etype aes256-cts, salt
".\#7bJ)L)J"mP,T7", params ""
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325376: Received cookie:
MIT1\x00\x00\x00\x01\xe0w\xf7\xd1|$\xa4\x14\x01\xea\x08\x0c\xe7\xf6&\xd6\xb0\x8d\xd1\x9dw/\x98\x14\x81\xe2\xf372\xc5\xb6\xc0k^\xd1\x9b\xe3R\xd4?^\x11\xecyd\x05\xb5>\x93\xdd\x94\x0e\x0a\xc7.\xb2\x84E\xb7El\x87\xbaa\x9b\xae\x9e\xa6d\xf4\xf7m\xf4W\x11~]\xfecR@[\xef\xdc3W\x1f\xe8\xa7\x07\xae\xd5\x12\x15\xc4\xa2\xb6\xa0\x0b\xab\x09cv\x8741s\x18\xc9\xee\xa9\x13Qu\xd6+\xb7\xe9\xf8V\xf0\xf9@\x95\xbb\x8c\x9d\x92\xcb\xbd
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325377: PKINIT client has no configured identity; giving up
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325378: Preauth module pkinit (147) (info) returned: 0/Success
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325379: PKINIT client received freshness token from KDC
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325380: Preauth module pkinit (150) (info) returned: 0/Success
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325381: PKINIT client has no configured identity; giving up
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325382: Preauth module pkinit (16) (real) returned: 22/Invalid
argument
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325383: SPAKE challenge received with group 1, pubkey
1B0BEF657989B0A997331DC1C3FE27B3DDA988E0CCDE4AD1953E63654308BB8A
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557
Password for nonadmin(a)IPA.TEST:
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325384: SPAKE key generated with pubkey
E7799A68439AF32E18B1899FA0D7145F70FD5345C6F59F5EB4463754CE1C45C3
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325385: SPAKE algorithm result:
F305A9105E6AE9531D6F6041EE348B146FB937039B3FFA1BD3A614638269AA91
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325386: SPAKE final transcript hash:
273E7D21D701511A5FEB8D9EE1A817D34F4CFE0DA9849260A6D3654B59A7A965
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325387: Sending SPAKE response
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325388: Preauth module spake (151) (real) returned: 0/Success
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325389: Produced preauth for next request: PA-FX-COOKIE (133),
PA-SPAKE (151)
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325390: Sending request (431 bytes) to IPA.TEST (master)
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325391: Resolving hostname master.ipa.test
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325392: Initiating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325393: Sending TCP request to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325394: Received answer (1521 bytes) from stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325395: Terminating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325396: AS key determined by preauth: aes256-cts/108D
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325397: Decrypted AS reply; session key is: aes256-cts/755F
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325398: FAST negotiation: available
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325399: Attempting password change; 3 tries remaining
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557
Password expired. You must change it now.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 Enter
new password:
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 Enter
it again:
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325401: Creating authenticator for nonadmin(a)IPA.TEST ->
kadmin/changepw(a)IPA.TEST, seqnum 0, subkey aes256-cts/D865, session key
aes256-cts/755F
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325403: Sending DNS URI query for _kpasswd.IPA.TEST.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325404: No URI records found
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325405: Sending DNS SRV query for _kpasswd._udp.IPA.TEST.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325406: SRV answer: 0 100 464 "replica0.ipa.test."
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325407: SRV answer: 0 100 464 "master.ipa.test."
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325408: Sending DNS SRV query for _kpasswd._tcp.IPA.TEST.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325409: SRV answer: 0 100 464 "replica0.ipa.test."
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325410: SRV answer: 0 100 464 "master.ipa.test."
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325411: Resolving hostname replica0.ipa.test.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325412: Resolving hostname master.ipa.test.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325413: Resolving hostname replica0.ipa.test.
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325414: Initiating TCP connection to stream 192.168.122.43:464
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325415: Sending TCP request to stream 192.168.122.43:464
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325416: Received answer (236 bytes) from stream 192.168.122.43:464
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325417: Terminating TCP connection to stream 192.168.122.43:464
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325418: Read AP-REP, time 1592990743.325402, subkey aes256-cts/D865,
seqnum 469261493
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325419: Getting initial TGT with changed password
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325420: Getting initial credentials for nonadmin(a)IPA.TEST
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325422: Sending unauthenticated request
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325423: Sending request (172 bytes) to IPA.TEST (master)
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325424: Resolving hostname master.ipa.test
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325425: Initiating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325426: Sending TCP request to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 kinit:
Password has expired while getting initial credentials
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325427: Received answer (147 bytes) from stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325428: Terminating TCP connection to stream 192.168.122.35:88
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:557 [24275]
1592990743.325429: Received error from KDC: -1765328361/Password has expired
DEBUG
ipatests.pytest_ipa.integration.host.Host.master.cmd64:transport.py:217 Exit
code: 1
ERROR ipatests.pytest_ipa.integration.host.Host.master.cmd64:host.py:199
stderr: kinit: Password has expired while getting initial credentials
full logs:
http://freeipa-org-pr-ci.s3-website.eu-central-1.amazonaws.com/jobs/3966b69…
--- Additional comment from Sumit Bose on 2020-06-24 15:43:03 UTC ---
Hi,
do you know if SSSD is running during the test? If yes, can you check if
/var/lib/sss/pubconf/kdcinfo.IPA.TEST exists and contains one or more IP
addresses of IPA servers? This file is read by SSSD's locator plugin which
should make sure libkrb5 uses the same KDC for a long time.
bye,
Sumit
--- Additional comment from François Cami on 2020-06-24 16:22:57 UTC ---
Hi Sumit,
The machine logs for the test are available at:
http://freeipa-org-pr-ci.s3-website.eu-central-1.amazonaws.com/jobs/3966b69…
The timestamp for the error is 1592990743.325347 (Wednesday, June 24, 2020
9:25:43.325 AM) and the journal seems to imply SSSD was started at this point.
Sadly the VMs used for the test are ephemeral and the above test fails only
sporadically.
I will add a step to display /var/lib/sss/pubconf/kdcinfo.IPA.TEST similarly to
the way I added KRB5_TRACE=/dev/stdout to get more information.
Thanks,
François
--- Additional comment from Robbie Harwood on 2020-06-25 19:09:32 UTC ---
Would also like to see the sssd information.
(I will note that krb5 expects there to be a single master_kdc that is
authoratative for password changes. If that address resolves to multiple KDCs,
they need to agree on the state of the world.)
--- Additional comment from François Cami on 2020-06-25 19:36:57 UTC ---
Robbie, do you need more information than what is seen in the PR:
https://github.com/freeipa/freeipa/pull/4853
Especially: https://github.com/freeipa/freeipa/pull/4853#issuecomment-649235842
The test blows up very sporadically. I've triggered it 16 times today without
any issue.
If within a month I haven't seen it red, I will trigger a 100+ run and we might
get a bad run with interesting logs.
--- Additional comment from Robbie Harwood on 2020-06-25 20:51:09 UTC ---
Ah sorry, race condition - I started my comment before yours appeared. I've
subscribed to the issue. Per #c3, I think that master_kdc isn't being
correctly used - it seems like Sumit is investigating where the multiple values
come from.
--- Additional comment from Sumit Bose on 2020-06-26 11:30:23 UTC ---
(In reply to Robbie Harwood from comment #5)
> Ah sorry, race condition - I started my comment before yours appeared. I've
> subscribed to the issue. Per #c3, I think that master_kdc isn't being
> correctly used - it seems like Sumit is investigating where the multiple
> values come from.
Hi,
in the current logs there was only one IP address and this will be used for the
master as well. As long there is a kdcinfo file SSSD's Kerberos locator plugin
should use the data and iirc libkrb5 will always ask the available locator
plugins first before trying other methods to find a KDC. Since the KRB5_TRACE
output in the description has e.g. 'Sending DNS URI query for
_kpasswd.IPA.TEST.' I would expect that the kdcinfo file did not exist in this
run. Maybe SSSD had some delays when trying to connect to the IPA server and as
a result the creation of the kdcinfo file was delayed as wel?
bye,
Sumit
--- Additional comment from Robbie Harwood on 2020-09-10 17:31:13 UTC ---
Moving to sssd based on #c6.
--- Additional comment from François Cami on 2020-09-22 18:58:49 UTC ---
ipatests PR to collect that kdcinfo file:
https://github.com/freeipa/freeipa/pull/5128
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1850445
[Bug 1850445] kinit switches servers after password change
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1904592
Bug ID: 1904592
Summary: gkr-pam: unable to locate daemon control file
Product: Fedora
Version: 33
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: email(a)linuxtricks.fr
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:
Same problem than https://bugzilla.redhat.com/show_bug.cgi?id=1796544 closed by
EOL
Unable to login from GDM to an Active Directory Account :
Dec 04 22:23:07 w-dij-inf-2-lnx gdm-password][1624]:
pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0
tty=/dev/tty1 ruser= rhost= user=juliette.canard(a)LINUXTRICKS.LAN
Dec 04 22:23:07 w-dij-inf-2-lnx gdm-password][1624]: gkr-pam: unable to locate
daemon control file
Dec 04 22:23:07 w-dij-inf-2-lnx gdm-password][1624]: gkr-pam: stashed password
to try later in open session
Dec 04 22:23:07 w-dij-inf-2-lnx gdm-password][1624]:
pam_sss(gdm-password:account): Access denied for user
juliette.canard(a)LINUXTRICKS.LAN: 6 (Autorisation refusée)
Version-Release number of selected component (if applicable):
Fedora 33 Workstation
How reproducible:
Always
Steps to Reproduce:
1. Install fedora Workstation 33
2. After installing add a local account
3. From this local account, join to domain adding in the GNOME control center
an account which can join computers on domain
4. Logout
5. try to login with an other account which is in the Active Directory on GDM
Actual results:
Sorry, unable to connect
Expected results:
Connection
Additional info:
Connecting from the local account into the terminal (gnome-terminal) with
command line (su - user(a)domain.lan) works
--
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=1917429
Bug ID: 1917429
Summary: sssd: FTBFS in Fedora rawhide
Product: Fedora
Version: rawhide
URL: https://koschei.fedoraproject.org/package/sssd
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: thrnciar(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,
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:
Package sssd fails to build from source in Fedora rawhide.
Version-Release number of selected component (if applicable):
2.4.0-6.fc34
Steps to Reproduce:
koji build --scratch f34 sssd-2.4.0-6.fc34.src.rpm
Additional info:
This package is tracked by Koschei. See:
https://koschei.fedoraproject.org/package/sssd
RPM build errors:
File not found:
/builddir/build/BUILDROOT/sssd-2.4.0-6.fc34.x86_64/usr/lib/systemd/system/sssd-pac.socket
File not found:
/builddir/build/BUILDROOT/sssd-2.4.0-6.fc34.x86_64/usr/lib/systemd/system/sssd-pac.service
--
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=1885874
Bug ID: 1885874
Summary: double free in sss_to_sudoers
Product: Fedora
Version: 32
OS: Linux
Status: NEW
Component: sssd
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: avi.kivity(a)gmail.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,
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:
Running 'sudo -s' crashes with
free(): double free detected in tcache 2
Version-Release number of selected component (if applicable):
sudo-1.9.2-1.fc32.x86_64
sssd-2.3.1-2.fc32.x86_64
How reproducible:
Always (on one machine)
Steps to Reproduce:
1. sudo -s
Actual results:
free(): double free detected in tcache 2
Expected results:
Root superpowers
Additional info:
This is a freeipa enrolled machine.
Backtrace:
(gdb) bt
#0 0x00007fdb051ae9e5 in raise () from /lib64/libc.so.6
#1 0x00007fdb05197895 in abort () from /lib64/libc.so.6
#2 0x00007fdb051f2857 in __libc_message () from /lib64/libc.so.6
#3 0x00007fdb051f9d7c in malloc_printerr () from /lib64/libc.so.6
#4 0x00007fdb051fb38d in _int_free () from /lib64/libc.so.6
#5 0x00007fdb056fa205 in sss_sudo_free_values () from
/usr/lib64/libsss_sudo.so
#6 0x00007fdaf779faaf in sss_rule_to_priv (rc_out=<synthetic pointer>,
rule=0x564ee50595d0, handle=0x564ee5055690) at ./sssd.c:336
#7 sss_to_sudoers (sss_result=0x564ee5057d50, handle=0x564ee5055690) at
./sssd.c:398
#8 sudo_sss_query (nss=<optimized out>, pw=<optimized out>) at ./sssd.c:684
#9 0x00007fdaf778f9b9 in sudoers_lookup (snl=<optimized out>,
pw=0x564ee5054d78, validated=validated@entry=96, pwflag=pwflag@entry=0) at
./parse.c:297
#10 0x00007fdaf77994ca in sudoers_policy_main (argc=argc@entry=1,
argv=argv@entry=0x564ee504aa80, pwflag=pwflag@entry=0,
env_add=env_add@entry=0x0, verbose=verbose@entry=false,
closure=closure@entry=0x7fff1050fc70) at ./sudoers.c:368
#11 0x00007fdaf7792090 in sudoers_policy_check (argc=1, argv=0x564ee504aa80,
env_add=0x0, command_infop=0x7fff1050fd30, argv_out=0x7fff1050fd38,
user_env_out=0x7fff1050fd40,
errstr=0x7fff1050fd58) at ./policy.c:974
#12 0x0000564ee349b14d in policy_check (user_env_out=0x7fff1050fd40,
argv_out=0x7fff1050fd38, command_info=0x7fff1050fd30, env_add=0x0,
argv=0x564ee504aa80, argc=1) at ./sudo.c:1162
#13 main (argc=<optimized out>, argv=<optimized out>, envp=0x7fff1050ffd0) at
./sudo.c:267
(gdb)
--
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=1897205
Bug ID: 1897205
Summary: SSSD fails to start when run as non-root user
Product: Fedora
Version: 33
OS: Linux
Status: NEW
Component: sssd
Severity: urgent
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: apeetham(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,
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:
SSSD service fails to restart, when "user = sssd" is set in SSSD.CONF, we don't
see this behaviour in downstream RHEL-8.3 / RHEL-8.4 systems.
Version-Release number of selected component (if applicable):
sssd-2.4.0-2.fc33.x86_64
libsss_simpleifp-2.4.0-2.fc33.x86_64
How reproducible: Always
Steps to Reproduce:
1. Configure sssd.conf as follows:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, ifp
debug_level = 0xFFF0
user = sssd
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[ifp]
allowed_uids = root
user_attributes = +mail, +givenname, +sn
debug_level = 0xFFF0
2. Restart SSSD service, it fails with error.
# systemctl restart sssd; systemctl status sssd
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor
preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2020-11-12
20:27:20 IST; 10ms ago
Process: 6678 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited,
status=4)
Main PID: 6678 (code=exited, status=4)
CPU: 15ms
Nov 12 20:27:20 mojito.redhat.com systemd[1]: Failed to start System Security
Services Daemon.
3. Below is the sssd.log contents, logged right after service restart:
(2020-11-12 20:27:20): [sssd] [monitor_quit_signal] (0x2000): Received shutdown
command
(2020-11-12 20:27:20): [sssd] [monitor_quit_signal] (0x0040): Monitor received
Terminated: terminating children
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0040): Returned with: 0
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Terminating [ifp][6526]
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Child [ifp] exited
gracefully
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Terminating [pam][6525]
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Child [pam] terminated
with a signal
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Terminating [nss][6524]
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Child [nss] exited
gracefully
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Terminating
[implicit_files][6523]
(2020-11-12 20:27:20): [sssd] [monitor_quit] (0x0020): Child [implicit_files]
exited gracefully
(2020-11-12 20:27:20): [sssd] [watch_ctx_destructor] (0x2000): Closing inotify
fd 0
(2020-11-12 20:27:20:592247): [sssd] [get_service_user] (0x0010): Failed to set
allowed UIDs.
(2020-11-12 20:27:20:592289): [sssd] [get_monitor_config] (0x0020): Failed to
get the unprivileged user
(2020-11-12 20:27:20:592325): [sssd] [main] (0x0020): SSSD couldn't load the
configuration database.
(2020-11-12 20:27:20:860946): [sssd] [get_service_user] (0x0010): Failed to set
allowed UIDs.
(2020-11-12 20:27:20:861023): [sssd] [get_monitor_config] (0x0020): Failed to
get the unprivileged user
(2020-11-12 20:27:20:861077): [sssd] [main] (0x0020): SSSD couldn't load the
configuration database.
(2020-11-12 20:27:21:099530): [sssd] [get_service_user] (0x0010): Failed to set
allowed UIDs.
(2020-11-12 20:27:21:099570): [sssd] [get_monitor_config] (0x0020): Failed to
get the unprivileged user
(2020-11-12 20:27:21:099609): [sssd] [main] (0x0020): SSSD couldn't load the
configuration database.
(2020-11-12 20:27:21:354551): [sssd] [get_service_user] (0x0010): Failed to set
allowed UIDs.
(2020-11-12 20:27:21:354631): [sssd] [get_monitor_config] (0x0020): Failed to
get the unprivileged user
(2020-11-12 20:27:21:354678): [sssd] [main] (0x0020): SSSD couldn't load the
configuration database.
(2020-11-12 20:27:21:596433): [sssd] [get_service_user] (0x0010): Failed to set
allowed UIDs.
(2020-11-12 20:27:21:596565): [sssd] [get_monitor_config] (0x0020): Failed to
get the unprivileged user
(2020-11-12 20:27:21:596672): [sssd] [main] (0x0020): SSSD couldn't load the
configuration database.
Actual results:
SSSD fails to restart.
Expected results:
Like rhel-8.4, sssd service should restart without issues.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.