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=2299733
Bug ID: 2299733
Summary: logrotate service will fail to start due to improper
permissions on /var/log/sssd directory
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: sssd
Keywords: Regression
Severity: high
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: sponix2ipfw(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
I see that the logrotate service has failed to start from within cockpit. In
there it explains that this is due to improper permissions on /var/log/sssd
directory. After a sudo chmod 755 /var/log/sssd I can start the logrotate
service without issues. Pretty sure what I've done to resolve this is take the
permissions from drwxrwxr-x to drwxr-xr-x on this directory.
Reproducible: Always
Steps to Reproduce:
1.Apply system updates that include sssd, have a look at services in cockpit
2.after seeing the logrotate service failed to start using sudo chmod 755
/var/log/sssd
3.clear the error, and start logrotate and it works as it should
Actual Results:
Well, the steps above get logrotate running again. I am not sure how this may
effect the sssd system itself though
Expected Results:
it is expected to see logrotate service running without the need to use sudo
chmod 755 /var/log/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=2299733
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2291235
Bug ID: 2291235
Summary: FreeIPA upgrade test from Fedora 39 fails since
Rawhide 20240608.n.1
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: sssd
Severity: medium
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: awilliam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
lslebodn(a)redhat.com, mzidek(a)redhat.com,
pbrezina(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
I noticed the openQA FreeIPA server upgrade2 test is failing since
sssd-2.10.0~beta1-1.fc41 landed in 20240608.n.1 . The one-release upgrade test
(F40 to Rawhide) is fine, but F39 to Rawhide fails.
After the upgrade process is complete, on the upgraded server, ipa.service
doesn't start. ipaupgrade.log shows the sssd service failing. sssd journal
messages just say:
Jun 10 11:31:15 ipa001.test.openqa.fedoraproject.org systemd[1]: Starting
sssd.service - System Security Services Daemon...
Jun 10 11:31:15 ipa001.test.openqa.fedoraproject.org sssd[24779]: Starting up
Jun 10 11:31:15 ipa001.test.openqa.fedoraproject.org sssd_be[24781]: Starting
up
Jun 10 11:31:15 ipa001.test.openqa.fedoraproject.org sssd_be[24783]: Starting
up
Jun 10 11:31:17 ipa001.test.openqa.fedoraproject.org sssd_be[24785]: Starting
up
Jun 10 11:31:22 ipa001.test.openqa.fedoraproject.org sssd_be[24787]: Starting
up
Jun 10 11:31:22 ipa001.test.openqa.fedoraproject.org sssd[24779]: Exiting the
SSSD. Could not restart critical service [test.openqa.fedoraproject.org]
Jun 10 11:31:22 ipa001.test.openqa.fedoraproject.org systemd[1]: sssd.service:
Main process exited, code=exited, status=1/FAILURE
Jun 10 11:31:22 ipa001.test.openqa.fedoraproject.org systemd[1]: sssd.service:
Failed with result 'exit-code'.
Jun 10 11:31:22 ipa001.test.openqa.fedoraproject.org systemd[1]: Failed to
start sssd.service - System Security Services Daemon.
but the sssd log files themselves are very verbose, so much so that I can't see
exactly what the problem is. Will attach a tarball of the var/log/sssd
directory.
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2291235
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…