HI!
What's the option ldap_user_certificate used for in IPA? Is it used for a separate map? Or is it used e.g. for emulation of signed SSH authorized keys?
Ciao, Michael.
On Mon, Sep 21, 2015 at 07:32:47PM +0200, Michael Ströder wrote:
HI!
What's the option ldap_user_certificate used for in IPA? Is it used for a separate map? Or is it used e.g. for emulation of signed SSH authorized keys?
Ciao, Michael.
(Maybe Sumit or Pavel will correct me later, they implemented most of the code in this area..)
As you noted, the NSS interface doesn't allow the certificate to be matched (there's no getpwcert) or even returned (there's no cert field in struct passwd). But SSSD has also a rich D-Bus interface. In our use-cases it's mostly used to match a user entry based on certificate during a smart-card login.
There are some examples here that maybe illustrate the flow better: http://www.freeipa.org/page/V4/User_Certificates#How_to_Test
What is your use-case?
On Mon, Sep 21, 2015 at 09:39:18PM +0200, Jakub Hrozek wrote:
On Mon, Sep 21, 2015 at 07:32:47PM +0200, Michael Ströder wrote:
HI!
What's the option ldap_user_certificate used for in IPA? Is it used for a separate map? Or is it used e.g. for emulation of signed SSH authorized keys?
Ciao, Michael.
(Maybe Sumit or Pavel will correct me later, they implemented most of the code in this area..)
As you noted, the NSS interface doesn't allow the certificate to be matched (there's no getpwcert) or even returned (there's no cert field in struct passwd). But SSSD has also a rich D-Bus interface. In our use-cases it's mostly used to match a user entry based on certificate during a smart-card login.
There are some examples here that maybe illustrate the flow better: http://www.freeipa.org/page/V4/User_Certificates#How_to_Test
yes, this entry is used to support various certificate based authentications. Currently there is the D-Bus lookup to find a matching user for application which do the certificate based authentication on its own, like e.g. apache. In addition to the page above there is https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate with more D-Bus details.
Recently initial support for native Smartcard authentication was added and a public ssh key can be derived from the certificate as well to support Smartcard authentication via ssh with suitable clients. More details can be found at https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#H...
HTH
bye, Sumit
What is your use-case? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sumit Bose wrote:
In addition to the page above there is https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate with more D-Bus details.
Since this is a design document one important comment: This won't work with OpenLDAP.
In 389-DS 'userCertificate' is declared like this:
( 2.5.4.36 NAME 'userCertificate' DESC 'X.509 user certificate' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'RFC 4523' )
Note that although this references RFC 4523 simply Octet String syntax is used with the accompanying equality matching rule 'octetStringMatch'. That's what's used in your design for generating the LDAP filter strings.
In OpenLDAP 'userCertificate' is declared like defined in RFC 4523:
( 2.5.4.36 NAME 'userCertificate' DESC 'RFC2256: X.509 user certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
Note that 'certificateExactMatch' is used as equality matching rule. Generating simple filters like for 'octetStringMatch' does not work. You would have to construct a issuer-DN+serial assertion value.
Ciao, Michael.
On Tue, Sep 22, 2015 at 04:14:44PM +0200, Michael Ströder wrote:
Sumit Bose wrote:
In addition to the page above there is https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate with more D-Bus details.
Since this is a design document one important comment: This won't work with OpenLDAP.
In 389-DS 'userCertificate' is declared like this:
( 2.5.4.36 NAME 'userCertificate' DESC 'X.509 user certificate' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'RFC 4523' )
Note that although this references RFC 4523 simply Octet String syntax is used with the accompanying equality matching rule 'octetStringMatch'. That's what's used in your design for generating the LDAP filter strings.
In OpenLDAP 'userCertificate' is declared like defined in RFC 4523:
( 2.5.4.36 NAME 'userCertificate' DESC 'RFC2256: X.509 user certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
Note that 'certificateExactMatch' is used as equality matching rule. Generating simple filters like for 'octetStringMatch' does not work. You would have to construct a issuer-DN+serial assertion value.
Thank you for the comment. Out plan is to add more flexible mappings in one of the next releases. Besides matching the certificate as a whole we also plan to drop the requirement to have the full certificate stored in LDAP but find the matching user with some data from the certificate, like e.g. the CN or some values form the Subject Alternative Names.
bye, Sumit
Ciao, Michael.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Michael Ströder -
Sumit Bose