On Mon, Oct 21, 2019 at 4:25 PM James Cassell fedoraproject@cyberpear.com wrote:
On Mon, Oct 21, 2019, at 1:16 PM, James Ralston wrote:
When you say "SSH authentication using the Smart Card", what exactly do you mean?
I mean using the private key on the Smart Card as the SSH private key. SSSD will convert the userCertificate into SSH public keys for consumption by openssh.
Ah; ok.
We don't care about this, because with PKINIT login, the user obtains a Kerberos TGT, and that TGT permits gssapi-with-mic authentication.
PuTTY can do this ticket forwarding. The limiting factor is convincing the Active Directory team (or the security team) to enable the checkbox "Trust this computer for delegation to any service (Kerberos only)" -- there is also an adcli command line arg to set this option on Computer Account creation, but I've not tried setting it with adcli. I've gotten this working for the subset of machines for which InfoSec approved using the "Trust this computer for delegation to any service (Kerberos only)" checkbox.
Interesting. Is this a setting on the computer object of the target host, or on the (Windows) client where PuTTY is being executed?
(Side note: is there a good guide to setting up NFSv4 w/ auth=krb5p? I've been wanting to do this instead of forcing cifs/samba into its place... virtually every NFS guide I've found left things cleartext.)
I wasn't able to find a good guide; we had to puzzle out the configuration ourselves.
I can try to write up a guide for that (in my copious free time, ha), but in the meantime, shoot me off-list mail if you have specific questions.
Yes, I'm using opensc [in nssdb]. I only referenced coolkey since you said your cards were coolkey-based.
Understood.
I was also able to get this [smartcard login] working at the console. I didn't do anything special for the console; it just worked once the GUI was working.
I've been able to get /usr/bin/login to prompt for the username/PIN, but it still fails, even after I enter the correct PIN (that works in gdm).
This might be a PAM stack configuration issue, though. I'll have to dig into it further.
I'm in a similar situation... hoping to not write my own nssdb ansible role, but I'll probably need to write one since I didn't see a good existing one.
I figured out a way to avoid needing to maintain certificates in /etc/pki/nssdb. You only need to do these two things:
$ pkcs11-switch opensc $ ln -s /usr/lib64/libnssckbi.so /etc/pki/nssdb/
As long as alternatives is using p11-kit-trust.so:
$ alternatives --display libnssckbi.so.x86_64 libnssckbi.so.x86_64 - status is auto. link currently points to /usr/lib64/pkcs11/p11-kit-trust.so /usr/lib64/pkcs11/p11-kit-trust.so - priority 30 /usr/lib64/nss/libnssckbi.so - priority 10 Current `best' version is /usr/lib64/pkcs11/p11-kit-trust.so.
…then p11-kit-trust.so will automatically shim the certificate trust database maintained by update-ca-trust(8) into NSSDB.
It's [smartcard logins] certainly not going away anytime soon for companies who have government, and especially DoD, contracts.
Alas, yes.
I did finally get full sssd PKINIT logins working with gdm, BTW.
Thanks to you (and you, Sumit) for your assistance; it was invaluable.
Next step: to write a guide for this and throw it up somewhere (GitHub or Pagure) so that others can contribute and expand it…