I will occasionally get requests from people to help them troubleshoot smart card authentication to the View Connection Server in a setup that just doesn’t seem to work. This will often manifest by connecting the View Client to the server and not being prompted for your PIN. Instead you are taken to the username/password dialog or see an error dialog saying “Smart card or certificate authentication is required.” This blog post will help you troubleshoot situations like these using the Windows View Client 4.0 or later.
The first step is to enable TRACE logging on the View Client and reproduce the authentication failure. To enable TRACE logging, open “regedit” and navigate to HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM. If you are on 64-bit Windows, navigate to HKEY_LOCAL_MACHINE\Software\Wow6432Node\VMware, Inc.\VMware VDM. In this registry key, create a new REG_SZ value with Name “TraceEnabled” and Data “true”. After you have set this, launch the View Client, reproduce your failure, and note the exact time that you hit Connect.
Now you need to find the most recent debug log detailing this failure. On Windows XP, the directory to find this in is C:\Documents and Settings\<current_username>\Local Settings\Application Data\VMware\VDM\logs. On Windows Vista and later, the directory is C:\Users\<current_username>\AppData\Local\VMware\VDM\logs. Open the most recently modified file in this directory starting with “debug”.
Now starts the fun part: trying to understand the gibberish that is a log file. The easiest way is to scroll to the approximate time that you clicked the Connect button and saw the failure. The first thing that you are looking for is a line that contains the phrase “HttpSendRequest returned ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED”. If you see this, that means that the View Connection Server is telling the View Client that it wants to certificate authentication, which is good. If you do not see this line anywhere, then you have not set up the View Connection Server correctly to support smart card authentication. Refer to the View Manager Administration Guide for more details about this. The most common error is not setting the attributes of the “locked.properties” file correctly or having a typo (e.g. “userCertAuth = true” instead of “useCertAuth = true”).
If you configured certificate authentication correctly in the View Connection Server, the next step is to determine whether the View Client can find the certificate you want to use for authentication. The Windows View Client doesn’t read them directly off of the smart card; instead, it looks in Start > Control Panel > Internet Options > Content > Certificates > Personal. If you go there and do not find the certificate that you want to use from your smart card, then you likely haven’t configured your middleware correctly. It is the job of the smart card middleware (e.g. ActivClient) to “copy” certificates from a smart card to the Personal certificate store for use by applications such as Outlook, Internet Explorer, and the View Client.
If the certificate you want to use to login is in the Personal store, that means that the Windows View Client believes that it is invalid for authentication to the current View Connection Server. To find the reason why, you need to look at the debug log file again. If you start at the place in the log file where you had previously found the phrase “HttpSendRequest returned ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED”, search downward for the word “GetCertificate”. The first line containing this word should be a line that will say something like “GetCertificate: Only using certs from issuers: ‘com, vmware-vdi, dc3-CA'”. Inside of the single-quote is a semicolon-delimited list of all of the certificate issuers that the View Connection Server is telling the View Client that it accepts. You should look at this list and make sure that this is correct. If it isn’t, you misconfigured the truststore in the View Connection Server. The truststore is what tells the View Connection Server which issuers it should accept for certificate authentication.
If the issuer list is correct, the next step is to look at the lines below that start with the word “IsValidCertificate”. This logging documents information about the certificates that it finds and the reason why it filters a certificate out. Here are the rules that the Windows View Client uses to filter certificates out (taken from this MSDN blog entry):
- The certificate must be valid according to the computer clock (i.e. not expired and not valid in the future). To override this, use Microsoft’s “AllowTimeInvalidCertificates” GPO.
- The certificate must have a private key that can be used for authentication.
- The certificate must have a valid user principal name or distinguished name. The distinguished name is also known as a Subject in the Certificate Details screen of Windows. The user principal name looks like an e-mail address and can be viewed by looking at the Subject Alternative Name in the Certificate Details screen.
- The certificate must have the Digital Signature key usage. This can be viewed by looking at the Key Usage field in the Certificate Details screen.
- The certificate must have the Smart Card Logon enhanced key usage or the Client Authentication enhanced key usage. This can be viewed by looking at the Enhanced Key Usage field in the Certificate Details screen. The Smart Card Logon enhanced key usage is almost always part of a certificate on a smart card and the Client Authentication enhanced key usage is almost always part of a certificate that you manually installed from the certificate server. To override this, use Microsoft’s “AllowCertificatesWithNoEKU” GPO.
- The certificate must be issued by a domain that the View Connection Server allows for authentication. To view this domain, go into the certificate properties, click the Details tab, and look at the issuer field.
Determining which of these 6 rules is incorrectly filtering out your certificate is the last step. If it is #1 or #5, you can override the checks with a GPO if you want. If it is #6, you need to change your truststore on the View Connection Server, as it is not correct. The others are required for certificate authentication to be successful.
