Learn more about these different git repos.
Other Git URLs
Provider should support both online and offline cached operation.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.6.0
coverity: => owner: somebody => sbose upgrade: => 0
milestone: SSSD 1.6.0 => SSSD Deferred
Deferring as there is no asynchronous interface in the yubikey client library.
rhbz: => 0
SSSD now looks up users using a certificate. I don't think we should implement a yubikey provider per se.
blockedby: => blocking: => changelog: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: => 0 patch: => 0 review: => 1 selected: => sensitive: => 0
It might still be interesting if we want to support 2-factor-authentication for local users. But I agree it does not mean that we need a yubikey provider per se, we should consider if we can integrate or co-operate with pam_yubico first.
OK, then let's not close this one yet.
review: 1 => 0
Metadata Update from @sgallagh: - Issue assigned to sbose - Issue set to the milestone: SSSD Patches welcome
I believe sssd now supports yubikey4.
SSSD supports Yubikey4 with certificate/Smartcard authentication because Yubikey4 offers a PKCS#11 interface which is used by Smartcards as well.
The "classical" one-time-password mode is only supported when used together with FreeIPA.
I still think that it might make sense to think about how pam_yubico (or other PAM modules for other tokens e.g. RSA) can be used here.
Maybe we can add a 'auth_provider_second' option and use the current proxy code to call pam_yubico (or others) with a second factor for local users?
Metadata Update from @sbose: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/1711
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.
Login to comment on this ticket.