Fw: SSO with telnet/rlogin/rsh

[Douglas E. Engert]

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.
> 

 From a Kerberos prospective both could be correct. Using the process ID as
part of the cache name allows for session based credentials, so each telnet
session has its own cache. The telnetd should have alos set the KRB5CCNAME to point
at the cache. The Kerberos libraries us the KRB5CCNAME to locat the caceh.
The cache is then not affected if the default or user based cache
(i.e. using the uid as part of the name) is destroyed in another session.

This also allows for the use of different credentials by different session
even while using the local UID.


> 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 at 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

So its the rpc.gssd that is not using the KRB5CCNAME to find the session based cache.

Its a shame that NFSv4 did not look closer at how OSF DCE addressed this
isssue many years ago. DCE stored the session based cache in a tmp
directory and added a PAG number to the file name. Something like
/opt/dce/local/security/cache/krb5cc_dcecreds_<PAG>
The PAG  was also stored in the kernel in the creds structure, and
thus available to each process of a session.

On AIX the PAG was also shared with the Transarc AFS. PAGs are still used
today with OpenAFS.

> 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 at 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444