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.
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
