[krbdev.mit.edu #5712]

[Jeffrey Altman via RT]

Kevin Koch via RT wrote:
> NIM was built from the trunk on 9/4/2007 to verify that previously 
> reported bugs were still fixed after a hack was replaced with a real 
> solution.
> 
> During testing, a new problem was observed when using SecureCRT and an 
> open NIM GUI.
> 
> Several identities were defined; only one is legitimate for connecting 
> to Athena.
> 
> When modifying an identity, it would always pop to the top of the list 
> in the Basic view.  Then SecureCRT would attempt to connect using 
> topmost identity instead of using the default identity.  Even though 
> the topmost identity and the default identity had valid credentials, 
> NIM would prompt for a password for the topmost identity.
> 
> Attempts to reproduce the problem from a freshly rebooted virtual 
> machine or host XP PC failed, even though the host PC was rebooted 
> after the newly built NIM was installed.

It would be useful if you would debug the problem instead of reporting
symptoms viewed from 10,000ft.  You still have an open SecureCRT ticket.
(RT 5603) You haven't described how SecureCRT is interacting with
Kerberos and NIM.  Its obviously making a gssapi call or it could be
manipulating the credential cache configuration.  Which is it?

If its making a gssapi call, is it requesting a specific identity or
asking for the identity in the default ccache?

If its manipulating the ccache, is it changing the default ccname?

What do you mean by "modifying an identity"?  This is an extremely
ambiguous statement.  The default identity is listed first in the view
so if the ccache is "default", then it will be first.