Ticket History #5608: NIM password prompt appears under application window

NIM from either MIT KfW Beta 2 or from secure-
endpoints.com/binaries/mit-kfw-3-2-0/kfw-3-2-0.msi.

Vista or XP.


Scenario:

NIM GUI displayed.

Default identity credentials deleted or expired.

Kerberized application needs to authenticate.

The NIM password prompt dialog appears within the screen real estate
of the NIM GUI and underneath any application window that overlaps the
same space. If the application window covers the NIM GUI, then the
password prompt dialog will not be seen and it will appear that the
application has hung.

This has been discussed extensively on the mailing list.

The problem in this case is that the application is calling the gssapi
from its own Windows Message Handling thread. This blocks the
application from processing the Window messages that would otherwise
result in the application giving up its foreground window status.

Since the NIM obtain new credentials dialog is displayed at its last
known z-level and that z-level is below the application window and the
application isn't processing its Window messages, the NIM dialog cannot
move itself to the foreground. Instead what is done post kfw 3.2 is the
user's attention is requested by flashing the NIM dialog's button on the
task bar. (ticket 5584 - src/windows/identity/ui/newcredwnd.c rev 15)

Note that by default we do not want to force the NIM dialog to always be
"topmost". Doing so would mean that a non-foreground application could
trigger a NIM dialog that would be forced upon the user. Think of an
e-mail application running in the background that queries for mail every
30 minutes. If the user isn't actively reading her mail, she should not
be forced to deal with the NIM dialog *now*.

Still, we understand that there are broken applications out there such
as Oracle Calendar which do perform actions that take lots of time (and
perhaps block) from within the Window Message Thread. These
applications violate the Windows programming guidelines. Organizations
that use them should file complaints with the developers. In the
meantime, the only work around is to force the NIM dialog to be
"topmost". Post kfw 3.2 forcing the dialog to be "topmost" will be
performed when the NIM registry value "ForceToTop" DWORD is non-zero
[Key: CredWindow\Windows\NewCred]. (ticket 5584 -
src/windows/identity/ui/newcredwnd.c rev 15)

If MIT wants this behavior it can obtain it by building with the patch
and adding the necessary registry value to the MSI transform.

Jeffrey Altman