p11_child fails to obtain certificate from yubikey

I am trying to setup a PKINIT/smartcard-based logon scheme using sssd 1.15.1 on Ubuntu
16.04. I am using the opensc-pkcs11 lib to access the smartcard. I have a working pam_krb5
based PKINIT smartcard logon to the KDC. The opensc pkcs11 lib and all relevant ca
certificates are installed in the nss database.

However, p11_child is not happy about the yubikey:

➜  ~ sudo /usr/local/libexec/sssd/p11_child -d 9 --nssdb=/etc/pki/nssdb --pre
(Wed Apr 26 17:40:56:522588 2017) [[sssd[p11_child[2677]]]] [main] (0x0400): p11_child
started.
(Wed Apr 26 17:40:56:522763 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running in
[pre-auth] mode.
(Wed Apr 26 17:40:56:522849 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with
effective IDs: [0][0].
(Wed Apr 26 17:40:56:522931 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with
real IDs [0][0].
(Wed Apr 26 17:40:56:655832 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Default
Module List:
(Wed Apr 26 17:40:56:655859 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
name: [NSS Internal PKCS #11 Module].
(Wed Apr 26 17:40:56:655864 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
[(null)].
(Wed Apr 26 17:40:56:655869 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
name: [yubikey].
(Wed Apr 26 17:40:56:655873 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
[/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so].
(Wed Apr 26 17:40:56:655877 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Dead
Module List:
(Wed Apr 26 17:40:56:655883 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): DB Module
List:
(Wed Apr 26 17:40:56:655888 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
name: [NSS Internal Module].
(Wed Apr 26 17:40:56:655892 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
[(null)].
(Wed Apr 26 17:40:56:655917 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
Description [NSS Internal Cryptographic Services                             Mozilla
Foundation              
] Manufacturer [Mozilla Foundation              
] flags [1].
(Wed Apr 26 17:40:56:655924 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
Description [NSS User Private Key and Certificate Services                   Mozilla
Foundation              
] Manufacturer [Mozilla Foundation              
] flags [1].
(Wed Apr 26 17:40:56:655929 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
Description [Yubico Yubikey 4 OTP+CCID 00 00                                 OpenSC
(www.opensc-project.org) ] Manufacturer [OpenSC (www.opensc-project.org) ] flags [7].
(Wed Apr 26 17:40:56:655940 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Found
[PIV_II (PIV Card Holder pin)] in slot [Yubico Yubikey 4 OTP+CCID 00 00][1] of module
[2][/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so].
(Wed Apr 26 17:40:56:655946 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Token is
NOT friendly.
(Wed Apr 26 17:40:56:655951 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Trying to
switch to friendly to read certificate.
(Wed Apr 26 17:40:56:655957 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Login
required.
(Wed Apr 26 17:40:56:655961 2017) [[sssd[p11_child[2677]]]] [do_work] (0x0020): Login
required but no pin available, continue.
(Wed Apr 26 17:40:56:656102 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): found
cert[PIV_II (PIV Card Holder pin):Certificate for PIV
Authentication][CN=secadm,UID=4915377]
(Wed Apr 26 17:40:56:656127 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Filtered
certificates:
(Wed Apr 26 17:40:56:656132 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): No
certificate found.

It looks like the certificate on the key is PIN-protected. Shouldn't p11_child ask for
a PIN? Giving p11_child the --pin flag has absolutely no effect.

Any help is welcome.

Thx

[Sumit Bose]

On Wed, Apr 26, 2017 at 03:46:07PM -0000, tallinn1960(a)yahoo.de wrote:
>  I am trying to setup a PKINIT/smartcard-based logon scheme using sssd
> 1.15.1 on Ubuntu 16.04. I am using the opensc-pkcs11 lib to access the smartcard. I have a
> working pam_krb5 based PKINIT smartcard logon to the KDC. The opensc pkcs11 lib and all
> relevant ca certificates are installed in the nss database.
>  
>  However, p11_child is not happy about the yubikey:
>  
>  ➜  ~ sudo /usr/local/libexec/sssd/p11_child -d 9 --nssdb=/etc/pki/nssdb --pre
>  (Wed Apr 26 17:40:56:522588 2017) [[sssd[p11_child[2677]]]] [main] (0x0400): p11_child
> started.
>  (Wed Apr 26 17:40:56:522763 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running in
> [pre-auth] mode.
>  (Wed Apr 26 17:40:56:522849 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with
> effective IDs: [0][0].
>  (Wed Apr 26 17:40:56:522931 2017) [[sssd[p11_child[2677]]]] [main] (0x2000): Running with
> real IDs [0][0].
>  (Wed Apr 26 17:40:56:655832 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Default
> Module List:
>  (Wed Apr 26 17:40:56:655859 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
> name: [NSS Internal PKCS #11 Module].
>  (Wed Apr 26 17:40:56:655864 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
> [(null)].
>  (Wed Apr 26 17:40:56:655869 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
> name: [yubikey].
>  (Wed Apr 26 17:40:56:655873 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
> [/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so].
>  (Wed Apr 26 17:40:56:655877 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Dead
> Module List:
>  (Wed Apr 26 17:40:56:655883 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): DB Module
> List:
>  (Wed Apr 26 17:40:56:655888 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): common
> name: [NSS Internal Module].
>  (Wed Apr 26 17:40:56:655892 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): dll name:
> [(null)].
>  (Wed Apr 26 17:40:56:655917 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
> Description [NSS Internal Cryptographic Services                             Mozilla
> Foundation              
] Manufacturer [Mozilla Foundation              
] flags [1].
>  (Wed Apr 26 17:40:56:655924 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
> Description [NSS User Private Key and Certificate Services                   Mozilla
> Foundation              
] Manufacturer [Mozilla Foundation              
] flags [1].
>  (Wed Apr 26 17:40:56:655929 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000):
> Description [Yubico Yubikey 4 OTP+CCID 00 00                                 OpenSC
> (www.opensc-project.org) ] Manufacturer [OpenSC (www.opensc-project.org) ] flags [7].
>  (Wed Apr 26 17:40:56:655940 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Found
> [PIV_II (PIV Card Holder pin)] in slot [Yubico Yubikey 4 OTP+CCID 00 00][1] of module
> [2][/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so].
>  (Wed Apr 26 17:40:56:655946 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Token is
> NOT friendly.
>  (Wed Apr 26 17:40:56:655951 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Trying to
> switch to friendly to read certificate.
>  (Wed Apr 26 17:40:56:655957 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Login
> required.
>  (Wed Apr 26 17:40:56:655961 2017) [[sssd[p11_child[2677]]]] [do_work] (0x0020): Login
> required but no pin available, continue.
>  (Wed Apr 26 17:40:56:656102 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): found
> cert[PIV_II (PIV Card Holder pin):Certificate for PIV
> Authentication][CN=secadm,UID=4915377]
>  (Wed Apr 26 17:40:56:656127 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): Filtered
> certificates:
>  (Wed Apr 26 17:40:56:656132 2017) [[sssd[p11_child[2677]]]] [do_work] (0x4000): No
> certificate found.
>  
>  It looks like the certificate on the key is PIN-protected. Shouldn't p11_child ask
> for a PIN? Giving p11_child the --pin flag has absolutely no effect. 
Typically the private key is pin protect, since there is nothing secret
in the certificate I can be read without a pin.

SSSD expects that certificates used for authentication have at least the
key usage digitalSignature and the extended key usage clientAuth. Please
check if your certificate meet this criteria.

HTH

bye,
Sumit

> 
> Any help is welcome.
> 
> Thx
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

Thank you, EKU clientAuth was missing, including it got p11_child  working.

However still no luck with using the key with sssd and pkinit. kinit works fine with the
key, but login (tty and lightdm) never asks for the pin. Instead it ask for a password two
times and accepts the second as a local user-no-kerberos-login, when the key is plugged
in, and only one time when the key is not plugged in, giving me a kerberos login with
ticket.

I looked into the code and did some debugging and found that krb5_child signals
SSS_CERT_AUTH_PROMPTING (code 12) to pam_sss, which it does not know how to handle. But I
may be totally mistaken here. And anyway without clue.

[Sumit Bose]

On Thu, Apr 27, 2017 at 03:27:47PM -0000, tallinn1960(a)yahoo.de wrote:
>  Thank you, EKU clientAuth was missing, including it got p11_child 
> working.
>  
>  However still no luck with using the key with sssd and pkinit. kinit works fine with the
> key, but login (tty and lightdm) never asks for the pin. Instead it ask for a password two
> times and accepts the second as a local user-no-kerberos-login, when the key is plugged
> in, and only one time when the key is not plugged in, giving me a kerberos login with
> ticket. 
You most probably have to tweak your PAM configuration. In Fedora some
thing like

auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok
try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

is used. The pam_localuser line makes sure pam_unix (which can only ask
for a password) is only used for local user and pam_sss can prompt for
SSSD users.

Additionally you might need to call

    touch /var/lib/sss/pubconf/pam_preauth_available

to enable an additional round-trip between pam_sss and SSSD to check
which authentication methods are available for the user so that pam_sss
can prompt accordingly. Since this round-trip adds some time to the
login process it is not activated by default.

HTH

bye,
Sumit

> 
> I looked into the code and did some debugging and found that krb5_child signals
SSS_CERT_AUTH_PROMPTING (code 12) to pam_sss, which it does not know how to handle. But I
may be totally mistaken here. And anyway without clue.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

Eventually I've got a working setup with PKINIT, Smartcard and sssd 1.15.2 in a
Ubuntu/Unity-Environment. However, login fails, if both krb5 kdc and ldap id provider are
offline. Is offline mode for smartcard authentication vs kerberos supposed to work at all
in sssd or are there more requirements to be met than those already mentioned here?

Especially, are there any requirements on the subject dn in the certificate? I am looking
at an error message in the logs that is only there in offline mode:

sssd_pam.log:(Tue Jun  6 15:52:57 2017) [sssd[pam]] [pam_dom_forwarder] (0x0400): User and
certificate user do not match, continue with other authentication methods.

As for Kerberos the subject of the certificate has no meaning, the kerberos principal name
is encoded as an subject alternative name id-pki-san extension. So we did not choose
anything special for the subject name of the certificates.

[Sumit Bose]

On Tue, Jun 06, 2017 at 03:22:28PM -0000, tallinn1960(a)yahoo.de wrote:
>  Eventually I've got a working setup with PKINIT, Smartcard and
> sssd 1.15.2 in a Ubuntu/Unity-Environment. However, login fails, if both krb5 kdc and ldap
> id provider are offline. Is offline mode for smartcard authentication vs kerberos supposed
> to work at all in sssd or are there more requirements to be met than those already
> mentioned here?
>  
>  Especially, are there any requirements on the subject dn in the certificate? I am looking
> at an error message in the logs that is only there in offline mode:
>  
>  sssd_pam.log:(Tue Jun  6 15:52:57 2017) [sssd[pam]] [pam_dom_forwarder] (0x0400): User
> and certificate user do not match, continue with other authentication methods.
>  
>  As for Kerberos the subject of the certificate has no meaning, the kerberos principal
> name is encoded as an subject alternative name id-pki-san extension. So we did not choose
> anything special for the subject name of the certificates.  
If offline SSSD would just check the certificate and the PIN on its own.
To map the certificate to the user the full certificate is used because
it should have been saved to the cache by a previous online
authentication.

The log message indicates that the certificate is not properly stored in
the cache, at least searching the cache for the user and the certificate
return different objects.

Can you send the full sssd_pam.log file to see if there are more hints
why one of the searches in the offline case does not find the right
object?

bye,
Sumit

> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

I did the following tests this morning:

First login with freshly started sssd online, works fine
Repeat login still online, works fine, however, the suspicious logfile-entry cited above
appears!
Go offline, repeat login, fail, again sssd fails to match user and certificate user

Now it looks like sssd has a problem obtaining necessary information from the cache

I've prepared three logfiles for the three login attempts listed above, but they are
huge. Is there a way to upload them as attachments?

[Lukas Slebodnik]

On (07/06/17 10:42), tallinn1960(a)yahoo.de wrote:
> I did the following tests this morning:
>
> First login with freshly started sssd online, works fine
> Repeat login still online, works fine, however, the suspicious logfile-entry cited above
> appears!
> Go offline, repeat login, fail, again sssd fails to match user and certificate user
>
> Now it looks like sssd has a problem obtaining necessary information from the cache
>
> I've prepared three logfiles for the three login attempts listed above, but they are
> huge. Is there a way to upload them as attachments? 
There is configured limit for
attachments. IIRC 1 MiB.

But you can attach gzipped version (or any other compression format which
you prefer). Another option is use pastebin or upload files somewhere else
with reasonable file limit :-)

LS

Using my e-mail client to upload the logfiles has created a new thread unfortunately. Here
is the link to the message:

https://lists.fedorahosted.org/archives/list/[e-mail]...