Smart Card (CAC) logon

English Install/Boot/Login
#1

Situation Brief.
My work computer is running Leap 42.1 with KDE.
It is joined to the domain via the YaST module and any domain user can login, as it should be.
I have been able to set up a CAC reader, thanks to https://en.opensuse.org/DoD_Common_Access_Card_(CAC)_Reader, and both Firefox and Chrome were working.
I tried to get the login to prompt for a card/PIN by doing the following. Most of this came from http://blog.fkraiem.org/2013/03/13/linux-smart-card-authentication-pam/.

Verified that all modules within /etc/pam.d/common-auth-smartcard were installed.
Added the following to /etc/pam_pkcs11/pam_pkcs11.conf

use_pkcs11_module = cackey;

pksc11_module cackey {
    module = /usr/lib64/libcackey.so;
    description = "Cackey";
    slot_num = 0;
    support_threads = false;
    ca_dir = /etc/pam_pkcs11/cacerts;
    crl_dir = /etc/pam_pkcs11/crls;
    cert_policy = signature;
}

Added the CA certs, in pem format, to /etc/pam_pkcs11/cacerts. Ran sudo pkcs11_make_hash_link.
Added

auth    sufficient    common-auth-smartcard

to /etc/pam.d/sddm and sddm-greeter.
Rebooted.

After the reboot the smart card readers, I have two plugged in, an SCR3310 and an OMNIKEY 3121, both work in Firefox, did not seem to be turned on. When a card is inserted the smart card reader light is supposed to come on and, depending on the model, blink. Neither show that behavior.
So I looked up the pcscd information and found that it is an on-demand service, only turned on when needed. Possibly this is the problem? I don’t know exactly how to change this behavior though.

Any ideas?

#2

Although I have no experience setting up a card reader,

My initial thought is whether the daemon is running when your system first boots…

Assuming the following should reveal the current status and likely is saying “disabled”

systemctl status pkscd.service

If so, then to make the daemon available on boot,

systemctl enable pkscd.service

TSU

#3

So I got the pcscd service to finally start at boot.
I had to change the pcscd.service file from this:

[Unit]
Description=PC/SC Smart Card Daemon
Requires=pcscd.socket

[Service]
Environment="PCSCD_OPTIONS="
EnvironmentFile=-/etc/sysconfig/pcscd
ExecStart=/usr/sbin/pcscd --foreground --auto-exit $PCSCD_OPTIONS
ExecReload=/usr/sbin/pcscd --hotplug

[Install]
Also=pcscd.socket

to this:

[Unit]
Description=PC/SC Smart Card Daemon

[Service]
Environment="PCSCD_OPTIONS="
EnvironmentFile=-/etc/sysconfig/pcscd
ExecStart=/usr/sbin/pcscd --foreground --auto-exit $PCSCD_OPTIONS
ExecReload=/usr/sbin/pcscd --hotplug

[Install]
WantedBy=graphical.target

Still SDDM does not prompt for a card login or give me the option to enter a PIN.

#4

You’re describing a systemd Unit file.

Be sure you are following Best Practices by not editing the original file, make a copy in /etc/systemd/user/ or /etc/systemd/system/ and <then> modify your copy however you wish. Any Unit files in these locations will over-ride the original files when they exist. You can always return to the default Unit files by just deleting the copies you created.

I don’t know if making the pcsd service a dependency for graphical-target is better than the more usual method I suggested (enable the service), both should make your service available before the User login. At worse, your method might decrease the automatic parallelism during boot and could cause some delay… Or, it might not make a diff.

If you believe that sddm is your current problem, then just try a different display manager. You can choose from many using YAST
YAST > System > /etc/sysconfig editor > Desktop > Display manager > DISPLAYMANAGER

TSU

#5

The problem with the pcscd service is two fold. It is one of only a few middleware drivers for smart card readers, and the only one that is available for OpenSuSE.
The way it is installed, with systemd, is that it requires the pcscd.socket to listen for an application asking to use a smart card. Once that request comes in the service is started.
This works fine for Firefox and Chrome but seemed to be failing for login. So either the login manager had no idea to request a smart card or the socket wasn’t listening, I’m leaning more towards the first one.
By modifying the pcscd.service file to no longer require pcscd.socket and to be wanted by the graphical.target, the service automatically starts and stays running whenever X is started.
And yes I did keep a copy of the original pcscd.service file.

Now it’s up to the login manager and SDDM seems to be ignoring the available smart card. I have also tried changing

auth    sufficient    common-auth-smartcard

to

auth    sufficient    pam_pkcs11.so

to no effect.
I did try using KDM instead of SDDM but received the same results.

Something is missing or wrong in my config files or system but none of the how-tos that I have seen include something that I haven’t already tried.
I’m still hoping someone else using OpenSuSE, or SLE, has gotten this to work and can help me out.

#6

I haven’t tried using a cac reader in OpenSuSE KDE but in the RedHat Rhel world it only works with GDM. If working correctly
there will be a process called gdm-smartcard running along with gdm-password.

#7

This idea that “socket” isn’t sufficient and replacing with “wanted by graphical.target” didn’t sound right to me, a socket not available by the time multi-user.target was reached? – That doesn’t sound right at all.

So, did a little Googling,
It seems that the basic/original description to setting up pcsd in a systemd is this article which describes leaving the original pcsd.service Unit file as is, but also creating a new Unit file that explicitly starts up the socket. The “why” is in the article, that ordinary behavior is that pcsd.service does not typically always run, but is invoked only on demand.
http://ludovicrousseau.blogspot.com/2011/11/pcscd-auto-start-using-systemd.html

A year or so later there is this bug discussion I don’t think applies to your situation immediately(system login) but may be important to know because it may affect other apps (like FF)… that apps may have their own way of invoking pcsd (which is the normal behavior) but if pcsd is already running(the unexpected behavior) may not connect to the same process… I wonder if pcsd.service should be stopped immediately after successful login.
https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/975482

TSU