Note: This is the second in a series of articles about troubleshooting authentication in View. The previous article in the series was: Troubleshooting smart card authentication using the Windows View Client.
When I get requests to troubleshoot single sign-on for a customer, the decision tree often is a bit complicated given the variety of Windows versions, protocols, and 3rd-party products we support. So I wanted to write a post about how I tend to troubleshoot single sign-on problems into a remote desktop.
The most important variables are: 1) protocol (e.g. RDP, PCoIP, or Local Mode), 2) authentication method (password, smart card, proximity card, or biometric), 3) remote desktop OS (with Vista, Microsoft significantly rewrote their authentication stack), and 4) whether any 3rd-party single sign-on products are installed in the remote desktop (e.g. Imprivata OneSign).
Third-party single sign-on products
When installing third-party SSO programs, we recommend that you install the 3rd-party product first then install the View Agent. On XP, this allows us to set up GINA chaining so our GINA is primary and the 3rd-party GINA is secondary. I am not aware of any 3rd-party GINA’s that we don’t work with; the only one that needs a little work is the Novell Client GINA when connecting over PCoIP (see VMware KB article 1025114 for more information). Note that in View 4.0, PCoIP SSO would fail when GINA chaining was enabled; this is fixed as of View 4.0.1 and later. On Vista and later, Imprivata recently fixed some issues they have so if you have a recent version of OneSign it should work fine side-by-side with our single sign-on functionality.
To verify that GINA chaining is set up correctly on XP remote desktops, open regedit on the Agent and navigate to the registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”. You should see a REG_SZ named “GinaDLL” that is set to the absolute path of our GINA, wsgina.dll. This means that the VMware View Agent’s GINA is the primary GINA, which is required. In that same registry key, you should see a REG_SZ named “VdmGinaChainDLL”, which should be set to the absolute path of the 3rd-party GINA that is also installed. With both of these registry values set correctly, this GINA chaining should cause VMware View’s SSO to work correctly and the 3rd-party software to function as well.
XP remote desktops
For XP remote desktops, our single sign-on functionality stays out of the way for most of the time. With PCoIP and Local Mode, it does the programmatic equivalent of setting the text of the username and password edit boxes and clicking the OK button. With RDP, it uses functionality built into Windows to provide the credentials directly to Windows. As a result, in all cases, the chance of problems here is pretty small.
One known issue is when connecting via RDP to XP remote desktops that have multiple vCPUs configured. There is a race condition here where single sign-on will occasionally fail. We will have a fix in our next release, but for now the only workaround you can provide is to change the VM to use only 1 vCPU or just use PCoIP instead of RDP. This issue is described more directly in the View 4.5 Release Notes.
If you aren’t running into the previously mentioned known issue and you configured 3rd-party software correctly (or don’t have any), there is no good reason for SSO to fail and it is best to work with VMware support to see if any of the components are not communicating correctly. In a case like this, submitting TRACE logs from the View Agent is important. You can also post questions to the VMware Forums.
Vista and Win7 remote desktops
For Vista and Win7 remote desktops, the single sign-on process is a bit more complicated. People tend to report issues in terms of “single sign-on isn’t working”, but there are many ways in which the failure could manifest. It is best to start with the question: when you connect to the remote desktop and single sign-on fails, what screen do you see?
If you see the “Press Ctrl+Alt+Delete to log on” screen
This means that a Windows policy is not set correctly. This problem can only happen in PCoIP connections and Local Mode desktops. When the desktop is launched, the View Agent signals a Ctrl+Alt+Del to start the login process but Windows must be configured to allow this to happen. The View Agent installer configures Windows to do this, but often times administrators will override this with a GPO and not realize that they did this. The registry value we set is: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\SoftwareSASGeneration and it is best to check that registry value in the problematic remote desktop to see what it is set to. The GPO that controls this registry value is named “Disable or enable software Secure Attention Sequence”. Our installer sets the registry value to 1 (corresponding to the Services option). This value is required to either be 1 (Services) or 3 (Services and Ease of Access Applications).
If you see a screen with tiles or one tile automatically selected
A tile corresponds to a method of authentication or a credential. You tend to have one tile per certificate on a smart card, one tile for the most recent password user, and one tile to provide a different password user. When connecting in this case, Windows may leave you at a screen with multiple tiles or it may automatically select the last tile and show you some username/password controls. Regardless, the causes for getting into this situation are the same.
One problem that could cause this is if you have “AllowSingleSignOn” GPO set to “false” and we didn’t try SSO. Another problem that could cause this (however only for PCoIP; RDP doesn’t have this requirement) is if you have the “Interactive logon: Do not require Ctrl+Alt+Del” GPO set to “Enabled”. We require that this GPO be disabled or not set, because our SSO code depends on our View Agent signaling a SSO after the connection.
But more likely, the issue depends on the method of authentication. If you did password authentication to the View Connection Server, the only real explanation here is that there was some sort of communication error in getting the credentials to our SSO components; VMware support or our forums could help you with this issue. If you did smart card authentication to the View Connection Server, then the most likely problem is that our SSO component couldn’t find the correct certificate on a smart card. Problems that could cause this would be: 1) you are using PCoIP but didn’t choose to install the “PCoIP Smart Card” option in the View Agent installer, 2) you are using Local Mode but didn’t install the Microsoft USB CCID driver that we require, 3) the smart card wasn’t completely inserted when SSO was being attempted in the remote desktop, or 4) you didn’t install the middleware your smart card requires on the remote desktop. If you want to get more info, open the View Agent log and search for the most recent occurrence of the string “GetSerialization”. Immediately after that, you will see some log lines that give information about the certificates that the SSO code found. They are in a format pretty similar to those described here in the section discussing “IsValidCertificate”.
If you see a “VMware SSO User” tile automatically selected
The other screen you may see when single sign-on fails is a screen that says “VMware SSO Tile” and only has as Cancel button. If you see this, it means that our single sign-on failed for some reason, but there is no general guidance I can give here. You would want to post a question on the Forums with info about what you are seeing.
