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=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.
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
https://bugzilla.redhat.com/show_bug.cgi?id=2077856
Bug ID: 2077856
Summary: package sssd-idp-2.7.0-1.fc35.x86_64 requires
sssd-common = 2.7.0-1.fc35, but none of the providers
can be installed
Product: Fedora
Version: 36
Status: NEW
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,
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:
When trying to upgrade from F35 to F36:
Error:
Problem: package sssd-idp-2.7.0-1.fc35.x86_64 requires sssd-common =
2.7.0-1.fc35, but none of the providers can be installed
- sssd-common-2.7.0-1.fc35.x86_64 does not belong to a distupgrade repository
- problem with installed package sssd-idp-2.7.0-1.fc35.x86_64
I believe that is resolved by pushing this update stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-cdc3365ffc
Requesting for a Freeze Exception.
--
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=2077856
https://bugzilla.redhat.com/show_bug.cgi?id=2078243
Bug ID: 2078243
Summary: sssd.conf files not came with sssd-common package
anymore and service fails.
Product: Fedora
Version: 36
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: thunderbirdtr(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,
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
I freshly installed Fedora KDE 36 on VM and "sssd" service gives "condition
failed" error. I have some problem on my current F36 machine as well.
Package versions:
sssd-common-2.6.3-1.fc36.x86_64
sssd-2.6.3-1.fc36.x86_64
Service Result
systemctl status sssd
○ sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor
preset: enabled)
Active: inactive (dead)
Condition: start condition failed at
├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
└─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met
I removed directory and re-installed and none of them worked.
rpm -ql sssd-common | grep etc
/etc/logrotate.d
/etc/logrotate.d/sssd
/etc/pam.d/sssd-shadowutils
/etc/rwtab.d
/etc/rwtab.d/sssd
/etc/sssd
/etc/sssd/conf.d
/etc/sssd/pki
/etc/sssd/sssd.conf
Normally, I expect it should be up and running.
--
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=2078243
https://bugzilla.redhat.com/show_bug.cgi?id=2066688
Bug ID: 2066688
Summary: rawhide ships older sssd version than fc36
Product: Fedora
Version: rawhide
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: frenaud(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:
Fedora rawhide is shipping sssd version 2.6.2-3.fc36 while fedora 36 already
has sssd-2.6.3-1.fc36.
This old version is missing some fixes related to IPA-AD trust and our freeipa
rawhide tests are failing because of it
(https://github.com/SSSD/sssd/issues/5947 fixed in 2.6.3).
Version-Release number of selected component (if applicable):
sssd-client-2.6.2-3.fc36.x86_64
How reproducible:
Steps to Reproduce:
1. install sssd on rawhide
2. # rpm -qa sssd-client
sssd-client-2.6.2-3.fc36.x86_64
This issue was already discussed internally with SSSD developers, and is
related to a build issue (make check failure).
--
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=2066688