Learn more about these different git repos.
Other Git URLs
I have set up authentication using smart card certificate stored on yubikey. I have also external card reader connected through USB and there are several issues I noticed during last weeks:
with-smartcard-lock-on-removal
I can provide whatever logs (if you will point out what might be important) you ask for since I can reproduce this reliably, even submit patches, if I will figure out where is the actual issue.
So far, I collected the logs from p11_child, which seems to be relevant:
p11_child
(Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x0400): p11_child started. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x2000): Running in [pre-auth] mode. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x2000): Running with real IDs [0][0]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): Module List: (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): common name: [p11-kit-trust]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): dll name: [/usr/lib64/pkcs11/p11-kit-trust.so]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): Description [/etc/pki/ca-trust/source PKCS#11 Kit ^A] Manufacturer [PKCS#11 Kit ^A] flags [1] removable [false] token present [true]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): Description [/usr/share/pki/ca-trust-source PKCS#11 Kit ^A] Manufacturer [PKCS#11 Kit ^A] flags [1] removable [false] token present [true]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): common name: [opensc]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): dll name: [/usr/lib64/pkcs11/opensc-pkcs11.so]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): Description [OMNIKEY AG CardMan 3121 00 00 OMNIKEY AG ^F] Manufacturer [OMNIKEY AG ^F] flags [6] removable [true] token present [false]. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [do_card] (0x4000): Token not present. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x0040): do_work failed. (Tue Aug 6 10:09:33 2019) [[sssd[p11_child[5558]]]] [main] (0x0020): p11_child failed!
This says that it tries only the first slot and if the token is not present there, it fails the whole child, which seems to be confirmed by the code:
https://pagure.io/SSSD/sssd/blob/master/f/src/p11_child/p11_child_openssl.c#_1580
I think there should be some cycle around making sure all the slots are tested for the first issue.
I think this will be addressed by the addressing the above, since on plugging in the reader, the p11_child pops up with the empty card reader only and probably reports the card was removed, even if it is still there.
This sounds like missing event on the reader removal.
Additionally, it looks like I am hitting the following Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1722294 which is making the gsd-smartcard-manager crashing in p11-kit, which might or might not be directly related to this issue.
Actually, I think the problem is here:
https://pagure.io/SSSD/sssd/blob/master/f/src/p11_child/p11_child_openssl.c#_1544
This takes only the first slot (empty OMNIKEY is removable slot) and let it fail with it, ignoring any other slots that might have valid certificates.
Though, I am not sure what would be the correct fix from top of my head.
For now, I was able to workaround this issue by setting the p11_uri option to specify yubikey URI, but it is a bit annoying. This actually resolves all of the three issues described above.
p11_uri
Hi Jakub,
to handle multiple device you can use the 'p11_uri' option in the [pam] section of sssd.conf to specify a PKCS#11 URI (please note there is a know typo in the sssd.conf man page, the 'pkcs11:' prefix is missing in the examples). Does authentication work if you add the URI for the Yubikey?
The screen lock is handled by gdm/gsd. pam_sss sets PKCS11_LOGIN_TOKEN_NAME during authentication with a Smartcard. So in theory the Gnome components might be able to only act on events from the device used for login but since they use NSS I'm not sure if all needed information would be available.
HTH
bye, Sumit
Looks like my reply came too late.
Imo in a setup with multiple device it would be more reliable to require a PKCS#11 URI for the device which should be used for authentication. Otherwise in your setup if there is a card in the reader authentication would fail because the card in the reader will most probably not have the right data since this is stored in the Yubikey.
That is the reason why the cards (usually) contain readable public keys and certificates which can be checked before trying to login into the particular card. The same way as you iterate over the certificates to check whether they are acceptable, you should probably iterate over the slots.
I think sssd should be able to handle this use case more gracefully out of the box, even though I agree that this is not the most common use case I have here :) If nothing, this can be used for documentation/known issues/troubleshooting since the error and behavior is not very straightforward.
Imo in a setup with multiple device it would be more reliable to require a PKCS#11 URI for the device which should be used for authentication. Otherwise in your setup if there is a card in the reader authentication would fail because the card in the reader will most probably not have the right data since this is stored in the Yubikey. That is the reason why the cards (usually) contain readable public keys and certificates which can be checked before trying to login into the particular card. The same way as you iterate over the certificates to check whether they are acceptable, you should probably iterate over the slots.
Yes, and SSSD already does this for a single slot, i.e. reading all certificates. filtering the certificates which match the matching rule and then check with the help of the mapping rule if the found certificate maps to the user trying to log in.
It would indeed be possible to iterate over all slots and check all found certificates. The drawback is that the authentication would be even longer.
I agree that checking all available slots might be less surprising for a user. Do you agree that I treat this ticket not as a bug but as a RFE?
Sure. No problem. I understand that this is not a common case and we have a simple workaround (which I kind of managed to figure out only after initial debugging).
In the case, there is empty reader (as it was in my initial case), the speed penalty should be minimal or almost none.
And also note that when the URI is not specified, the removal of yubikey does not lock the screen, even if it is the only token in the system, which I would consider a bug, somebody is more likely to hit.
It looks like with the current version sssd-2.2.2-1.fc30.x86_64, these things work fine with the p11_uri specified including the lock screen. I will report further issues if I will encounter one.
sssd-2.2.2-1.fc30.x86_64
Metadata Update from @pbrezina: - Issue tagged with: Future milestone
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/5025
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.