get_cred starting realm
jaltman at secure-endpoints.com
Thu Apr 30 00:11:12 EDT 2015
On 4/29/2015 1:01 PM, Benjamin Kaduk wrote:
> On Wed, 29 Apr 2015, Nico Williams wrote:
>> We know at least one ccache type with non-deterministic iteration order:
>> MSLSA. (Though it may not permit insertion.)
> The LSA itself permits insertion; our MSLSA interface to it may not be
> quite so generous, though I don't remember offhand.
The LSA Kerberos functions do have some caching properties but they are
primarily not a credential cache. The LSA Kerberos functions are a
service ticket fetching API. The MSLSA krb5_ccache implementation is a
wrapper for the Microsoft Kerberos implementation that permit
applications built against MIT's Kerberos and GSS libraries to make use
of the Microsoft Kerberos implementation without source code changes.
If the Microsoft Kerberos implementation is unable to obtain the
requested ticket, then the MIT krb5 library will attempt to obtain one
itself. The ability to submit the resulting ticket (if any) to the LSA
and retrieve it again is dependent upon:
* how the MSLSA shim was built
* the OS version and SKU
The contents of the LSA can be destroyed at any point by any application
and as a result of a screen unlock.
In addition, the MSLSA can appear to store credentials for multiple
client principals. The application visible contents are not all from
the same store. The view of the application is actually a mashup of
three different credential stores (two of which the application cannot
alter) and the store that user application can alter can be masked by
the contents of the other two.
As a result I do not consider storing hints in the LSA to be stable or
reliable. When using the LSA non-Microsoft hints IMHO should be stored
outside the LSA.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20150430/93c39242/attachment.bin
More information about the krbdev