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. > > > > 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 > > > * 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 > 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... > 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. 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
