[krbdev.mit.edu #5712] Random issue reported by Kevin

[Kevin Koch via RT]

Jeff --

That was very helpful.  

Thanks.

Kevin 

-----Original Message-----
From: RT User,,,, [mailto:rt at MIT.EDU] On Behalf Of Jeffrey Altman via RT
Sent: Wednesday, September 05, 2007 7:29 PM
To: kpkoch at MIT.EDU
Subject: [krbdev.mit.edu #5712] Random issue reported by Kevin 

Debugging SecureCRT.exe.  Start Visual Studio devenv.exe or windbg.exe.
 Open SecureCRT.exe as the current project.  Open source file lshfunc.c
and place break points within acquire_tkt_no_princ().  

What this shows is that SecureCRT does not call gss_acquire_cred()
directly.  Instead it calls gss_init_sec_context() with
GSS_C_NO_CREDENTIAL.  This results in a call to gss_acquire_cred() with
desired_name equal to GSS_C_NO_CREDENTIAL which in turn calls
acquire_init_cred() with the same which results in a call to
krb5int_cc_default().

Now things get interesting.  krb5int_cc_default() loads leashw32.dll and
searches for the function pLeash_AcquireInitialTicketsIfNeeded() which
when called without a desired principal name checks the current default
ccache for a valid TGT and if not found queries NIM to prompt the user.
 The user can response with any principal name and NIM will return the
ccache name for the cache that holds the identity specified by the user.  

Once the ccache name is determined, the ccache name is stored in the
krb5_context.  The result is that subsequent changes to the default
ccache name in NIM (or manually in the registry) will not affect
SecureCRT until it is restarted.  The call to krb5_cc_set_default_name()
is performed within krb5int_cc_default().  

Next time you see a problem.  Attach a debugger to SecureCRT.exe and
debug what is happening.  Then you can file a report showing where the
actual problem is describing function calls and parameters.

As far as I can tell with SecureCRT 5.1 as downloaded from MIT, it is
working as designed.