Is anyone using sssd to perform smartcard authentication directly against Microsoft Active Directory, without using IPA? If so, what did you have to do in order to get it working?
In our AD domain, the userPrincipalName attribute contains the address of what I assume is the CN of the smartcard that corresponds to that user. I don't see any other attributes set in AD that look like they're related to smartcard authentication (i.e., no certificates), so everything must drive from the userPrincipalName attribute. (We use a one-smartcard-per-account model, so we have no altSecurityIdentities attributes.)
Our Windows guys don't know for certain, but I believe that the smartcard authentication employs PKINIT. (I don't see how else it would work, honestly.)
Pretty much the only sssd configuration options I see related to smartcard authentication are pam_cert_auth and pam_cert_db_path.
Is it really the case that all I have to do is set pam_cert_auth to "true" and smartcard logins will just magically work, because sssd will look at the userPrincipalName attribute in AD and just Do The Right Thing?
I mean, it can't be that easy, can it? :-P
Thanks in advance for any advice or tips.
On Fri, Aug 10, 2018, at 10:38 AM, James Ralston wrote:
Is anyone using sssd to perform smartcard authentication directly against Microsoft Active Directory, without using IPA? If so, what did you have to do in order to get it working?
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.
In our AD domain, the userPrincipalName attribute contains the address of what I assume is the CN of the smartcard that corresponds to that user. I don't see any other attributes set in AD that look like they're related to smartcard authentication (i.e., no certificates), so everything must drive from the userPrincipalName attribute. (We use a one-smartcard-per-account model, so we have no altSecurityIdentities attributes.)
Our Smart Cards had a userPrincipalName attribute that matched the identically-named attribute in Active Directory.
Our Windows guys don't know for certain, but I believe that the smartcard authentication employs PKINIT. (I don't see how else it would work, honestly.)
SSSD will use pkinit if krb5-pkinit is installed, or just verify the card locally otherwise.
Pretty much the only sssd configuration options I see related to smartcard authentication are pam_cert_auth and pam_cert_db_path.
Is it really the case that all I have to do is set pam_cert_auth to "true" and smartcard logins will just magically work, because sssd will look at the userPrincipalName attribute in AD and just Do The Right Thing?
Not quite.
I mean, it can't be that easy, can it? :-P
Thanks in advance for any advice or tips.
We had to get a hotfix of krb5-pkinit from Red Hat to get a TGT from the card.
V/r, James Cassell
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted....
On Fri, Aug 10, 2018 at 8:31 PM James Cassell fedoraproject@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_pkin...
…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
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@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-se... 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_pkin...
…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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted....
sssd-users@lists.fedorahosted.org
-
James Cassell -
James Ralston -
Sumit Bose