On Fri, Aug 10, 2018 at 8:31 PM James Cassell
<fedoraproject(a)cyberpear.com> wrote:
We had to add each user's Smart Card certificate to the
"User
Certificate" attribute in Active Directory. We were not able to
make the association only based on trusting the X.509 certificate
like Windows does.
Bah. I'll get no end of grief from our Windows guys about that,
because Windows doesn't need the userCertificate attribute to be set
in AD.
Our Smart Cards had a userPrincipalName attribute that matched the
identically-named attribute in Active Directory.
Where was the userPrincipalName attribute recorded on the smart card?
Was it in one of the X509v3 extensions?
I checked, and for us, the userPrincipalName attribute in AD is set to
match the CN of the Subject of the user's smart card. Which makes
sense: because we don't set the userCertificate attribute, the only
way to map a smart card to a user is by matching the CN of the Subject
of the card's certificate to the account in AD with the corresponding
userPrincipalName attribute.
SSSD will use pkinit if krb5-pkinit is installed, or just verify the
card locally otherwise.
Did you have to set and pkinit-specific krb5.conf options?
One of the sssd design documents suggests that this is necessary:
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_p...
…but I'm not sure if the implementation exactly matches the design
document.
We had to get a hotfix of krb5-pkinit from Red Hat to get a TGT from
the card.
Thanks for that; I opened a support case with Red Hat to request the
same thing.
(We use NFSv4 sec=krb5p home directories, so it is absolutely critical
that we perform PKINIT authentication (not local authentication) and
obtain a TGT from the PKINIT phase. Otherwise, the user may be logged
in, but won't be able to access his home directory.)
Thanks,
James