On Sat, Oct 19, 2019 at 3:26 AM James Cassell fedoraproject@cyberpear.com wrote:
On Fri, Oct 18, 2019, at 9:58 PM, James Ralston wrote:
I am struggling to get smartcard authentication working on RHEL7, using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active Directory KDCs.
Has anyone actually gotten this working? If so, what behavior differences do you see from various login mechanisms (gdm, login, et. al.)?
I've gotten it working.
Because I see *no* visual differences in any login mechanism. gdm, login, et. al. prompt for a username/password, exactly as before. Both after I enter the username, and after I enter the PIN (at the "password" prompt), there is a delay while sssd pokes at the card. I can also tell this from watching the light on the card reader blink.
I've seen it behave both ways, and I'm not sure what the difference was. Sometimes, the GDM login screen automatically shows the correct user when the Smart Card is inserted; other times, I must first enter the user name before being prompted for the PIN.
I've not seen GDM prompt for a Smart Card, but I'm also not enforcing Smart Card-only login at this time.
I tried disabling password authentication, but the only change I saw in gdm's behavior was that it skipped the "password" prompt.
If it's really the case that we have to train our users to type their username into the "username" prompt and enter their smartcard PIN into the "password" prompt, we can do that, but that doesn't seem to be how it's supposed to work based on the above documents. And that's going to seem completely horrible to users in contrast to how Windows works, where you walk up, insert your smartcard, and the login screen identifies you and then prompts for your PIN.
The PIN should not be entered into the "Password" prompt. Only the prompt that says "PIN"
OK, good to know. I haven't seen any PIN prompts, so that tells me gdm isn't even getting to that point in the process.
- I touched /var/lib/sss/pubconf/pam_preauth_available into existence and restarted sssd.
There is no need to perform this step. This is performed automatically by sssd when configured with `pam_cert_auth = True`
Noted.
- I set "pam_cert_auth = true" in the [domain/example.org] section of /etc/sssd/sssd.conf.
This should be in the [pam] section of the sssd.conf
Hmmm. It seemed to work for me in the [domain] section. (Or at least, it changed the login behavior.) But I'll go back and try it in the [pam] section.
- I extracted the correct certificate from my smartcard (the one that krb5.conf is configured to find) and added it to my userCertificate attribute in Active Directory.
This is necessary if you want to use the Smart Card for SSH authentication. I'm unsure if it's necessary for authentication when the card is physically present at the machine. I know it's not necessary with the latest upstream version of SSSD, but not sure if it made it into RHEL.
This feature:
https://docs.pagure.org/SSSD.sssd/design_pages/certmaps_for_LDAP_AD_file.htm...
…didn't make it to RHEL7, no.
We know that in order for gdm to be able to identify the user corresponding to the inserted smartcard, sssd needs to be able to map a smartcard to an AD user. The only way that the RHEL7 version of sssd knows how to do that is by searching for an AD user object that has a userCertificate attribute that matches the one on the smartcard. Thus the requirement to populate userCertificate attributes.
BUT: if the only consequence of not populating the AD user objects with the userCertificate attribute is that the user will need to enter their username before entering their PIN, then we will gleefully avoid populating our AD user objects with the userCertificate attributes:
1. It's another tedious step that has to be performed whenever we [re]issue] a smartcard.
2. Smartcard login on Windows doesn't require the userCertificate attribute in order to map the smartcard to a user. (Instead, Windows extracts the CN of the smartcard certificate and matches it to the AD user(s) who have that CN value as their userPrincipalName attributes.) So I'm taking flak from our AD admins who don't understand why LInux needs this step.
Assuming I can get smartcard logins working, I'll then test to see what happens if I remove the userCertificate attribute from my AD user object. Will doing so break smartcard logins, or will it just mean that gdm prompts me for my username, because sssd can't figure out who I am just from the certificate on the smartcard alone?
- I even populated /etc/pki/nssdb with all of the same certificates that update-ca-trust maintains, even though I'm not sure that's necessary, as I think krb5 pkinit.so should handle that.
This is required for SSSD, but not for plain PKINIT.
Yeah, that's what I thought. But I wasn't completely sure, so I did it anyway.
Once I get it working, I'll reset /etc/pki/nssdb back to its default (no certificates) and test to see whether smartcard login still works.
I increased various sssd timeouts to work around this bug in sssd that was derailing the nss responder:
#4103 slow smartcard interactions break sssd when PKINIT is configured https://pagure.io/SSSD/sssd/issue/4103
I'd been considering opening my own bug against pcscd (pcsc-lite?) because of the long delays caused by accessing the card. (Seems like this could be cached.)
The delays seem specific to certain reader and/or smartcard combinations.
For example, I was testing with a different smartcard, and pcscd could read that smartcard *much* more rapidly.
But, alas, for the specific smartcard implementation we have to use, pcscd is *sloooooooooow*.
Nonetheless, I will poke around in upstream bug reports, and see if this issue has come up before. Perhaps there's some way to increase the speed.
I'm open to suggestions for anything that I missed.
The thing that solved pkinit for me when logging in on RHEL 7 was the p11_child_timeout in sssd.conf:
[pam] p11_child_timeout = 90
Strangely, RHEL 8 did not require that timeout value to be set. The built-in default value is 6 seconds, IIRC.
Sigh… I missed that one. I only have these ones:
krb5_auth_timeout: 60 ldap_network_timeout: 60 ldap_opt_timeout: 60 ldap_search_timeout: 60
I know for our reader/smartcard combination, there's no way the p11 child is going to be able to do *anything* with them in under 6 seconds.
I will add the p11_child_timeout setting an re-test.
Hope that's helpful
Indeed it was; much thanks.
and I'd be interested in hearing about any gotchas you solve along the way.
Red Hat's syntactically incorrect pkinit_anchors setting in /etc/krb5.conf derailed us until I rebuilt pkinit.so with debugging and could see what it was choking on:
syntax error in default /etc/krb5.conf file silently breaks PKINIT https://bugzilla.redhat.com/show_bug.cgi?id=1757506
There's a subtle bug in OpenSC that breaks CoolKey-based cards using 2048-bit RSA certificates (which is what we're using):
"pkcs11-tool --test" fails with a SIPR card #1524 https://github.com/OpenSC/OpenSC/issues/1524
OpenSC 0.20.0 will have the fix, but no released version of OpenSC does, and Red Hat hasn't backported the fix. So I had to backport the fix myself, building local RPM packages (based on the latest RHEL7 source RPMs) that had the fix.
In general, the fact that pkinit.so provides absolutely no diagnostics whatsoever (unless it is re-compiled with debugging flags) was the biggest gotcha. There are multiple options that need to be set correctly in order to get PKINIT working.
When I get this working, I'm going to write a guide for how to do it, and specifically include links for the above gotchas.