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
On Wed, Apr 26, 2017 at 03:46:07PM -0000, tallinn1960@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.
On Thu, Apr 27, 2017 at 03:27:47PM -0000, tallinn1960@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.
On Tue, Jun 06, 2017 at 03:22:28PM -0000, tallinn1960@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
On (07/06/17 10:42), tallinn1960@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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org