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:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 3:26 AM To: Paul B. Hill Cc: [email protected] 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" <[EMAIL PROTECTED]> 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
