we use a pam module that normalizes the credential cache. If krb5.conf asks for
KEYRING and sshd leaves the cache in /tmp, the code moves it into KEYRING and
updates KRB5CCNAME.
I really like KEYRING. Our staff have multiple principals. With a collection,
kinit will create a new cache in the collection without disrupting the old one,
so kswitch can take you back. We use two-factor, so we’d rather not have to get
new credentials.
However there’s a gotcha. Kerberized NFS uses (by default) the currently
selected principal. So for a collection to be useful, we also have a ccselect
plugin to make sure that NFS (actually rpc.gssd) always gets the right
principal from the collection.
> On Mar 5, 2020, at 11:44:47 PM, abdullahrao <abdullah.s....@gmail.com> wrote:
>
> Hi,
>
> I had faced the same issue and found that I had to change the value for
> default_ccache_name from "KEYRING:persistent:%{uid}" to "/tmp/krb5cc_%{uid}"
>
>
>
> --
> Sent from: http://kerberos.996246.n3.nabble.com/Kerberos-General-f11810.html
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
