Learn more about these different git repos.
Other Git URLs
SSSD should return an AUTHTOK that would contain a GNOME keyring decryption key that will be passed via pam stack to GNOME keyring.
The key can come from the central server or some SSSD cache. This needs to be better designed. The main use cases: OTP authentication into desktop or login into virtual desktop. In these cases the key to GNOME keyring is not a user password. Instead in enterprise case the key can be stored in the central server like IPA. It should also be stored and cached locally for offline case.
Fields changed
type: defect => enhancement
milestone: NEEDS_TRIAGE => SSSD 1.14 beta
rhbz: => todo
This would require a FreeIPA ticket. But it can be done only when we have vault capability in IPA.
FreeIPA ticket is https://fedorahosted.org/freeipa/ticket/4176
The other option is to modify gnome-keyring and do not touch SSSD at all. Gnome-keyring could use PKCS#11 for manipulating the key used for keyring encryption. As a result, the key could be stored on a real smart card or in IPA.
PKCS#11
Given the fact that IPA is going to implement PKCS#11 interface anyway it seems that support for PKCS#11 standard in gnome-keyring is a way how to get more functionality with the same effort.
Related ticket - #2278 was requested sooner as it's a prerequisity for OTP. Moving up.
milestone: SSSD 1.14 beta => SSSD 1.13 beta
mark: => 1
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
Mass-moving tickets not planned for the 1.13 release to 1.14
milestone: SSSD 1.13 backlog => SSSD 1.14 beta
There is an existing thesis topic proposal for this RFE: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa
keywords: => thesis
Michal, is this part of your thesis?
cc: => mzidek@redhat.com milestone: SSSD 1.14 beta => SSSD 1.14 backlog sensitive: => 0
Replying to [comment:12 jhrozek]:
No. At least not in the way it is designed currently.
This ticket talks about storing the keys to decrypt GK inside FreeIPA, but my goal is to store there the secrets themselves (the secrets that are inside GK).
I see value in storing just the keys to decrypt the GK inside FreeIPA, but it is not the goal currently. However the only think this would achieve is that the user will not have to type the password for GK after login (which is still a good feature IMO, but not the goal of my thesis).
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1355909 (Red Hat Enterprise Linux 7)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1355909 1355909]
Since the 1.14 branch is transitioning into maintenance mode and new functionality is being developed in master which will become 1.15 eventually, I'm mass-moving tickets from the 1.14 backlog milestone to the "Future releases" milestone.
milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)
Metadata Update from @dpal: - Issue set to the milestone: SSSD Future releases (no date set yet)
Bugzilla closed as won't fix
Metadata Update from @thalman: - Custom field design_review reset (from 0) - Custom field mark adjusted to on (was: 1) - 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
Metadata Update from @thalman: - Custom field design_review reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - Issue tagged with: Canditate to close
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/3263
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.