Learn more about these different git repos.
Other Git URLs
If SSSD registered on the system message bus, then interested clients could listen for signals indicating when a user's Kerberos credentials were about to expire. Preferably, SSSD could be enlisted to monitor credentials that it didn't acquire, and provide a dialog-based method for obtaining new initial credentials.
This takes per-cctype work for figuring out how to monitor a ccache off of the desktop's plate. It also solves a problem that an unprivileged user has a harder time doing: if SSSD has access to the system keytab, it can use that to obtain credentials to use for setting up FAST. In realms where anonymous PKINIT isn't available, that's the only dependable option for doing so, and an unprivileged user can't do it alone.
Fields changed
milestone: NEEDS_TRIAGE => Temp milestone proposed_priority: Undefined => Core rhbz: => todo summary: Add a general-purpose D-Bus responder => [RFE] Add a general-purpose D-Bus responder
summary: [RFE] Add a general-purpose D-Bus responder => [RFE] Add a general-purpose D-Bus responder for ticket monitoring
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: Temp milestone => SSSD 1.10 beta
priority: minor => critical
design: => design_review: => 0 fedora_test_page: => selected: => Not need
Moving tickets that are not a priority for SSSD 1.10 into the next release.
milestone: SSSD 1.10 beta => SSSD 1.11 beta
If SSSD could be enlisted (via message bus or other means) to monitor credentials that it didn't acquire, it would also help solve a couple of other use-cases on servers where automatic renewal is useful:
- people logging in via SSH PKI (with keys), running kinit manually, and then running long-running jobs that access e.g. NFS with KRB5 - people logging in via SSH GSS-API (i.e. passwordless logins) and then running long-running jobs, etc.
Currently tickets won't be renewed automatically in those cases as the credentials cache is created by either kinit or sshd and not SSSD.
If appropriate functionality was exposed, it would be possible to script initialising tickets and adding the cache to be monitored from e.g. login scripts.
Also see related discusson on sssd-users list.
changelog: => review: => 0
Replying to [comment:7 mighg]:
If SSSD could be enlisted (via message bus or other means) to monitor credentials that it didn't acquire, it would also help solve a couple of other use-cases on servers where automatic renewal is useful: people logging in via SSH PKI (with keys), running kinit manually, and then running long-running jobs that access e.g. NFS with KRB5 people logging in via SSH GSS-API (i.e. passwordless logins) and then running long-running jobs, etc.
Please take a look at the GSSProxy project. GSSproxy can auto acquire and renew the tickets on your behalf in the scenarios that you described allowing scripts running as a user on a box assume kerberos identity you find appropriate.
https://fedorahosted.org/gss-proxy/ [[BR]] https://fedoraproject.org/wiki/Features/gss-proxy
Yes, gss-proxy does sound interesting indeed, but as Jakub Hrozek noted in the discussion: due to a large number of dependencies, GSSProxy is probably never coming to RHEL-6
cc: => Michael.Gliwinski@henderson-group.com
mark: => 0
milestone: SSSD 1.13 beta => SSSD 1.13 backlog patch: 0 => 1 priority: critical => minor
Mass-moving tickets not planned for the next two releases.
Please reply with a comment if you disagree about the move..
milestone: SSSD 1.13 backlog => SSSD 1.15 beta
blockedby: => #2887 sensitive: => 0
Metadata Update from @nalin: - Issue marked as depending on: #2887 - Issue set to the milestone: SSSD Future releases (no date set yet)
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field patch adjusted to on (was: 1) - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset - Issue close_status updated to: None
Metadata Update from @jhrozek: - Custom field design_review reset - Custom field mark reset - Custom field review reset - Custom field sensitive reset - Custom field testsupdated reset
Metadata Update from @lslebodn: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - Issue tagged with: KCM
Metadata Update from @thalman: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - 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/2539
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.