#1723 [RFE] Expand kerberos ticket renewal in KCM
Closed: cloned-to-github 3 years ago by pbrezina. Opened 11 years ago by prefect.

If one logs in to a machine with OpenSSH with GSSAPI and delegations enabled, OpenSSH creates a new ccache file to store the delegated credential. This file isn't handled by sssd, so isn't renewed.

It would be preferable if this was renewed in the same fashion as a ticket generated by sssd would be had you logged in using SSH with a password.

This occurs if you use these settings with OpenSSH:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Fields changed

summary: Expand kerberos ticket renewal => [RFE] Expand kerberos ticket renewal

Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred
selected: =>

Fields changed

rhbz: => todo

If #1497 was implemented, it would be possible to handle this outside SSSD.

changelog: =>
review: => 0

Fields changed

cc: => Michael.Gliwinski@henderson-group.com

This will be solved by KCM

mark: => 0
review: 0 => 1
sensitive: => 0

Fields changed

blockedby: => 2887

Fields changed

review: 1 => 0

Metadata Update from @prefect:
- Issue marked as depending on: #2887
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None

7 years ago

Copying request from ticekt #2887 about renewals:
I have a request for the proposed KCM implementation. This is the ticket pointed to by the design doc, so I assume it's the right place.

The Heimdal KCM daemon appears to renew tickets as long as the KDC allows it. We have lots of users who run long jobs, and even daemons. The safe setting for us is to allow renewal indefinitely. But we don't want tickets to last longer than needed. We currently have a daemon that renews credentials. You register credentials for renewal by creating an entry in the session keyring. As far as I can tell, the session keyring has exactly the right properties for ticket lifetime. Even if someone spawns a daemon in a cron job (which our students do, because it's the only way they can restart the daemon after a reboot), it should remain in the same session. Hence we continue renewing tickets as long as there is an entry in any session keyring pointing to it.

I'd like to avoid having to maintain local utilities. It would be really nice if you'd use this approach or something like it to decide how long to renew credentials.

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

6 years ago

In case it isn't clear: we use a pam session module to create the entry in the session keyring. It looks at KRB5CCNAME, which should have been set up by the time it's called, to find the ticket to register. That lets us support sshd or anything else that uses pam. We just create an entry with a specific key, and the ticket id as the value.

With KCM, krb5ccname is always just "KCM:". That's part of the KCM protocol, so any configuration must be done on the KCM deamon side.

I'm not sure yet how the renewals would be configured. We discussed that with another developer briefly a couple of weeks ago and so far thought about renewing tickets that were acquired by SSSD if SSSD is set to renew them. But that would be a system-wide setting, I guess. It looks like in your case you'd like some ccaches to be stored in the persistent scope and some in the session scope, right?

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

6 years ago

As long as session is defined as it is in keyring, so it includes processes kicked off by a session, I'd be happy with all tickets being session scope. At that point you could just renew all tickets as long as their session lasts. In particular, we have users to use cron jobs to make sure their apache servers are alive, and if not kick one off. Any server started by a cron job needs to be in the same session. (This may seem like a wierd setup, but we have shared machines used for student assignments that involve running, and sometimes writing, a server.)

We've been using persistent uid and /tmp, simply because those are the defaults and I thought they'd be better supported. But I'm using a session scope key to keep track of how long they should be renewed, so having the tickets themselves be session would be fine.

If sssd does the renewal there needs to be a way to register a ticket to be renewed, unless sssd can see all tickets whether it issued them or not. If KCM is built into sssd that's probably the case. Clearly the simplest policy would be to renew all tickets as long as possible. That would be fine if they're session scope. But I very specifically do not want someone to login to do something brief, and have their ticket live forever. That significantly increases their exposure to compromise. In our environment it's not just that someone might steal their ticket, but that their file are exposed via Kerberized NFS, while they're not if there's no ticket.

Essentially, if sssd only renews tickets it issued, the feature isn't useful to me, since I still have to maintain renewd for other tickets. It's also not useful if tickets live forever (i.e if they're not tied in some way to a session).

One other note: Consider how this will interoperate with rpc.gssd. Our primary purpose for using Kerberos was to secure our file systems. As far as I can tell, rpc.gssd works with the kernel to set up kernel-based security contexts They are per-user, not per-session. So if KCM maintains session-based tickets, there should be some syntax rpc.gssd (actually gssproxy, probably) can use to retrieve a ticket for a given user independent on session, presumably the one with the latest expiration time.

Thanks for all the inputs. I need to ponder this a bit more and currently I'm dealing with some internal deadlines for the next RHEL version, so I think I will only get back to KCM work in a couple of weeks. I'll make sure to discuss what you brought up with the the gssproxy developers as well.

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

6 years ago

Thanks. The ideal state, in my view, would be to have session-based NFS security contexts in the kernel (probably in addition to user-based contexts). That would solve an issue that is otherwise going to require kludges: When a user logs off, we'd like the NFS access to expire immediately, and not live until the expiration of the ticket that created the context. If you provide sessions-based contexts, then they go away at the right time.

But that's probably too ambitious. That means that roc.gssd and gssproxy will probably have to deal with a kernel for which access is associated with the user, and KCM / sssd, where access may well be based on session. Hence the suggestion for a syntax like KCM:user:NNN to get a ticket for the user independent of session.

In case it matters, in addition to sssd, we will create Kerberos tickets in sshd and cron. In the case of cron, we're planning to acquire tickets through a PAM module. A user registers that they want to run cron jobs on a machine. A keytab is created for them on a secure machine. A client-server PAM module then retrieves a ticket from the server which the server generates using the keytab.

Because keytabs are global, we don't want users to put a keytab on the end-user machines. Remember that these are public machines accessible to all students. We don't want a root compromise to let someone steal keytabs for a bunch of user. Those keytabs could then be used to impersonate the user on any machine in the system. Hence the client-server app to acquire credentials for a user on the machine.

Also make sure you think about the interaction between kswitch, KCM, and gss. With keyring, gssproxy (and thus rpc.gssd) look at the primary cache in your keyring. If you have multiple caches, and use kswitch to pick one other than the one associated with your userid (e.g. some kind of administrative credentials), gssproxy will see the new primary. NFS access will probably fail, since it needs a ticket for the user.

What's worse, kinit implicitly does a kswitch to the new principal.

We're going to have to prohibit people from using kswitch, and surround kinit by a script that kswitches back to the user's primary credentials. The only safe way to switch is by setting KRB5CCNAME.

It's clear that NFS hasn't been fully integrated into the who Kerberos tool environment. A new implementation of KCM is the right time to get this right.

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1496869 (was: todo)

6 years ago

I'm not sure if the ticket renewal would make the 1.16.0 cut, but 1.16.x should be the milestone we implement the renewals at.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 set to the milestone: SSSD 1.16.0 (was: SSSD Patches welcome)

6 years ago

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)

6 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark 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: KCM

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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: postpone-to-2-0

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 untagged with: postpone-to-2-0
- Issue set to the milestone: SSSD 2.0 (was: SSSD 1.16.1)

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 set to the milestone: SSSD 2.1 (was: SSSD 2.0)

5 years ago

I've got enough time to work on this, but I'd like to agree on a design first. Suggestion:

Goals:
* automatically renew Kerberos tickets
* remove tickets as soon as possible after they are no longer needed

The reason for the second goal is that in an enviornment with Kerberized
NFS, root is able to access a user's files as long as there is a Kerberos
ticket on the system. If a user logs into a system briefly, we don't want
their files exposed after they log out.

It appears that systemd's sessions track session lifetimes properly, at
least in Centos 7 with default configurations.

Suggested design:
mechanism should be controlled by a sssd configuration option.
if pam_sss session doesn't get session information, nothing is
registered, and the mechanism does nothing. If it does but no
messages are sent on session termination, it renews all registered
credentials forever.
pam_sss session should register the current ticket, from KRB5CCNAME, with
sssd for renewal. It should be associated with the current
session. On our system this can be obtained from XDG_SESSSION_ID.
It should be verified that this is always true.
sssd should listen for logind dbus messages SessionRemoved(s session_id, o)
it should remove that session's request for that ticket, and if
no other session is registered for it, remove the ticket itself
sssd should automatically renew any tickets for which at least one
session has requested renewal
tickets not registered should be left alone, neither renewed nor
deleted

Note by the way that I can't see the bugzilla entry.

It would be absolutely awesome if you could work on this and I'd be glad to help you with whatever I can.

Looking at your design proposal, it seems like it's mixing two things that were separate in my mind previously - ccache scope (session vs. "global") and the ticket renewal. Currently the KCM ccache scope is just global, so totally unrelated to logind sessions. The session scope was also something on our list that was not done for some time, but I think it's not strictly related to the renewals and even ccaches not bound to any session could be renewed.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

The problem is figuring out when to renew a credential. The scope of credentials is global. But they're used by specific processes. You want to renew a credential as long as some process needs them. In fact my current code goes through /proc/NNN/environ looking at KRB5CCNAME for every process. If a credential is used by any KRB5CNAME, it's renewed. Mostly. Where KRB5CCNAME is set to a collection (which is typical for us), we have to pick the right one.

It seems to me that trolling through /proc/*/enviorn is kind of inelegant and arguably not scalable. The only other way I can think to know what's still in use is to use sessions. A ticket isn't really scoped to the session. The session is just used to see if it's still needed. I can't think of anything else that can be event driven, i.e. that doesn't require periodic polling. Can you? WIthout something that happens when a user logs out, we have to renew all tickets forever. That's unacceptable to us. The only other option I can see is to renew all tickets registered for a user until the user logs out.

We considered that, but didn't do it because it can result in unnecessary exposure of the user. We have users that run cron jobs a lot. They use Kerberos credentials that aren't forwardable. The cron jobs don't need to ssh, so there's no reason to make them forwardable. Suppose one of these users logs in briefly. With ssh, we generate forwardable credentials, since we want the user to be able to ssh to other hosts and use other applications that need forwardable tickets. When that user logs out, we don't want their forwardable tickets renewed just because they've got a cron job that doesn't need forwardable tickets.

Hence we want to track each ticket separately, and only renew the ones that are still in use. I don't think tracking on a per-process basis is feasible without periodic polling. But it's easy to associate tickets with sessions, and get a dbus notification when the session ends. This doesn't scope the credentials. it's just for tracking when they're in use.

[Incidentally, we generate tickets for cron sessions using a pam modujle that's only triggered by cron. A user has to register that they're going to run cron jobs on that system. The pam module makes a kerberized call to a daemon. If the user has registered that session, it generates a ticket and sends it back to the caller. This is more secure than the traditional approach of using keytables, because root can read the key table. If someone comrpomses root they can get smoething that's equivalent to the user's passowrd and that is usable anywhere in the domain. The user would also never know it has happened. With our system, you can only get a nonforwardable and time-limited ticket locked to that specific system. We have systems managed by end users, including grad students, so we really want to protect against root as well as possible. We also want t make Kerberos as transparent as possible. No keytables, no k5start. It's all done by pam and daemons, except that you have to register if you're going to run cron jobs.]

just to clarify: in order to allow separate renewal the pam module for cron generates explicitly unique tickets. It doesn't use the default. We're currently not using KCM:, but if we did, I assume it would be KCM:uid.XXXXXX. We're actually use files in /tmp. But I don't think it makes sense to do an sssd design that doesn't track actual usage of the ticket.

OK, I hope I'm starting to understand you better... I'm trying to focus on this part from your first comment: "remove tickets as soon as possible after they are no longer needed" mostly because the renewals part seems like the part I understand better.

Does this workflow describe what you mean wrt sessions?
- user U logs in to host H with ssh (ssh U@H). To keep things simple, let's assume there are no existing credentials available, so the login involves a full PAM conversation.
- pam_sss.so is invoked in PAM auth phase, SSSD acquires a TGT and stores it in KCM:U
- pam_systemd.so is invoked in PAM session phase, calls logind's CreateSession and creates a session
- the user does some work and logs out. At this point, pam_systemd.so calls ReleaseSession
- sssd-kcm receives the SessionRemoved signal which contains the object path to the session being terminated (right?). The session object has a property user which contains the UID of the user who ended the session at which point we can call e.g. sd_uid_get_sessions to see if the user still has any sessions left or not and of not, just remove all the credentials.

Does this sounds about right?

I still think the renewals are somewhat orthogonal, earlier you described a mechanism where only tickets registered through pam_sss.so session phase are scheduled for a renewal, but we've also had quite a few requests from users who'd like any tickets, including tickets just acquired with kinit, with no interaction through PAM whatsoever, to be renewed.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

We don't want all tickets renewed. E.g. suppose I login as hedrick, then kinit as hedrick.admin to do IPA administrative operations. I want hedrick to be renewed as long as I'm logged in, but I specifically do not want hedrick.admin to be renewed. I'd actually like those tickets to have short lifetimes as well, but we're not currently doing that. I really don't want administrative tickets lying around any longer than necessary.

This is why my design uses pam_sss(session) to register the ticket created for the login to be renewed. That will work for ssh. For kerberized login it doesn't use pam auth, but it does use pam session.

Your design is only tracking users. You're using the session release, but just to see whether the user is still there. So you're going to have to renew all tickets for the user. We specifically don't want to do that because a user may have different tickets with different policies (in our case forwardable or not). Those tickets need to be tracked separately, so that the forwardable ticket can be killed when the session that needs it ends, even though there may be another session using a non-forwardable ticket.

The only way your scheme would work is if we use KCM: only for interactive login tickets, which are forwardable, and KEYRING or /tmp for everything else, e.g. cron login tickets and misc. stuff like admin tickets. Perhaps that's what you envision. In such a scheme we wouldn't use KCM at all, so my motivation for writing the code is kind of low.

In our operation, a user may have at least three tickets, in my case:
hedrick, in the primary credential collection
hedrick.admin, in the primary credential collection
* hedrick for a cron job, in a /tmp file
Each of these has different properties and needs to be managed separately. Renewd does that.

We don't want all tickets renewed. E.g. suppose I login as hedrick, then kinit as hedrick.admin to do IPA administrative operations. I want hedrick to be renewed as long as I'm logged in, but I specifically do not want hedrick.admin to be renewed. I'd actually like those tickets to have short lifetimes as well, but we're not currently doing that. I really don't want administrative tickets lying around any longer than necessary.

You can achieve that already now with kinit using an override krb5.conf option

[libdefaults]
kdc_default_options = 0

if you specify KRB5_CONFIG=/etc/krb5.conf:/path/to/my/krb5.conf.override kinit then you'd apply the override only to your kinit run. KRB5_CONFIG environmental variable allows to specify multiple configuration files (including a directory too). kdc_default_options is set to include KDC_OPT_RENEWABLE_OK unless overridden, making the ticket renewable by default.

OK, I think we're getting there. Thanks for sticking with me, it appears you have the use-case well thought through.

So let's expand the scheme. We would need some options added to KCM:
- kcm_track_sessions = true|false. Defaults to false. This is related to what I described earlier
- kcm_renewals = true|false|session. You'd set this to session, meaning you only want to renew tickets as long as the owner has a session running. True would mean always renew all tickets (I think this is a valid thing to have configurable) and false would mean never renew any tickets.

One piece I'm still missing is how would you associate the tickets stored in KCM with a session? Keep in mind the tickets are created in pam_auth phase, so before the session phase.

You suggested to expand the pam_sss session phase to do that, but what exactly would it do? Earlier you said that pam_sss.so would peek at XDG_SESSION_ID and tell KCM to associate KRB5CCNAME with this session, correct? So we would have to have some kind of API between KCM and pam_sss.so. I guess we could expand the KCM protocol to do that.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Yes, we’ve thought of the use cases because we have existing automatic renewal. Making it work in all of our use cases has been interesting.

By the time we get to pam session, the session should exist. So the idea was that pam_sss in session would associate the ticket with the session. (Remember, it’s not a one to one mapping. Multiple sessions can use the same ticket. Generally interactive logins will all share one.)

There are a couple of ways to do that. But remember, pam_sss session may get called without pam_sss auth, e.g. if you ssh in with a kerberos credential. There are ways to pass data privately between pam auth and pam session. That could be used, but we can’t depend upon it. My assumption was that pam_sss auth or sshd would set KRB5CCNAME in the new environment. My current renewal scheme depends upon that, and we’ve had no problems. It has a session module that looks at KRB5CCNAME and registers the corresponding ticket to be renewed. If KRB5CCNAME is set to a collection, you have to find the currently selected credential cache in the collection and register it. We haven’t run into situations where there’s a ticket but KRB5CCNAME isn’t set.

Next, the question is how to identify the session. We’re not doing this now (we determine what tickets are in use by looking for KRB5CCNAME in /proc/*/environ). But it appears to me that XDG_SESSION_ID in the new environment points to the session. Probably you or one of your colleagues will know whether that’s the best way to determine the session. There seems to be a dbus login call getSessionByPID. That might be better, assuming pam knows the PID of the session it’s starting. Obviously pam_sss session would need to appear after the pam module that creates the session.

There’s a lot of weird cases. We have web applications as part of Hadoop, Jupyterhub and Apache Zeppelin. Both can use pam for authentication. We’re using a Kerberized Hadoop cluster, so we need a ticket for the user. We’d like that ticket to be renewed. As far as I can tell, Zeppelin calls pam auth but not pam session at login. Indeed there’s not even a session. The main web app runs as a single process under the zeppelin user ID. When the user starts a task, it spawns an interpreter as the user (using sudo, which is configured to allow zeppelin to become anyone). That’s when the real task is started. Perhaps pam_sss could do the registration at that point. The sudo man page claims that it calls pam session. Jupyterhub doesn’t have this issue because it starts the user session at login, and seems to call pam session.

Finally, we currently use tickets in /tmp for cron jobs. The problem here is that we want separate tickets with different properties. There's no way with collections to get a cc that won’t be used as the default. That is, suppose we do the following:
start a cron job with a non-forwardable ticket using a unique generated name in KEYRING:persistent.
ssh into the system
Normally ssh will generate a new, forwardable ticket. But it turns out that if there’s an existing ticket (really, cc) in the collection, it uses it. I believe it updates the contents, but either way we have an issue. We want two separate tickets, one forwardable and one not, which are renewed and deleted separately. What we get is one ticket. So at the moment we generate a ticket in /tmp for cron. That keeps it separate. Is there a way to get a separate cc with KCM that won’t be overwritten by sshd?

Is there any reason renewal needs to be limited to KCM?

On Oct 3, 2018, at 3:53 AM, Jakub Hrozek pagure@pagure.io wrote:

jhrozek added a new comment to an issue you are following:
``
OK, I think we're getting there. Thanks for sticking with me, it appears you have the use-case well thought through.

So let's expand the scheme. We would need some options added to KCM:
- kcm_track_sessions = true|false. Defaults to false. This is related to what I described earlier
- kcm_renewals = true|false|session. You'd set this to session, meaning you only want to renew tickets as long as the owner has a session running. True would mean always renew all tickets (I think this is a valid thing to have configurable) and false would mean never renew any tickets.

One piece I'm still missing is how would you associate the tickets stored in KCM with a session? Keep in mind the tickets are created in pam_auth phase, so before the session phase.

You suggested to expand the pam_sss session phase to do that, but what exactly would it do? Earlier you said that pam_sss.so would peek at XDG_SESSION_ID and tell KCM to associate KRB5CCNAME with this session, correct? So we would have to have some kind of API between KCM and pam_sss.so. I guess we could expand the KCM protocol to do that.
``

To reply, visit the link below or just reply to this email
https://pagure.io/SSSD/sssd/issue/1723

One interesting note: with Zeppelin, the Zeppelin app is all we really care about. You'd think we wouldn't need to track sessions, but could just renew a single ticket as long as the user is active. Unfortunately that won't work, without a really special-case hack.

The difficulty is that Zeppelin doesn't create any user process until the first time the user runs a task. We observe that this may be an hour or so after they login. I assume that renew = yes would continue renewing as long as the user has a process, and kill the ticket when the user logs out. But it wouldn't find any user process for an hour, and thus would probably kill the ticket immediately.

With renew = session, it doesn't start tracking the ticket until a user process is created, so things work. Unless the user doesn't do anything before ticket expiration, of course, but that's unusual.

Yes, we’ve thought of the use cases because we have existing automatic renewal. Making it work in all of our use cases has been interesting.
By the time we get to pam session, the session should exist. So the idea was that pam_sss in session would associate the ticket with the session. (Remember, it’s not a one to one mapping. Multiple sessions can use the same ticket. Generally interactive logins will all share one.)
There are a couple of ways to do that. But remember, pam_sss session may get called without pam_sss auth, e.g. if you ssh in with a kerberos credential. There are ways to pass data privately between pam auth and pam session. That could be used, but we can’t depend upon it. My assumption was that pam_sss auth or sshd would set KRB5CCNAME in the new environment. My current renewal scheme depends upon that, and we’ve had no problems. It has a session module that looks at KRB5CCNAME and registers the corresponding ticket to be renewed. If KRB5CCNAME is set to a collection, you have to find the currently selected credential cache

Currently selected = default?

in the collection and register it. We haven’t run into situations where there’s a ticket but KRB5CCNAME isn’t set.
Next, the question is how to identify the session. We’re not doing this now (we determine what tickets are in use by looking for KRB5CCNAME in /proc/*/environ). But it appears to me that XDG_SESSION_ID in the new environment points to the session. Probably you or one of your colleagues will know whether that’s the best way to determine the session.

Looking at the documentation it appears so

There seems to be a dbus login call getSessionByPID. That might be better, assuming pam knows the PID of the session it’s starting. Obviously pam_sss session would need to appear after the pam module that creates the session.

I checked the PAM stack on my Fedora machine and indeed pam_systemd is present before pam_sss

There’s a lot of weird cases. We have web applications as part of Hadoop, Jupyterhub and Apache Zeppelin. Both can use pam for authentication. We’re using a Kerberized Hadoop cluster, so we need a ticket for the user. We’d like that ticket to be renewed. As far as I can tell, Zeppelin calls pam auth but not pam session at login. Indeed there’s not even a session. The main web app runs as a single process under the zeppelin user ID. When the user starts a task, it spawns an interpreter as the user (using sudo, which is configured to allow zeppelin to become anyone). That’s when the real task is started. Perhaps pam_sss could do the registration at that point. The sudo man page claims that it calls pam session.

At least on Fedora, /etc/pam.d/sudo includes /etc/pam.d/system-auth which includes pam_systemd.so in session

Jupyterhub doesn’t have this issue because it starts the user session at login, and seems to call pam session.
Finally, we currently use tickets in /tmp for cron jobs. The problem here is that we want separate tickets with different properties. There's no way with collections to get a cc that won’t be used as the default. That is, suppose we do the following:
start a cron job with a non-forwardable ticket using a unique generated name in KEYRING:persistent.
ssh into the system
Normally ssh will generate a new, forwardable ticket. But it turns out that if there’s an existing ticket (really, cc) in the collection, it uses it. I believe it updates the contents, but either way we have an issue. We want two separate tickets, one forwardable and one not, which are renewed and deleted separately. What we get is one ticket. So at the moment we generate a ticket in /tmp for cron. That keeps it separate. Is there a way to get a separate cc with KCM that won’t be overwritten by sshd?

I can't think of any except using a different KRB5CCNAME. This is also IMO not really something that KCM decides, but libkrb5..KCM has a "proprietary" protocol that is used for communication between libkrb5 and KCM which includes operations like "resolve this CCNAME into a UUID" or "store these credentials into this UUID".

Is there any reason renewal needs to be limited to KCM?

In theory, no (after all, you have your renewd..), it's just that since KCM is already a ticket-tracking deamon, it makes sense to do the renewal there. btw for tickets acquired by SSSD during pam_sss auth, SSSD already tries to renew tickets.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

One interesting note: with Zeppelin, the Zeppelin app is all we really care about. You'd think we wouldn't need to track sessions, but could just renew a single ticket as long as the user is active. Unfortunately that won't work, without a really special-case hack.
The difficulty is that Zeppelin doesn't create any user process until the first time the user runs a task. We observe that this may be an hour or so after they login. I assume that renew = yes

I thought about renew=yes as 'renew as long as the ticket is renewable'.

would continue renewing as long as the user has a process, and kill the ticket when the user logs out. But it wouldn't find any user process for an hour, and thus would probably kill the ticket immediately.
With renew = session, it doesn't start tracking the ticket until a user process is created,

s/process/session/

so things work. Unless the user doesn't do anything before ticket expiration, of course, but that's unusual.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Let me try to put what we discussed so far together.

  1. Overview
    The end goal is to enable Kerberos ticket renewal and logind session integration. The logind integration would serve two ends - to enable destroying the credentials once the user finishes all their sessions and enable renewing only those tickets that are part of a user session.

  2. Ticket renewal
    KCM should be able to renew Kerberos tickets stored in the KCM deamon database. This would be akin to the user running kinit -R. The renewal would be controlled by a new KCM deamon option kcm_renew_tickets. This option would allow three possible options: true, false and session.
    The false option is hopefully self-explanatory, KCM would do nothing.
    If the option was set to true, then KCM would renew ccaches undonditionally until the renewal threshold is reached.
    If the option was set to session, then KCM would renew only those ccaches that are associated with a logind session and not try to renew other ccaches.
    The renewal is a blocking operation, so KCM would have to fork out a helper process to do the renewal. The already existing krb5_child process could be used for renewals.
    The renewal should be attempted at a defined at defined times of the ccache lifetime, say 50, 75, and just before the lifetime ends.

  3. Session tracking
    a. associating ccaches with sessions
    A way to associate the ccaches with user sessions must be designed. We can't rely on the ccache to be created within the context of a session, because often the credentials are either created before a session starts (during the PAM auth phase, while the session only starts in the PAM session phase) or forwarded from elsewhere.
    Therefore we would try to associate an existing ccache, referenced by the KRB5CCNAME environment variable with the session identifier as read from XDG_USER_SESSION_ID PAM environment variable.
    During the PAM session phase, the pam_sss module would forward the environment variables to the sss_pam responder. The PAM responder would have to verify that the XDG_USER_SESSION_ID variable corresponds to the UID of the user logging in to make sure we can trust its value. Once the KRB5CCNAME-session pair is known, the PAM responder needs to tell the KCM server to associate this ccache with a session ID. To do this, we need a way for the PAM responder to talk to the KCM deamon. But since both are part of SSSD and since the work on SSSD 2.0 each SSSD process can pose as a D-bus server, we could devise a private D-BUS API that the sssd_pam responder would use to tell sssd_kcm to associate a ccache with a session. One ccache can be associated with multiple session IDs.
    b. destroying ccaches after all sessions terminate
    Optionally (perhaps using another option like kcm_track_sessions), KCM could also offer the ability to remove ccaches once all user sessions terminate. To do this, the KCM deamon would also listen to the SessionRemoved D-Bus signal. This signal includes an object path to the session which can be used to obtain the UID of the user whose session had ended. Using this ID we can check if any other sessions exist for this UID and if not, we remove all of this user's credentials.

  4. Open questions
    a. On the KCM database level, how should we associate the session with the ccache?
    At the moment, the ccaches are stored under a path called /kcm/persistent/$UID/ccache/. Perhaps we could, when associating the session, create another entry under /kcm/session/$UID/$session_name/ccache that would point to the ccache entry.
    b. Making D-Bus calls
    For the communication between sssd_pam and sssd_kcm we can already use the sbus wrapper that we already use for communication between different SSSD components. We should also check if the sbus wrapper can be extended to call methods on the system bus to e.g. resolve session ID's owner.
    c. Avoiding renewal attempts while the machine is offline
    This could be done later, but in general it would be nice to not even attempt the renewal if we know the machine can't reach the KDC. For systems where there exists an SSSD domain that is connected to the Kerberos realm of a ccache, perhaps we could query the online/offline status of the domain and don't even attempt the renewals if the domain is offline. However, we probably don't have other choice than try if there are no SSSD domains (e.g. a system that only uses krb5.conf)

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Normally ssh will generate a new, forwardable ticket. But it turns out that if there’s an existing ticket (really, cc) in the collection, it uses it. I believe it updates the contents, but either way we have an issue. We want two separate tickets, one forwardable and one not, which are renewed and deleted separately. What we get is one ticket. So at the moment we generate a ticket in /tmp for cron. That keeps it separate. Is there a way to get a separate cc with KCM that won’t be overwritten by sshd?

To make sure I understant this, are you looking after something like:
kinit -f foo
now klist -f would list a forwardable ticket

kinit -F foo
now what you want is for klist -f would list BOTH a forwardable and a non-forwardable ticket, but what really happens is that the previous ticket gets overwritten

I still don't know how to solve this, just making sure I understand the requirement

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Yes, this looks right.

On Oct 4, 2018, at 6:38 AM, Jakub Hrozek pagure@pagure.io wrote:
=20
=20
jhrozek added a new comment to an issue you are following:
Let me try to put what we discussed so far together. =20 1. Overview The end goal is to enable Kerberos ticket renewal and logind session i= ntegration. The logind integration would serve two ends - to enable destroy= ing the credentials once the user finishes all their sessions and enable re= newing only those tickets that are part of a user session. =20 1. Ticket renewal KCM should be able to renew Kerberos tickets stored in the KCM deamon= database. This would be akin to the user running `kinit -R`. The renewal w= ould be controlled by a new KCM deamon option `kcm_renew_tickets`. This opt= ion would allow three possible options: `true`, `false` and `session`.=20 The `false` option is hopefully self-explanatory, KCM would do nothing. If the option was set to `true`, then KCM would renew ccaches undonditi= onally until the renewal threshold is reached. If the option was set to `session`, then KCM would renew only those ccac= hes that are associated with a logind session and not try to renew other cc= aches. The renewal is a blocking operation, so KCM would have to fork out a hel= per process to do the renewal. The already existing `krb5_child` process co= uld be used for renewals. The renewal should be attempted at a defined at defined times of the cca= che lifetime, say 50, 75, and just before the lifetime ends. =20 1. Session tracking a. associating ccaches with sessions A way to associate the ccaches with user sessions must be designed. We= can't rely on the ccache to be created within the context of a session, be= cause often the credentials are either created before a session starts (dur= ing the PAM auth phase, while the session only starts in the PAM session ph= ase) or forwarded from elsewhere. Therefore we would try to associate an existing ccache, referenced by t= he KRB5CCNAME environment variable with the session identifier as read from= XDG_USER_SESSION_ID PAM environment variable. During the PAM session phase, the pam_sss module would forward the env= ironment variables to the sss_pam responder. The PAM responder would have t= o verify that the XDG_USER_SESSION_ID variable corresponds to the UID of th= e user logging in to make sure we can trust its value. Once the KRB5CCNAME-= session pair is known, the PAM responder needs to tell the KCM server to as= sociate this ccache with a session ID. To do this, we need a way for the PA= M responder to talk to the KCM deamon. But since both are part of SSSD and = since the work on SSSD 2.0 each SSSD process can pose as a D-bus server, we= could devise a private D-BUS API that the sssd_pam responder would use to = tell sssd_kcm to associate a ccache with a session. One ccache can be assoc= iated with multiple session IDs. b. destroying ccaches after all sessions terminate Optionally (perhaps using another option like `kcm_track_sessions`), KC= M could also offer the ability to remove ccaches once all user sessions ter= minate. To do this, the KCM deamon would also listen to the `SessionRemoved= ` D-Bus signal. This signal includes an object path to the session which ca= n be used to obtain the UID of the user whose session had ended. Using this= ID we can check if any other sessions exist for this UID and if not, we re= move all of this user's credentials. =20 1. Open questions a. On the KCM database level, how should we associate the session with= the ccache? At the moment, the ccaches are stored under a path called `/kcm/p= ersistent/$UID/ccache/`. Perhaps we could, when associating the session, cr= eate another entry under `/kcm/session/$UID/$session_name/ccache` that woul= d point to the ccache entry. b. Making D-Bus calls For the communication between sssd_pam and sssd_kcm we can already = use the sbus wrapper that we already use for communication between differen= t SSSD components. We should also check if the sbus wrapper can be extended= to call methods on the system bus to e.g. resolve session ID's owner. c. Avoiding renewal attempts while the machine is offline This could be done later, but in general it would be nice to not eve= n attempt the renewal if we know the machine can't reach the KDC. For syste= ms where there exists an SSSD domain that is connected to the Kerberos real= m of a ccache, perhaps we could query the online/offline status of the doma= in and don't even attempt the renewals if the domain is offline. However, w= e probably don't have other choice than try if there are no SSSD domains (e= .g. a system that only uses krb5.conf)
=20
To reply, visit the link below or just reply to this email
https://pagure.io/SSSD/sssd/issue/1723

Yes. But there doesn’t seem to be a problem. I just enabled KCM on a test system. There are, however a couple of issues:

When I login I get KCM:1003 or possibly KCM:1003.NNN. For a cron job I would explicitly create a cc KCM:1003:cron-NNN. When I did kinit -c for a specific cc, it didn’t seem to set the primary cache of the collection, so this doesn’t interfere with the tickets used by the login sessions. So there’s on problem maintaining a separate ccache. I won’t need to use files in /tmp, it doesn’t appear.

Problem 1: After login KRB5CCNAME is set to KCM:1003 or KCM:1003.NNN. We’d really like it to be set to KCM:. If KRB5CCNAME is set to a collection, and you kinit as another principal, kinit is smart enough to create a new cc in the collection and switch to ti. If KRB5CCNAME is set to a specific ccache it overwrites the primary ticket. This is fatal to NFS, since NFS has to have the user’s primary identity available in whatever is defined as the default ccname in krb5.conf (in this case KCM:).

Problem 2: There’s a bug in rpc.gssd with respect to collections. What it should do is call gssapi asking for the user’s primary principal, i.e. USER@DOMAIN. That’s the only principal that can work with NFS. In that case GSSAPI is smart enough to examine all tickets in the collection (and some other places) and return the right one. What rpc.gssd actually does is ask for the default cc, check to see if it’s the primary one, and fail if not. This causes failure in the case that the user has kinit’ed to an alternative identify, even though the correct cc is actually in the collection and GSSAPI is perfectly capable of finding it.

I’ve submitted https://bugzilla.linux-nfs.org/show_bug.cgi?id=318, which includes the correct code, but it doesn’t appear that anyone has looked at it. For the moment I’m using a wrapper loaded by LD_PRELOAD to fix rpc.gssd. This issue is more likely to show up for us than other sites because I run with rpc.gssd -t 600, so credentials are reevaluated every 10 min. I do this so once a user is logged out, someone who su’s to them won’t be able to see their files.

On Oct 4, 2018, at 6:42 AM, Jakub Hrozek pagure@pagure.io wrote:

jhrozek added a new comment to an issue you are following:
``

Normally ssh will generate a new, forwardable ticket. But it turns out that if there’s an existing ticket (really, cc) in the collection, it uses it. I believe it updates the contents, but either way we have an issue. We want two separate tickets, one forwardable and one not, which are renewed and deleted separately. What we get is one ticket. So at the moment we generate a ticket in /tmp for cron. That keeps it separate. Is there a way to get a separate cc with KCM that won’t be overwritten by sshd?

To make sure I understant this, are you looking after something like:
kinit -f foo
now klist -f would list a forwardable ticket

kinit -F foo
now what you want is for klist -f would list BOTH a forwardable and a non-forwardable ticket, but what really happens is that the previous ticket gets overwritten

I still don't know how to solve this, just making sure I understand the requirement
``

To reply, visit the link below or just reply to this email
https://pagure.io/SSSD/sssd/issue/1723

QXNzdW1lIHRoYXQgd2UgcmVuZXcgZXZlcnl0aGluZyBpbiB0aGUgcmVuZXcgdGFibGUgdW50aWwg
dGhlIHRpY2tldCBpcyBraWxsZWQgKG9yIHJlbW92ZWQgZnJvbSB0aGUgcmVuZXcgdGFibGUsIGJ1
dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3aWxsIGhhcHBlbiB3aXRob3V0IGtpbGxpbmcgaXQpLg0K
DQpUaGVuIGFkZF90Z3RfdG9fcmVuZXdfdGFibGUgaGFzIHRvIGJlIGFkZGVkIHRvIHBhbSBzZXNz
aW9uLg0KDQpUaGUgcmVzdCBvZiB0aGUgbG9naWMgZGVwZW5kcyB1cG9uIG1vZGU6DQoNCnJlbmV3
ID0gdXNlcg0KICAgZGJ1cyBzaWduYWwgdXNlcnJlbW92ZWQNCiAgICAgICAga2lsbCBhbGwgb2Yg
dGlja2V0cyBmb3IgdGhlIHVzZXIgaW4gdGhlIHJlbmV3IHRhYmxlIFtvciBhbGwgdGlja2V0cyBm
b3IgdGhlIHVzZXI/XQ0KDQpyZW5ldyA9IHNlc3Npb24NCiAgcGFtIHNlc3Npb24uIEFkZCAva2Nt
L3Nlc3Npb24vJFVJRC8kc2Vzc2lvbl9uYW1lL2NjYWNoZSBwb2ludGluZyB0byBjY2FjaGUNCiAg
ZGJ1cyBzaWduYWwgc2Vzc2lzb25yZW1vdmVkDQogICAgICBsb29rIHVwIC9rY20vc2Vzc2lvbi8k
VUlELyRzZXNzaW9uX25hbWUvY2NhY2hlDQogICAgICAgICByZW1vdmUgZW50cnkgL2tjbS9zZXNz
aW9uLyRVSUQvJHNlc3Npb25fbmFtZS9jY2FjaGUNCiAgICAgICAgIGxvb3Agb3ZlciAva2NtL3Nl
c3Npb24vJFVJRC8kc2Vzc2lvbl9uYW1lLCBjaGVja2luZyB0byBzZWUgaWYgdGhlcmUgYXJlIG1v
cmUgcG9pbnRlcnMgdG8gdGhlIHNhbWUgY2NhY2hlDQogICAgICAgICBpZiB0aGVyZSBhcmUgbm8g
bW9yZSBwb2ludGVycyB0byB0aGF0IGNjYWNoZSwga2lsbCBpdA0KDQpJZiBJIHVuZGVyc3RhbmQg
d2hhdCB0aGUgc2lnbmFsIFVzZXJyZW1vdmVkIGlzLCB3ZSBvbmx5IG5lZWQgdG8gcmVjZWl2ZSBk
YnVzIHNpZ25hbHMsIG5vdCBtYWtlIGRidXMgZnVuY3Rpb24gY2FsbHMuIEkgYmVsaWV2ZSBVc2Vy
UmVtb3ZlZCBpcyB0aGUgbGFzdCBzZXNzaW9uIGZvciB0aGUgdXNlciB0ZXJtaW5hdGVkLCB0aG91
Z2ggaXQgc291bmRzIGxpa2UgaXTigJlzIHRoZSB1c2VyIGJlaW5nIHJlbW92ZWQgZnJvbSB0aGUg
c3lzdGVtLiBUaGUgbGF0dGVyIHdvdWxkbuKAmXQgYmUgcGFydCBvZiB0aGUgZnVuY3Rpb24gb2Yg
bG9naW5kLCBhbmQgd291bGRu4oCZdCBpbiBnZW5lcmFsIGJlIHBvc3NpYmxlLiAoWW914oCZZCBo
YXZlIHRvIHNvbWVob3cgc25vb3Agb24gbGRhcCBjaGFuZ2VzLikNCg0KDQpPbiBPY3QgNCwgMjAx
OCwgYXQgNjozOCBBTSwgSmFrdWIgSHJvemVrIDxwYWd1cmVAcGFndXJlLmlvPG1haWx0bzpwYWd1
cmVAcGFndXJlLmlvPj4gd3JvdGU6DQoNCiAgICAgICAgQXQgdGhlIG1vbWVudCwgdGhlIGNjYWNo
ZXMgYXJlIHN0b3JlZCB1bmRlciBhIHBhdGggY2FsbGVkIGAva2NtL3BlcnNpc3RlbnQvJFVJRC9j
Y2FjaGUvYC4gUGVyaGFwcyB3ZSBjb3VsZCwgd2hlbiBhc3NvY2lhdGluZyB0aGUgc2Vzc2lvbiwg
Y3JlYXRlIGFub3RoZXIgZW50cnkgdW5kZXIgYC9rY20vc2Vzc2lvbi8kVUlELyRzZXNzaW9uX25h
bWUvY2NhY2hlYCB0aGF0IHdvdWxkIHBvaW50IHRvIHRoZSBjY2FjaGUgZW50cnkuDQoNCg==

btw your last comment was rendered as base64 or something..was it supposed to be an attachment?

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Yes. But there doesn’t seem to be a problem. I just enabled KCM on a test system. There are, however a couple of issues:
When I login I get KCM:1003 or possibly KCM:1003.NNN. For a cron job I would explicitly create a cc KCM:1003:cron-NNN. When I did kinit -c for a specific cc, it didn’t seem to set the primary cache of the collection, so this doesn’t interfere with the tickets used by the login sessions. So there’s on problem maintaining a separate ccache. I won’t need to use files in /tmp, it doesn’t appear.
Problem 1: After login KRB5CCNAME is set to KCM:1003 or KCM:1003.NNN. We’d really like it to be set to KCM:. If KRB5CCNAME is set to a collection, and you kinit as another principal, kinit is smart enough to create a new cc in the collection and switch to ti. If KRB5CCNAME is set to a specific ccache it overwrites the primary ticket. This is fatal to NFS, since NFS has to have the user’s primary identity available in whatever is defined as the default ccname in krb5.conf (in this case KCM:).

I /believe/ that this is all handled in libkrb5. I wonder if @rharwood understands this better? I must admit I'm getting a bit out of my depth here.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

Yes, this looks right.

thank you, I will start a more formal design page to get more feedback from other developers.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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)

5 years ago

I know libkrb5 pretty well. I do a lot of low-level Kerberos programming. It wouldn’t have the ability to set KRB5CCNAME within PAM. I just realized: my tests were probably ssh with a ticket. This is a known behavior of sshd. I have a pam module that resets KRB5CCNAME to the collection. That module mostly does things to set up renewal, but it does normalize KRB5CCNAME. I had hoped to scrap that module, because I don’t want to commit Rutgers to maintaining low-level C code forever. But this can only be done in C. pam_exec lets PAM run a shell script, but the shell script has no way to affect the environment PAM is preparing. In my opinion this is an sshd bug. I’ll see if I can get the ssh maintainers to fix it.

On Oct 5, 2018, at 7:12 AM, Jakub Hrozek pagure@pagure.io wrote:

jhrozek added a new comment to an issue you are following:
``

Yes. But there doesn’t seem to be a problem. I just enabled KCM on a test system. There are, however a couple of issues:
When I login I get KCM:1003 or possibly KCM:1003.NNN. For a cron job I would explicitly create a cc KCM:1003:cron-NNN. When I did kinit -c for a specific cc, it didn’t seem to set the primary cache of the collection, so this doesn’t interfere with the tickets used by the login sessions. So there’s on problem maintaining a separate ccache. I won’t need to use files in /tmp, it doesn’t appear.
Problem 1: After login KRB5CCNAME is set to KCM:1003 or KCM:1003.NNN. We’d really like it to be set to KCM:. If KRB5CCNAME is set to a collection, and you kinit as another principal, kinit is smart enough to create a new cc in the collection and switch to ti. If KRB5CCNAME is set to a specific ccache it overwrites the primary ticket. This is fatal to NFS, since NFS has to have the user’s primary identity available in whatever is defined as the default ccname in krb5.conf (in this case KCM:).

I /believe/ that this is all handled in libkrb5. I wonder if @rharwood understands this better? I must admit I'm getting a bit out of my depth here.
``

To reply, visit the link below or just reply to this email
https://pagure.io/SSSD/sssd/issue/1723

I /believe/ that this is all handled in libkrb5. I wonder if @rharwood understands this better? I must admit I'm getting a bit out of my depth here.

I checked the source. It turns out that this is a Redhat patch. With openssh sshd, if you ssh with Kerberos credentials, the process on the destination machine ends up with a unique ccname in FILE:/tmp. No matter what krb5.conf says. This would clearly not be good for KCM:. Redhat adds a patch that gets the right credentials most (though not all) the time. But they set KRB5CCNAME to the name of the actual cache. As far as I can tell there's no routine in libkrb5 to return the right name. sssd has interesting code to use the collection name rather than the specific cache name if the cache type supports kswitch. Code like that needs to be put into sshd to make behavior consistent. At the moment I end up with KCM:1003 rather than KCM:, which is probably not the result you want. If I submit a bug report to Redhat for openssh on this, is anyone likely to pay attention to it?

Please see also https://bugzilla.mindrot.org/show_bug.cgi?id=2815. This is a discussion with the sshd maintainer upstream. This is the same person who maintains ssh for Redhat. Currently there's a proposed resolution to my problem that will break sshd compatibility with KCM:. Since Redhat is about to make KCM: the default, I think the results are going to be unpleasant. I'm guessing that sshd is going to yield here, since you're stuck implementing the Heimdal API. But please look at the report and talk to the maintainer.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 set to the milestone: SSSD 2.2 (was: SSSD 2.1)

5 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark 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 set to the milestone: SSSD 2.3 (was: SSSD 2.2)

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field mark 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: Next milestone

4 years ago

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/2765

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

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)

3 years ago

Login to comment on this ticket.

Metadata