9:38 a.m.
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.
6:42 p.m.
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(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...
3:05 p.m.
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
2:07 a.m.
New subject: smartcard authentication directly against AD (no IPA)?
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...
2091
days inactive
2095
days old
sssd-users@lists.fedorahosted.org
3 comments
3 participants
participants (3)
-
James Cassell -
James Ralston -
Sumit Bose