SSPI not populating Microsoft Kerberos cache

Paul B. Hill pbh at MIT.EDU
Tue Mar 28 11:08:31 EST 2006

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


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

  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?


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

>2) User has done a NTLM login to the workstation:
>    In this case, the application client takes user principal name
>kerberos password as input and makes the SSPI calls. SSPI calls
>TGT and service ticket from the  MIT KDC and the calls succeed and
>application works. But neither the TGT nor the Service Ticket is
>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
cannot query the cache. If you do subsequent SSPI operations you should
able to verify that the TGT is being cached by using a network monitor
(Ethereal) to examine the traffic. 


More information about the Kerberos mailing list