Environment
Novell Client for Windows 2000/XP/2003 4.91 Login
Situation
The "Remote Desktop" feature introduced with Microsoft Windows XP and
Windows Server 2003 requires support from the installed Windows GINA
(e.g. MSGINA.DLL, NWGINA.DLL, etc.) in order to behave in an expected
and correct manner when a Remote Desktop operation is being performed.
Prior to the Novell Client 4.91 for Windows, Novell's NWGINA.DLL did not contain any Remote Desktop-specific handling or awareness. This lead to observations of "the screen goes blank for a while, and then the Novell login dialog appears again" and "the Novell login dialog appears two or even three times in the course of a Remote Desktop operation".
Remote Desktop to Windows 2003 or Windows XP prompts twice for NetWare login - TID10093130
Prior to the Novell Client 4.91 for Windows, Novell's NWGINA.DLL did not contain any Remote Desktop-specific handling or awareness. This lead to observations of "the screen goes blank for a while, and then the Novell login dialog appears again" and "the Novell login dialog appears two or even three times in the course of a Remote Desktop operation".
Remote Desktop to Windows 2003 or Windows XP prompts twice for NetWare login - TID10093130
Resolution
Windows XP Professional and Remote Desktop
In Novell Client 4.91 for Windows, Novell implemented the GINA-level support for Remote Desktop. The intended and designed operation of the Novell Client 4.91 in conjunction with Remote Desktop on Windows XP Professional is as follows:
If there isn't a user currently logged on at the physical console, initiating a Remote Desktop terminal connection will display the "normal" Novell login dialog permitting login to both NDS and Windows. Whether or not the Remote Desktop session will be allowed depends upon the Windows credentials provided (and the Windows user accounts assigned to have Remote Desktop permission). i.e. Login will fail, even if correct credentials are provided, if the Windows user account specified is not among the accounts permitted to use Remote Desktop.
Once the Remote Desktop session has successfully logged in, at the physical console of the Windows machine the Novell login dialog will change to a Remote Desktop-specific Novell dialog indicating that Remote Desktop is in use and prompting for (only) Windows credentials if someone at the physical console wants to initiate bringing the console session back to the physical console.
This occurs because entering credentials at the physical console (while the Remote Desktop terminal session is logged in) now performs an operation similar to "unlocking a locked workstation". The credentials being provided are not for attempting a new login, but rather are being evaluated for whether the Windows account has permission to take over (i.e. see all the currently running applications and data) the console session, or whether they have permission to force the existing console session to logout (i.e. force all applications to close and forcibly log the current user out of the console session such that the console session can be used by someone else).
If the Remote Desktop terminal session logs out (i.e. shut down all applications and logoff), the Novell dialog at the physical console will switch back from the Remote Desktop-specific dialog to being the "normal" Novell login dialog permitting login to both NDS and Windows.
This occurs because providing credentials is no longer an attempt to "take over the existing logged-in session". At this point no one is currently logged in and using the console session, so the Novell login dialog is now no different than for any other workstation where no one is currently logged on.
For everything just described, "the reverse" is also true. Meaning if someone is currently logged on at the physical console, initiating a Remote Desktop connection will end up seeing the Remote Desktop-specific Novell dialog indicating that the console session is currently in use and prompting for (only) Windows credentials if the Remote Desktop user wants to attempt "taking over" or "forcing logoff" of the existing console session.
Windows Server 2003 and Remote Desktop
Note that all of the above description is being made specifically for Windows XP Professional. Windows Server 2003, because it can be supporting multi-user terminal services at the same time as Remote Desktop, is handled slightly differently.
If a Remote Desktop terminal connection is initiated while the console session is currently in use, instead of seeing the Remote Desktop-specific Novell dialog indicating that the console session is in use and prompting for (only) Windows credentials, the Remote Desktop terminal connection sees the "normal" Novell login dialog permitting entry of both NDS and Windows credentials.
The reason for this is because the way Remote Desktop is implemented on Windows Server 2003, the GINA does not know whether the terminal connection is being initiated for Remote Desktop (e.g. "MSTSC.EXE /CONSOLE") or as a normal multi-user Terminal Services session (e.g. "MSTSC.EXE" without the /CONSOLE parameter).
As such, the Novell Client is left to always prompt for both NDS and Windows credentials, even knowing that if the current terminal connection is actually initiated for Remote Desktop, the NDS login and credentials will end up being discarded in this scenario of someone being currently logged in on the console session.
Note that on the Windows Server 2003 machine's physical console (as opposed to the Remote Desktop-initiated terminal connection), you will see the Remote Desktop-specific Novell dialog indicating that the a Remote Desktop is in use and prompting for (only) Windows credentials to either take the console session back or force the existing user to log out of the console session.
Frequently Asked Questions
"Why can't the Novell Client prompt for NDS credentials when someone is currently using the console session? The Novell Client is able to use NDS credentials for unlocking the workstation, so why not Remote Desktop, too?"
For simply "unlocking a locked workstation", the NDS credentials are indeed used if specified/selected. But "unlocking the workstation" versus "Remote Desktop taking over an existing console session" are unfortunately two very different operations.
In the case of unlocking the workstation, Windows (WINLOGON.EXE, specifically) asks the GINA to determine whether the unlock should be allowed or not allowed and/or whether the existing user session should be forced to logout. So a third party GINA like Novell's NWGINA.DLL is free to make this determination based upon NDS credentials or anything the third-party GINA deems appropriate and secure.
In the case of Remote Desktop taking over an existing session, the way Windows implements Remote Desktop leaves Windows (WINLOGON.EXE) itself to make the determination of whether the user attempting the operation should be permitted to "take over" the console session or force the existing session to logoff. And when Windows makes this determination, it does so based purely on the Windows account credentials specified.
For Remote Desktop, a third party GINA isn't inherently able to "pass" or "fail" this Remote Desktop determination due to its own criteria or credentials other than Windows credentials, as is the case for "unlocking the workstation".
Although the older Novell Clients without Remote Desktop awareness actually did prompt for both NDS and Windows credentials in this scenario, only the Windows credentials were actually used. Keep in mind, for the scenario of "someone is currently logged on in the console session", there isn't a new NDS login that needs to be performed. The outcome of this scenario is either (a) the Remote Desktop user is able to "take over" the existing session with its existing NDS login, or (b) the Remote Desktop user is able to force logoff of the console session, meaning the console session is going to return to a completely logged-out state.
The older Novell Clients without Remote Desktop awareness would prompt for NDS credentials and would perform a new, additional NDS login that in fact was immediately discarded because it was not necessary nor was it used. The fact that an additional NDS login was performed (even though it was later discarded) could still conspire to create concurrent connection limit issues and similar due to the additional and unnecessary NDS login that had occurred.
"Why does the Novell Client 4.91 and later fail to work as expected on Windows XP Professional in conjunction with third-party products such as ThinSoft Inc.'s WinConnect XP?"
Please see the discussion on this question in the following document:
Novell Client 4.91 not working as desired with WinConnect
In Novell Client 4.91 for Windows, Novell implemented the GINA-level support for Remote Desktop. The intended and designed operation of the Novell Client 4.91 in conjunction with Remote Desktop on Windows XP Professional is as follows:
If there isn't a user currently logged on at the physical console, initiating a Remote Desktop terminal connection will display the "normal" Novell login dialog permitting login to both NDS and Windows. Whether or not the Remote Desktop session will be allowed depends upon the Windows credentials provided (and the Windows user accounts assigned to have Remote Desktop permission). i.e. Login will fail, even if correct credentials are provided, if the Windows user account specified is not among the accounts permitted to use Remote Desktop.
Once the Remote Desktop session has successfully logged in, at the physical console of the Windows machine the Novell login dialog will change to a Remote Desktop-specific Novell dialog indicating that Remote Desktop is in use and prompting for (only) Windows credentials if someone at the physical console wants to initiate bringing the console session back to the physical console.
This occurs because entering credentials at the physical console (while the Remote Desktop terminal session is logged in) now performs an operation similar to "unlocking a locked workstation". The credentials being provided are not for attempting a new login, but rather are being evaluated for whether the Windows account has permission to take over (i.e. see all the currently running applications and data) the console session, or whether they have permission to force the existing console session to logout (i.e. force all applications to close and forcibly log the current user out of the console session such that the console session can be used by someone else).
If the Remote Desktop terminal session logs out (i.e. shut down all applications and logoff), the Novell dialog at the physical console will switch back from the Remote Desktop-specific dialog to being the "normal" Novell login dialog permitting login to both NDS and Windows.
This occurs because providing credentials is no longer an attempt to "take over the existing logged-in session". At this point no one is currently logged in and using the console session, so the Novell login dialog is now no different than for any other workstation where no one is currently logged on.
For everything just described, "the reverse" is also true. Meaning if someone is currently logged on at the physical console, initiating a Remote Desktop connection will end up seeing the Remote Desktop-specific Novell dialog indicating that the console session is currently in use and prompting for (only) Windows credentials if the Remote Desktop user wants to attempt "taking over" or "forcing logoff" of the existing console session.
Windows Server 2003 and Remote Desktop
Note that all of the above description is being made specifically for Windows XP Professional. Windows Server 2003, because it can be supporting multi-user terminal services at the same time as Remote Desktop, is handled slightly differently.
If a Remote Desktop terminal connection is initiated while the console session is currently in use, instead of seeing the Remote Desktop-specific Novell dialog indicating that the console session is in use and prompting for (only) Windows credentials, the Remote Desktop terminal connection sees the "normal" Novell login dialog permitting entry of both NDS and Windows credentials.
The reason for this is because the way Remote Desktop is implemented on Windows Server 2003, the GINA does not know whether the terminal connection is being initiated for Remote Desktop (e.g. "MSTSC.EXE /CONSOLE") or as a normal multi-user Terminal Services session (e.g. "MSTSC.EXE" without the /CONSOLE parameter).
As such, the Novell Client is left to always prompt for both NDS and Windows credentials, even knowing that if the current terminal connection is actually initiated for Remote Desktop, the NDS login and credentials will end up being discarded in this scenario of someone being currently logged in on the console session.
Note that on the Windows Server 2003 machine's physical console (as opposed to the Remote Desktop-initiated terminal connection), you will see the Remote Desktop-specific Novell dialog indicating that the a Remote Desktop is in use and prompting for (only) Windows credentials to either take the console session back or force the existing user to log out of the console session.
Frequently Asked Questions
"Why can't the Novell Client prompt for NDS credentials when someone is currently using the console session? The Novell Client is able to use NDS credentials for unlocking the workstation, so why not Remote Desktop, too?"
For simply "unlocking a locked workstation", the NDS credentials are indeed used if specified/selected. But "unlocking the workstation" versus "Remote Desktop taking over an existing console session" are unfortunately two very different operations.
In the case of unlocking the workstation, Windows (WINLOGON.EXE, specifically) asks the GINA to determine whether the unlock should be allowed or not allowed and/or whether the existing user session should be forced to logout. So a third party GINA like Novell's NWGINA.DLL is free to make this determination based upon NDS credentials or anything the third-party GINA deems appropriate and secure.
In the case of Remote Desktop taking over an existing session, the way Windows implements Remote Desktop leaves Windows (WINLOGON.EXE) itself to make the determination of whether the user attempting the operation should be permitted to "take over" the console session or force the existing session to logoff. And when Windows makes this determination, it does so based purely on the Windows account credentials specified.
For Remote Desktop, a third party GINA isn't inherently able to "pass" or "fail" this Remote Desktop determination due to its own criteria or credentials other than Windows credentials, as is the case for "unlocking the workstation".
Although the older Novell Clients without Remote Desktop awareness actually did prompt for both NDS and Windows credentials in this scenario, only the Windows credentials were actually used. Keep in mind, for the scenario of "someone is currently logged on in the console session", there isn't a new NDS login that needs to be performed. The outcome of this scenario is either (a) the Remote Desktop user is able to "take over" the existing session with its existing NDS login, or (b) the Remote Desktop user is able to force logoff of the console session, meaning the console session is going to return to a completely logged-out state.
The older Novell Clients without Remote Desktop awareness would prompt for NDS credentials and would perform a new, additional NDS login that in fact was immediately discarded because it was not necessary nor was it used. The fact that an additional NDS login was performed (even though it was later discarded) could still conspire to create concurrent connection limit issues and similar due to the additional and unnecessary NDS login that had occurred.
"Why does the Novell Client 4.91 and later fail to work as expected on Windows XP Professional in conjunction with third-party products such as ThinSoft Inc.'s WinConnect XP?"
Please see the discussion on this question in the following document:
Novell Client 4.91 not working as desired with WinConnect
Additional Information
Optional post-4.91 SP4 changes to the Remote Desktop behavior of the Novell Client:
To better accommodate customer scenarios where the Windows credentials necessary for Remote Desktop-specific operations are perhaps unknown to the interactive user, an optional Remote Desktop behavior policy was added in post-Novell Client 4.91 SP4 updates. Specifically LOGINW32.DLL v4.19.3 10APR2008 or later and NWGINA.DLL v4.91.4.17 10APR2008 or later.
The new optional registry-based policy defined by these updates is as follows:
[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\NWGINA\Login Screen]
"RemoteDesktopInUseDialog"=dword:00000000
"RemoteDesktopInUseDialog"=dword:00000001
If this policy is not defined in the registry, or if the "RemoteDesktopInUseDialog" value is set to 0x00000001, the behavior of the Novell Client in Remote Desktop-specific scenarios is exactly as described earlier in this document. i.e. The Novell Client's NWGINA.DLL will prompt the interactive user for Windows credentials only, since Windows credentials are all that Windows itself is going to consider when determining whether the Remote Desktop operation will be permitted or not.
If the "RemoteDesktopInUseDialog" policy is defined with a value of 0x00000000, then the Novell Client will present "the normal Novell Client login dialog" even in Remote Desktop-specific scenarios. Doing so will allow for the interactive user to be prompted for eDirectory credentials, in addition to Windows credentials, during Remote Desktop-specific operations.
All of the caveats previously described in this document still apply. Meaning if the "RemoteDesktopInUseDialog" policy is defined to prompt for eDirectory credentials during Remote Desktop, this still will cause an additional eDirectory authentication to be performed, may cause issues in environments that have concurrent connection limitations, and ultimately the additional eDirectory authentication that occurs will become immediately discarded.
Optionally allowing eDirectory credentials to be used even during Remote Desktop-specific operations accommodates situations where the eDirectory credentials had been the only credentials that the interactive user knew.
Specifically in NMAS non-password-based eDirectory logon methods, where the Windows account password was stored by Novell Single Sign-On and not necessarily known to the user. Or Novell ZENworks Dynamic Local User (DLU), where the eDirectory-based ZENworks policy dictated the credentials that were subsequently used for the Windows account logon, and may never have been known by the interactive user.
Formerly TID # 10099800
To better accommodate customer scenarios where the Windows credentials necessary for Remote Desktop-specific operations are perhaps unknown to the interactive user, an optional Remote Desktop behavior policy was added in post-Novell Client 4.91 SP4 updates. Specifically LOGINW32.DLL v4.19.3 10APR2008 or later and NWGINA.DLL v4.91.4.17 10APR2008 or later.
The new optional registry-based policy defined by these updates is as follows:
[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\NWGINA\Login Screen]
"RemoteDesktopInUseDialog"=dword:00000000
"RemoteDesktopInUseDialog"=dword:00000001
If this policy is not defined in the registry, or if the "RemoteDesktopInUseDialog" value is set to 0x00000001, the behavior of the Novell Client in Remote Desktop-specific scenarios is exactly as described earlier in this document. i.e. The Novell Client's NWGINA.DLL will prompt the interactive user for Windows credentials only, since Windows credentials are all that Windows itself is going to consider when determining whether the Remote Desktop operation will be permitted or not.
If the "RemoteDesktopInUseDialog" policy is defined with a value of 0x00000000, then the Novell Client will present "the normal Novell Client login dialog" even in Remote Desktop-specific scenarios. Doing so will allow for the interactive user to be prompted for eDirectory credentials, in addition to Windows credentials, during Remote Desktop-specific operations.
All of the caveats previously described in this document still apply. Meaning if the "RemoteDesktopInUseDialog" policy is defined to prompt for eDirectory credentials during Remote Desktop, this still will cause an additional eDirectory authentication to be performed, may cause issues in environments that have concurrent connection limitations, and ultimately the additional eDirectory authentication that occurs will become immediately discarded.
Optionally allowing eDirectory credentials to be used even during Remote Desktop-specific operations accommodates situations where the eDirectory credentials had been the only credentials that the interactive user knew.
Specifically in NMAS non-password-based eDirectory logon methods, where the Windows account password was stored by Novell Single Sign-On and not necessarily known to the user. Or Novell ZENworks Dynamic Local User (DLU), where the eDirectory-based ZENworks policy dictated the credentials that were subsequently used for the Windows account logon, and may never have been known by the interactive user.
Formerly TID # 10099800