kfw 2.6.5 vs. 3.2.1 leash/NIM

[Jeffrey Altman]

Paul Palacios wrote:
> Is NIM a replacement for leash, but either could be used? My upgrade 
> seemed to behave contrary to that premise.
NIM is a replacement for Leash. 

However the way the code is written, if the NIM Window class is
registered, the
request for credentials will be sent to NIM.  Otherwise, the Leash
Window class
will be searched for and the request will be sent to Leash.
> We have client applications that were written to use gssapi. All works 
> fine (under nt4/xp/w2k/2003), but upgraded to 3.2.1. Under 2.6.5 if the 
> cache does not have a tgt, leash would prompt the user for user/pwd. 
> Under 3.2.1, it seems that leash does not prompt under the same 
> conditions. If the user explicitly selects 'get tickets' menu item in 
> leash, the user is prompted and GSS auth process continues and works fine.
>
> When NIM is used instead of leash (under the same conditions), NIM does 
> prompt for usr/pwd, but the whole GSS authentication process appears 
> hung and does not complete.
GSS blocks while waiting for NIM to respond to the request for
credentials.   Do you
know whether the gss_acquire_creds() call is blocked or did it return
and get stuck
somewhere else?

Does gss_acquire_creds() get called with or without a desired name?
> But, if both leash and NIM are running (and no tgt in cache), then NIM 
> will prompt for usr/pwd, the tickets then become visible in both leash 
> and NIM, and the whole GSS authentication process continues just fine. 
> Are both actually needed?
There should be no requirement that Leash be installed.  In fact, I do
not understand how
Leash would be involved in this scenario.
> Additional notes...
>
> The above seems to be consistent, whether it is the very first time NIM 
> is ran (no previously saved identity), or subsequent launch.  Also, on a 
> few of the tests where NIM prompted for usr/pwd, usr/pwd was entered, 
> tickets were obtained, but the dialog box (for usr/pwd) just grayed-out, 
> remained on screen and could not be closed. All the above testing was 
> under xp.
This seems to indicate that NIM is not completing the ticket acquisition
process and
is therefore not returning the response to the application that called
gss_acquire_creds().

After NIM obtains the credentials required by the identity provider, it
then attempts to
acquire the credentials configured for the identity for other installed
credential providers. 
Shipping with NIM is the Kerberos v4 credential provider.  Do you see
the same behavior
if you disable the Kerberos v4 credential provider?
>
> Any insight as to what may be going on and what should be expected would 
> be greatly appreciated. Thank you in advance.
Jeffrey Altman
Secure Endpoints Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20070901/d3a636f3/attachment.bin