We have an air-gapped network of RHEL7 hosts that use sssd to perform
PKINIT (smartcard + Kerberos) authentication against Windows Server
2016 domain controllers.
Setting this up properly entailed setting pkinit_anchors, pkinit_pool,
pkinit_cert_match, et. al. in the krb5.conf file, and enabling
smartcard authentication in gdm. It also entailed adding individual
certificates to each user object’s userCertificate property, which our
Windows guys grumbled about.
(The way Windows performs PKINIT is to find the certificate on the
card that has a Microsoft User Principal Name X509v3 Subject
Alternative Name, extract that value, and then look for the AD user
object that has the same userPrincipalName. But the version of sssd
that shipped with RHEL7 can’t do that SAN/userPrincipalName matching.)
For the most part, this has worked, and worked well. Once again, sssd
has been an invaluable tool.
But.
For some accounts, smartcard authentication does not work, *even
though* you can use kinit to perform PKINIT against the card (e.g., if
you login via password authentication, then insert the smartcard once
you have a shell window to play with).
For the accounts where smartcard authentication works, after you enter
your username in gdm, the card blinks for a few seconds, and then you
are prompted to enter the PIN as follows:
<CN> PIN:
…where <CN> is the value of the CN= field of the certificate Subject
of the certificate on the smartcard that contains the Microsoft UPN
SAN. E.g.:
LASTNAME.FIRSTNAME.123456789 PIN:
For the accounts where smartcard authentication fails, after you enter
your username in gdm, the card blinks for a few seconds, and then you
are prompted to enter the PIN as follows:
PIN for Smartcard:
That PIN prompt is the kiss of death: even if you enter the correct
PIN, authentication will always fail.
We know that our Kerberos configuration (e.g., pkinit_cert_match)
correctly yields one (and only one candidate certificate) from the
smartcard, which is the correct certificate:
pkinit_cert_match = &&<SAN>.*@.*
And running kinit (with PKINIT) against the smartcard works just fine.
But logins fail for some users and not others. Which almost certainly
means that something is derailing sssd. But it’s not obvious what it
is. We’ve double-checked that the userCertificate objects are correct
in AD (that is, they match the smartcard).
Even more confusingly, the accounts for which smartcard authentication
works versus doesn’t work can change over time. For example, a few
weeks ago, my own account worked for smartcard login; now it doesn’t.
But we know we made no configuration changes and applied no package
updates to the host.
I have also had the situation where I got the “PIN for Smartcard” gdm
prompt, rebooted the host, and then got the “<CN> PIN” gdm prompt.
That almost implies an sssd caching issue, or inconsistent
data/behavior between our (two) domain controllers.
Again, these are air-gapped systems, so I can provide no logs; we are
going to have to slog through the sssd logs and figure it out on our
own.
Questions for the list:
* Does this sound familiar to anyone? Have you already been down this
path? If so, what did you discover?
* sssd logging can be quite voluminous (particularly at higher
debugging levels), to the point where I fear I might miss the needle
in the haystack that is indicating the problem. Can anyone provide
some tips on specific areas where I should focus?
Thanks in advance for any tips/advice.
_______________________________________________
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
