On Mon, Aug 13, 2018 at 04:05:55PM -0400, James Ralston wrote:
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.
Yes, unfortunately rule based mapping is currently only available for the
IPA provider. I'm working on making it available for the other providers
as well (
https://pagure.io/fork/sbose/SSSD/sssd/commits/certmap_config)
but it is not complete yet.
For the time being the certificate has to be added to the AD entry of
the user so that SSSD can relate the user and the certificate.
As an alternative it would be possible to add the certificate to a local
override with the sss_override tool. But this has to be done on every
client, so it might be even more cumbersome than adding it to AD if
there are more than a few users involved.
> 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?
First pkinit_anchors which should point to a file or directory where the
CA certificates to validate the certificate on the Smartcard and the
certificate which signed the KDC certificate can be found. In AD
environments the KDC (AD DC) certificate is typically signed by the AD
CS.
Besides that I would recommend pkinit_eku_checking=none and there should
be pkinit_kdc_hostname lines for each AD DC in your environment (at
least for each the client expects replies from).
If the AD DC certificate is created with the 'Kerberos authentication'
certificate templated of the AD CS you do not have to set
pkinit_eku_checking and you can set pkinit_kdc_hostname to the AD domain
name. You have to check with the AD administrators how the DC
certificates were created, see e.g.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows...
for details. Btw, this not only makes the Linux side Kerberos
configuration more easy but makes the AD side more secure as well
because the can enable 'strong KDC validation' on the Windows clients.
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.
Feel free to send me your case number by private mail.
bye,
Sumit
>
> (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
> _______________________________________________
> 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://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...