#1497 [RFE] Expose Kerberos ticket data on IFP from KCM
Opened 7 years ago by nalin. Modified 2 years ago

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

Fields changed

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

Fields changed

priority: minor => critical

Fields changed

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

Fields changed

mark: => 0

Fields changed

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

Fields changed

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)

2 years ago

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

2 years ago

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

2 years ago

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

2 years ago

Login to comment on this ticket.

Metadata