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
> <fedoraproject(a)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
> > > 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
> > > 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`
> > > * I set "pam_cert_auth = true" in the [domain/example.org
> > > 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:
> …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
> > > * 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
> 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
> 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
> 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
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
> 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.
Thanks for sharing your gotchas.
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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