Using the MSLSA krb5_ccache type with a non-Microsoft KDC

[Douglas E. Engert]

Jeffrey Altman wrote:
> 
> The initial purpose of implementing the MSLSA krb5_ccache type was to
> attempt to pursuade the authors of various tools which have been copying
> the original ms2mit.c source code to stop doing so.  That code while it
> worked well on Windows 2000 when run immediately after logon would have
> a tendency to return expired tickets or fail in environments which did
> not support DES-CBC-CRC.  By implementing the ability to read the contents
> of the MSLSA cache via the krb5_ccache api it is possible to re-implement
> the ms2mit.c functionality in six lines of code while allowing the krb5
> library to hide the various weird details.
> 
> The work which was committed last night allows the MSLSA ccache to be
> leveraged to provide transparent support for obtaining credentials
> using the principal associated with the Logon Session.
> 
> If you have thoughts on how AcquireCredentialsHandle() could be used
> to instantiate a new LSA cache please let me know.  The krb5_ccache
> api has no knowledge of usernames or passwords or hardware tokens.  All
> it knows about are ccache types, ccache names, and the ability to
> request/read a credential or store a credential.
> 
> Besides, if you are using the MIT krb5 api, I do not see the benefit
> for using the LSA for non-Logon Session principals.  Under what
> circumstances
> would it benefit you to do so?

A personal workstation at home, to access AFS, or use kx509 for example.
The machine does not have to have a principal. 

The gssklog for example today, will use either the gssapi32.dll or 
the SSPI. It uses LoadLibrary("gssapi32.dll"); So it can be run on a 
system with or without the Kerberos package present.  It can get the 
credentials via the gss_acquire_cred from Kerberos, or via the SSPI 
AcquireCredentialsHandle or if needed use the SSPI 
AcquireCredentialsHandle with the AuthIdentity. 

So for AFS purposes, it can look like the old klog, with a
user and password, or it can look like aklog where it uses the
available credentials either via Kerberos or Windows. 

What I am suggesting is that it might be possible to have kinit
(or leash) pass in a userid and password to the AcquireCredentialsHandle
via the AuthIdentity and get the first TGT. But I have not checked
if when the AuthIdentity is used, are the credentials available
to other applications. 


> Jeffrey Altman
> 
> Douglas E. Engert wrote:
> 
> >Thanks for the nice write up.
> >
> >Yes I do that all the time, and can use either an AD realm, or an
> >MIT based realm.
> >
> >May comments, questions may have been addressing to situation where
> >the SSPI/LSA will let you provide a userid and password
> >on the AuthIdentity parameter to the AcquireCredentialsHandle
> >but this gives you a local set of credentials I don't think you can
> >use these outside the application. If you can, this could
> >be used for kinit too. I think this is what the runas command is using.
> >
> >So my original comments/questions maybe outside the scope of what
> >you where supporting in the modification.
> >
> >I was using the feature with gssklog, msklog, and kx509 if the
> >user was on a machine not in a domain, and needed credentials
> >after logging in locally.
> >
> >
> >

-- 

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