On Sun, Oct 20, 2019 at 08:53:48PM -0400, James Cassell wrote: > On Sun, Oct 20, 2019, at 5:38 PM, James Ralston wrote: > > On Sat, Oct 19, 2019 at 3:26 AM James Cassell > > <fedoraproj...@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.
This is a feature of GDM which requires the dconf setting as you mentioned before and that the PKCS#11 module (OpenSC or Coolkey) is added to /etc/pki/nssdb. The latter should be done automatically during the installation of the related package. About dconf, how did you add the Smartcard authentication option? > > > > > > 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.html#certificate-mapping-and-matching-rules-for-all-providers > > > > …didn't make it to RHEL7, no. > > > > /me hopes beyond hope that it gets into 7.8 :P > > > > 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? > > > > Even if local authentication works w/o the userCertificate attribute, SSH > authentication using the Smart Card inherently requires the userCertificate > attribute because the certificate is not sent over the SSH session. > > > > > > * 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. > > > > nssdb is likely to be required for SSH Smart Card authentication /etc/pki/nssdb on RHEL7 (or /etc/sssd/pki/sssd_auth_ca_db.pem on RHEL8) should contain the CA certificates needed to verify the user certificate. > > > > > > * 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.) I commented in the pagure ticket and mentioned a work-around. > > > > 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. The default value is 10. In RHEL8 p11-kit is used by SSSD to access the Smartcard while in RHEL7 NSS is used here as well. This might cause a bit less overhead with your setup and in the result a bit faster operation. > > > > 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 > > > > Awesome, thanks for the reference! I'll ask to attach that to my Support > Case. (I also wasted days on that exact issue.) > > > There's a subtle bug in OpenSC that breaks CoolKey-based cards using > > 2048-bit RSA certificates (which is what we're using): > > > > aha! Did you add the coolkey driver to the nssdb? That could be your issue. > > The easiest way I know to do that is to install the `opensc` package then: > > # pkcs11-switch coolkey > > > > "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. > > > > Was it trivial to recompile w/ debug flags? I'm familiar w/ the likes of > `fedpkg mockbuild` for tweaking packages, but haven't looked at the source > for pkinit... > Please find attached a patch for this. > > 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. > > That would be great! Once I have this fully deployed, I plan to push > management to release our related ansible roles as Open Source. Thank you both for helping to improve the documentation about Smartcard authentication with real-world examples. bye, Sumit > > Thanks for sharing your gotchas. > > > V/r, > James Cassell > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
