SSPI not populating Microsoft Kerberos cache

[Paul B. Hill]

Hi Gokul,

When the initial workstation logon is done using NTLM and applications
subsequently use SSPI to perform Kerberos authentication, the TGT will be
process. Other SSPI applications will not be able to share the common TGT.

I have not verified this information myself, but I trust the source of the
information.

Paul

-----Original Message-----
From: K.G. Gokulavasan [mailto:kgokulavasan at novell.com] 
Sent: Tuesday, March 28, 2006 3:26 AM
To: Paul B. Hill
Cc: kerberos at mit.edu
Subject: RE: SSPI not populating Microsoft Kerberos cache

Hi,
  Thanks Paul for your reply. Where does the SSPI stores the TGT? In
its process memory or in a shared memory? I am just thinking whether any
other application can use this cached ticket? So after our kerberised
application authentication, if some other kerberized application tries
to authenticate the same user principal using SSPI(using the same calls
AcquireCredentialsHandle and InitializeSecurityContext), then whether
the cached TGT will be used by SSPI to get the service ticket?

Regards,
 Gokul.

>>> "Paul B. Hill" <pbh at MIT.EDU> 3/28/06 2:04 AM >>>
Hi,

>2) User has done a NTLM login to the workstation:
>    In this case, the application client takes user principal name
and
>kerberos password as input and makes the SSPI calls. SSPI calls
acquires
>TGT and service ticket from the  MIT KDC and the calls succeed and
>application works. But neither the TGT nor the Service Ticket is
present
>in Microsoft kerberos cache.
>
>   So how to cache the TGT using SSPI call? Do we have to make any
>other calls to populate the cache?

I am told that in this case SSPI is caching the TGT, but in this case
you
cannot query the cache. If you do subsequent SSPI operations you should
be
able to verify that the TGT is being cached by using a network monitor
(Ethereal) to examine the traffic. 

Paul