The latest versions of rpc.gssd look at file ownership rather than the
name. (It does narrow the field by looking for "krb5cc_*", then
looking at file ownership.) This change went into nfs-utils-1.0.11.

Unfortunately, gssd has no access to the user's environment variables
and cannot use that to determine the credentials cache file to use
when creating a context.

K.C.

On Jan 15, 2008 9:53 AM, Ido Levy wrote:
>
> We did a dipper investigation of this issue and found out that the
> difference between sshd and telnetd is in the user credential cache file
> name.
> While ssh to the machine the credential cache file name is composed using
> the numeric uid of the user like /tmp/krb5cc_XXXX. On the other hand while
> telnet to the machine the credential cache file name is composed using the
> telnet process number.
> As a result rpc.gssd is unable to find the credential cache file for the
> user since it tries to look for the files having the numeric uid as part of
> their name.
>
> In the /tmp directory the following file was created:
>
> ls -ltr /tmp/krb5cc_*
> -rw------- 1 user_name bin 431 Jan 15 16:41 /tmp/krb5cc_p3715
>
> Note that 3715 is the pid of the telnet process.
>
> Following is the output of the rpc.gssd daemon when we use telnet to enter
> the machine:
>
> xinetd[3713]: START: telnet pid=3715 from=x.xxx.xx.xx
> rpc.gssd[1934]: handling krb5 upcall
> rpc.gssd[1934]: Using keytab file '/etc/krb5.keytab'
> rpc.gssd[1934]: INFO: Credentials in CC 'MEMORY:/tmp/krb5cc_machine_REALM'
> are good until 1200491925
> rpc.gssd[1934]: using MEMORY:/tmp/krb5cc_machine_REALM as credentials cache
> for machine creds
> rpc.gssd[1934]: using environment variable to select krb5 ccache
> MEMORY:/tmp/krb5cc_machine_REALM
> rpc.gssd[1934]: creating context using fsuid 0 (save_uid 0)
> rpc.gssd[1934]: creating tcp client for server nfs_server.domain
> rpc.gssd[1934]: creating context with server nfs@nfs_server.domain
> rpc.gssd[1934]: DEBUG: serialize_krb5_ctx: lucid version!
> rpc.gssd[1934]: prepare_krb5_rfc1964_buffer: serializing keys with enctype
> 4 and length 8
> rpc.gssd[1934]: doing downcall
> rpc.gssd[1934]: handling krb5 upcall
> rpc.gssd[1934]: getting credentials for client with uid XXXX for server
> nfs_server.domain
> rpc.gssd[1934]: using FILE:/tmp/krb5cc_XXXX as credentials cache for client
> with uid XXXX for server nfs_server.domain
> rpc.gssd[1934]: using environment variable to select krb5 ccache
> FILE:/tmp/krb5cc_XXXX
> rpc.gssd[1934]: creating context using fsuid XXXX (save_uid 0)
> rpc.gssd[1934]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified
> GSS failure. Minor code may provide more information - No credentials
> cache found
> rpc.gssd[1934]: WARNING: Failed while limiting krb5 encryption types for
> user with uid XXXX
> rpc.gssd[1934]: WARNING: Failed to create krb5 context for user with uid
> XXXX for server nfs_server.domain
> rpc.gssd[1934]: doing error downcall
>
>
> Ido & Olga
>
> Ido
> Levy/Haifa/IBM
> To
> 01/07/2008 kerberos@mit.edu
> 11:08 PM cc
>
> Subject
> SSO with telnet/rlogin/rsh
>
>
>
>
>
>
>
>
>
> Hello,
>
> I am trying to set up SSO in a Linux environment which has the following
> components up and running:.
>
> Kerberos 5
> LDAP
> Kerberized NFSv4 ( security flavor krb5 )
> Automount
>
> When using ssh everything works fine, tickets ( for both user and nfs ) are
> forward and when the user login to a machine both tickets are set.
> Unfortunately when using telnet/rlogin/rsh ( the ones that shipped with
> krb5-workstation ) the user login to the machine
> but fails to cd to his home directory which is automounted using kerberized
> ( kerberos 5 ) NFSv4.
> When issuing 'klist -5' just the user principal is presented and not the
> NFS principal.
>
> Does anyone successfully set SSO with telnet/rlogin/rsh in a kerberized
> NFSv4 environment when using automount.
>
> Thanks,
>
> Ido Levy
>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>