Change NIM startup behavior?

[Jeffrey Altman]

Kevin:

As far as Asanka and I are aware, the patches I committed address the
issue.  At least the patches address the issue with the applications
that we have experienced the problem with at other institutions.  In
particular, Oracle Calendar.

The problem is really not with NIM but with the application that is
calling the GSS-API from within their own Message Queue thread.  We are
considering replacing the use of Window Messages for communication
between the GSS-API library and NIM with another technique.  As part of
adding support for Google Desktop's Gadgets and Vista's Widgets we need
to add support for COM.  Therefore, we can support Windows automation. 
Doing so provides an alternative method of communicating with NIM that
does not require the use of Window Messages and won't be susceptible to
the blocking of the Message Queue by the application *unless* they load
the GSS-API library on demand from within the Message Queue.  If that is
the case, there really won't be anything we can do.  There are limits to
what can be done to work around bugs in applications that violate the
Windows programming model.

It is true that if NIM displays a window at the top z-level, the next
time a window of the same class is displayed by NIM it will be given the
same z-level it had before.  This is why prompting for credentials at
NIM startup can be viewed as a work around.  If MIT wants the default
behavior of KFW 3.2 to be "prompt for credentials at startup",  MIT can
add the appropriate registry values to MIT's KFW transform to do that.  
There are no code changes required to make this happen.

Using the "-a" command line option is not the way to make this happen. 
The correct way to do this would be to set the Registry Value that is
defined for this purpose.  Please see the KFW 3.2 Release Notes.

Jeffrey Altman
Secure Endpoints Inc.



Kevin Koch wrote:
> There have been reports of the NIM password prompt dialog appearing
> underneath the kerberized application window.  
>
>  
>
> The password prompt dialog appears underneath rather than on top of the app
> window the first time the prompt dialog is displayed after a reboot.  After
> that, my observation is that the prompt dialog appears on top.  Can someone
> else confirm this?
>
>  
>
> This behavior is unchanged when KfW 3.2.0 is built with the updated
> newcredwnd.*.
>
>  
>
> When I tested run the same test with KfW 2.6.5 on the same XP machine,
> freshly rebooted:
>
>     On login, KfW 2.6.5 prompts for a password.  KfW 3.2.* does not.  I
> cancel out of it.
>
>     When the 1st kerberized app is run, the password prompt dialog displays
> on top of the app window.  
>
>  
>
> Setting
> HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\NetIDMgr to
> "netidmgr -a" and rebooting, NetIdMgr prompts for a password at login time,
> like KfW 2.6.5.  I cancel out of the password prompt.  Then when kerberized
> apps need a password, the password prompt dialog appears on top.
>
>  
>
> So the KfW 2.6.5 behavior causes a spurious NetIdMgr/password prompt at
> login time but corrects the 'pop-under' problem.
>
>  
>
> I think the NetIdMgr display at login time is less evil than the pop-under
> behavior and should be the behavior of MIT Kerberos 3.2.0.
>
>  
>
> What do you think?
>
>  
>
> Kevin
>
>  
>
> _______________________________________________
> kfwdev mailing list
> kfwdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kfwdev
-------------- 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/kfwdev/attachments/20070703/18bad7b3/attachment.bin