Home > Blogs > VMware End-User Computing Blog > Monthly Archives: October 2010

Monthly Archives: October 2010

View Into The Federal Government

by Pam Takahama – Sr. Product Marketing Manager

We focus a lot of our product marketing efforts around understanding the key use cases and business requirements of the VMware View target markets.

Take for example, the U.S. federal government sector; a highly dynamic and complex IT environment driven by rigorous security and compliance standards and a vast but decentralized workforce. When you consider the  diverse desktop requirements  of the modern federal workforce including teleworkers, disaster recovery teams and forward deployed military personnel, it becomes clear a highly dynamic IT approach is needed.

There are a few key events like last winter’s shutdown of Washington D.C. due to storms, the global H1N1 virus scare and federal IT modernization mandates which are driving IT to shift their thinking from a “device centric” world towards one focused more on “end-users”.  In a device centric environment users are tied to one device and find it difficult to access their desktop from other devices and locations such as from a home machine.  With the limitations of the traditional "device centric" model end-users are not empowered.

A user centric world enable greater efficiencies, empowerment and increased productivity; exactly what future public servants expect to be enabled in their jobs.  Think snowstorm. And think about providing agency workers real-time, secure access to familiar agency-standard resources via a VMware View desktop they can access from home, a remote office or even aboard ships or portable office pods!

It is very exciting to see federal IT—typically late adopters —take such a pro-active interest in VMware View over the past couple of years. The buzz was loud and clear at the recent San Francisco VMworld event! The end-user computing journey is just that…a journey. And desktop virtualization is the first big step federal IT is taking towards modernizing and better enabling their diverse workforce which ultimately improves service levels to citizens. We are committed to that journey and to an ongoing collaborative effort between our product team and the federal end-user community.

Troubleshooting smart card authentication using the Windows View Client

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):

  1. 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.
  2. The certificate must have a private key that can be used for authentication.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Wow, BYOC and Client Virtualization is hard!

The dust is starting to settle from the successful launch of View 4.5 which includes the industry's first and only truly VDI-integrated offline desktop support via View Client with Local Mode.  As I emphasized in a post back in May, this solution really comes into its own when you consider Bring Your Own Computer (BYOC) and similar scenarios.  But there's an important observation I didn't make back then: "dang this stuff is hard!"
 
It's hard in two macro dimensions:

  1. Doing BYOC successfully in the enterprise is hard
  2. Building the right technologies that make #1 easier is hard

Let's consider #1 first.  There's a lot of reasons why many analysts remain skeptical of BYOC for laptops taking off soon — in spite of broader trends to device heterogeneity and end user demand for consumerization of IT.  A few good examples include:

  • Risk of device failure = Productivity Loss (and IT left holding the bag)
  • Protection against data loss (laptop left on the bus, taken form the back of a car, etc)
  • Controlling Intellectual Property (IP) and application access (ensuring data or app licenses don't wander off)
  • Ability to address all of the above AND still offer integrated, off-network, "work anywhere" mobility

We know that addressing this cohesively won't be a one-size fits all sort of approach.  An enterprise taking this seriously is going to need to bring together several, well integrated technologies to address the needs of different users.  View Client with Local Mode is one important piece of that story.  How we think about that is highlighted well in this little video:



 

http://www.youtube.com/watch?v=Qza_T06t41U

But why is full integration and mobility of the virtual desktop between client and server useful?  How does it make BYOC easier?  Well, on one hand it can enable occasional BYOC offline use: if you're using server hosted VDI for the typical office bound worker (quite likely with a zero-client), and they need to take that occasional trip to a conference or customer site, a quick checkout to their own laptop before they hit the road can enable several days of offline productivity with minimal IT overhead or concern.  But more profoundly, it can help solve one of the key problems that has plagued other BYOC offerings with offline connectivity — that risk of significant productivity loss if a user manages to mess-up or lose their device.  Consider the following scenario:

  1. A roadwarrior checks out a desktop to their laptop of choice.
  2. They use it 100% in Local Mode as they roam the world.
  3. User changes are replicated back to the datacenter when they have network connectivity.
  4. Something bad happens to the laptop (run over by a truck, etc).
  5. They are able to immediately get up and running via any Internet kiosk in the world — their VM is brought up and running in the datacenter via the replicated bits — you can do this because the VM formats for View between server hosted and locally hosted workloads are the same.  No messing with in guest drivers, etc.
  6. When the roadwarrior has an opportunity to get a new laptop from a local electronics store they do so.
  7. They then re-checkout their desktop to run on that commodity laptop as if nothing has happened.

The important point here is that while IT doesn't own or manage the device, they are able to provide business continuity for the end-user in spite of the user's own mistakes in destroying or otherwise DOSing the device.  Productivity is actually improved, and IT is never left holding the bag for the reliability of hardware that is outside their control.
 
So that's a bit on how we're working hard to make BYOC easier for the enterprise.  Now what about the technology itself?  Yeah, this stuff is hard too.  As another vendor's recent attempts to offer BYOC-ish personal compute environments on corporate assets can attest, it's not easy to get this stuff right:

Brian Madden's Analysis of XenClient 1.0

I'm normally not one to wax too philosophic on other bloggers opinions, but Brian's observation at the end of his post does have an additional ring of truth to it:

"Oh, and by the way, how brilliant does VMware's cancel-type-1-replace-with-type-2 strategy seem now?"

I won't comment at this point about what VMware plans or does not plan to do when it comes to type-1 client hypervisors.  But I can say that we have invested over a dozen years of development now in the very platform that makes View Client with Local Mode do its thing.  When you check-out and run a desktop locally, you're leveraging the same battle hardened virtualization technologies used in VMware Workstation, Player and Fusion.  They're not perfect, but they've got some real treadwear.  Will the mouse cursor generally be responsive under normal conditions?  Of course.  Full (non-experimental) support for Windows 7 Aeroglass effects, or 3D apps like Google Earth with 3D buildings?   Yes, we support that on Vista and Win 7 hosts and on most GPUs — Intel, Nvidia and ATI are all fine.  When I unplug USB devices will everything work "normally" and not hang the whole machine?  Uh, yeah.  Will VMware be able to offer this same sort of goodness for the Mac too?  Well, you know by now that VMware folks never make commitments on yet to be announced products, but I can say that developers are hard at work on the right technologies for this in our labs — I think the existence proof of VMware Fusion makes such statements credible.
 
So bottom line, View Client with Local Mode opens up a lot of exciting new opportunities for managed desktop deployments — particularly those with Bring Your Own Computer overtones.  There will be many releases ahead where we continue to improve and refine this stuff.  It's indeed hard, but you can look to get real enterprise value for the right use cases today.
 
Happy View 4.5 piloting!