On Sat, Oct 19, 2019 at 3:26 AM James Cassell
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
> 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`
> * I set "pam_cert_auth = true" in the
> 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
> 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.
…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
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
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
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
> 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:
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:
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
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
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
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.