MSLSA krb5_ccache: please let me know if this is a bad idea

[Douglas E. Engert]

Jeff, 
This sounds like I good idea, and I see you have committed a change 
last night. 

Since the LSA will not be using the krb5.ini file, are there other
requirements such as running the MS ksetup command so it matches what's
in the krb5.ini? 

>From some tests I had done for msklog using the LSA on a machine 
which is not a member of the domain or any domain, to get a TGT for 
a user who is in a domain, the LSA would use LDAP to do some lookup, 
as well as port 88 to get the TGT. Whereas the MIT kinit only needed
port 88. This has firewall implications. 

If the KDC was not an MS AD, the LSA would need to have the ksetup 
run to add the realm and kdc names. 

There are surely other combinations of KDCs, DNS registration of the
realm and KDCs, which might need to be spelled out as well.
   



Jeffrey Altman wrote:
> 
> Ticket 2049 <https://krbdev.mit.edu/rt/Ticket/Display.html?id=2049>
> describes the
> addition of a new krb5_ccache type, MSLSA, which provides read-only
> access to the
> Microsoft LSA Kerberos cache via the krb5_ccache api.  This
> implementation was
> primarily meant for use by applications which desired ms2mit.exe
> functionality
> to reduce the large amount (800+ lines) of esoteric code which was
> required to
> obtain a TGT.
> 
> It is not possible to make the Microsoft LSA Kerberos cache writable but
> it occurred
> to me that it might be possible to fake it.  So please tell me if this
> is a horrible
> idea.  There is nothing I can do to implement the krb5_cc_initialize() or
> krb5_cc_generate_new() functions so lets ignore them.  However, for the
> krb5_cc_store()
> function we can attempt the following trick:
> 
>     * obtain the service principal, flags and encryption type from the
>       creds to be stored
>     * instead of storing the cred, request the Kerberos LSA to obtain a
>       new cred using the extracted parameters
> 
> The end result will be that the MSLSA krb5_ccache will contain a service
> ticket for the next time an application requests one.  However, the
> session key will be different in the stored ticket from the one which
> was used by the application.  Instead of returning KRB5_OK or
> KRB5_CC_READONLY, I would suggest a new error code KRB5_CC_NEWCRED.
> 
> So what do you think?
> 
> Thanks
> 
> - Jeff
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

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