Using the MSLSA krb5_ccache type with a non-Microsoft KDC

[Jeffrey Altman]

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?

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