Today I started to lock down the permissions the Xen Desktop Delivery Controllers (DDC) have on vCenter. There is not much documentation on this. Except for the kb article on VMWare Infrastructure 3 and XenDesktop which is lean and mean. But then i stumbled on this great blog post: http://theether.net/kb/100114

Which describes the solution to the error “This virtual machine could not be retrieved from the hosting infrastructure”
The solution basicly describes the proper permissioning for the accunts which access Virtual Center from the DDC and this even works for vCenter 4!

In VirtualCenter:

- Select View | Administration

- Click Add Role
- Enter the name XenDesktopGlobal
- Check Global | Manage Custom Attributes
- Click OK

- Click Add Role
- Enter the name XenDesktopDataCentre
- Check Datastore | Browse Datastore
- Check Virtual Machine | Inventory | Create
- Check Virtual Machine | Provisioning | Deploy Template
- Check Resource | Assign Virtual Machine to Resource Pool
- Click OK

- Click Add Role
- Enter the name XenDesktop
- Check Global | Set Custom Attribute
- Check Virtual Machine | Interaction | Power On
- Check Virtual Machine | Interaction | Power Off
- Check Virtual Machine | Interaction | Suspend
- Check Virtual Machine | Interaction | Reset
- Click OK

- Select View | Inventory | Hosts And Clusters

- Select Hosts & Clusters
- Select the Permissions tab
- Right click and select Add Permission from the context menu
- Select XenDesktopGlobal for Assigned Role
- Click Add
- Select the account used in the Logon Information properties of the Desktop Group
- Click OK
- Click OK

- Select the Datacentre that contains the virtual desktops
- Select the Permissions tab
- Right click and select Add Permission from the context menu
- Select XenDesktopDataCentre for Assigned Role
- Click Add
- Select the account used in the Logon Information properties of the Desktop Group
- Click OK
- Click OK

- Select the Cluster or Resource Pool that contains the virtual desktops
- Select the Permissions tab
- Right click and select Add Permission from the context menu
- Select XenDesktop for Assigned Role
- Click Add
- Select the account used in the Logon Information properties of the Desktop Group
- Click OK
- Click OK

Source: http://theether.net/kb/100114

Moxie developed a tool and technique called SSLSNIFF which is able to do undetectable Man in the Middle attacks on SSL connections exploiting the possibilities null terminated certificates offer. He defined three possible counter measures against his attack. Certificate validation, software updates and extended validation certificates. Unfortunately he was able to defeat two of these three measures.
Certificate validation these days is handled mostly by the OCSP, the Online Certificate Status Protocol. Marlinspike found a flaw in the protocol. On of the statuses the OCSP can send back is “Try later…”, represented by the number 3. Such a reply does not need to be signed by the CA an causes the browser to fail open, or as Moxie put it: “OCSP is defeated by the number 3”.
Software updates can be another issue. At the time of the presentation, these bugs where only fixed in Firefox 3.5, so how do you prevent people from updating to this version? Most browsers these days have a so called auto update function, this function searches online for a more recent version of the browser, addons or plugins. In order to ensure that no malicious content is installed, the browsers rely on SSL, the same SSL that was broken by Marlinspike’s SSLSNIFF.

But there is more trouble in paradise. Marlinspike also demonstrated a technique het called ssl stripping. Ssl stripping does not attack SSL itself, instead it actually attacks, what Moxie described as the bridge between http and https. “Https is today’s world is not often encountered directly. Users don’t often type https:// in the address bar themselves. In stead they get redirected to an https site or click on a link to it”. By performing an man in the middle attack on the http connection and carefully rewriting all https requests to http requests, Marlinspike was able to create near exact copies of the login pages for services such as gmail and paypal. The user would only know something is wrong, if they notice that the https prefix is not there or that the padlock symbol is missing.

Dan Kaminski was also able to exploit the common name field to get certificates he should not be getting. Different implementations of certificate validation routines have flaws when it comes to handling certificates with multiple common names in them. By requesting a certificate with three common names: CN=www.ioactive.com, CN=www.bankofameric.com and CN=* Kaminski was able to get a certificate that would perceived as follows; the CA would sees the certificate as an www.ioactive.com certificate, which Kaminski is allowed to request. Internet Explorer will interpret the certificate as a www.bankofamerica.com certificate and Firefox will allow the certificate to be used for any url.

Besides the common name abuse, Kaminski also showed us that there is still an MD2RSA signed root certificate present in all browsers. While practical exploitation is not possible at the moment, it is very likely that this possible in the near future. Most browser vendors are working to fix the issue right now, but Kaminski kindly requested his public to “please, do not hack MD2 in the next six months.”

The last talk I attended was Mike Zusman’s “Criminal Charges not Pursued, Hacking PKI”. Mike used another technique to get “interesting” certificates. By exploiting a flaw in the web application of a CA, he was able to request certificates for pretty much any domain he wanted.

One of the solutions seems to be popping up is Extended Validation, which in a sense takes us back a couple of years. A few years back, the only way to buy a certificate was to provide legal evidence that you had control over a domain via an out of band mechanism to a human, but then these persons at the CA’s where replaced by an online application with an automated validation process and the fun started.

Extended Validation changes this by enforcing standards for validation and requiring validation by a human before the certificate gets issued. Extended Validation (EV) CA’s are hard coded in the browser to prevent the addition of malicious CA’s. But EV certificates get trusted just as much as classic certificates.

Mike Zusman was able to perform a man in the middle attack PayPal, which uses an EV certificate to protect its site. What his program does is only redirect a small portion of the traffic, the actual login, to his own malicious website which has a non-EV www.paypal.com certificate obtained via on of the methods described earlier. The only side effect visible to the user is a brief flickering of the green address bar. But will a user notice or care?

Obviously dual factor authentication, like PayPal’s security key, will reduce the risk, but what can we really do?

I was able to share a beer with Mike after he presentation and it looks like there are fundamental underlying problems with the current certificate structure. Here we have architecture of trust, yet its foundations are built on the known insecure DNS database. Browser vendors claim they have this set of rules that should be obeyed in order for a CA to be included in the browser, yet practice shows that certain CAs that have not followed these rules are still in the browser, while on commercial CAs, like CAcert are having a hard time getting included in browsers for what seems to be political reasons.
It is time to ask ourselves fundamental questions like: Is it a good thing that a browser vendor determines who’s assertion of identity to trust. There is a trend that browsers make it harder to accept invalid certificates. Mike said: “It currently takes more clicks to accept an invalid certificate, then to import a new CA”. Is this a good thing?

Both Zusman and Kaminski agree that is would be a good thing if we had a trustworthy DNS structure that we could just to, e.g. store the fingerprints of certificates that are valid for our domain. Unfortunately DNSSEC is currently in a status quo. The current implementation still got issues, but until the root servers are going to be signed nobody will be motivated to fix these issues.

I was pretty impressed when trialling Flash HDX myselfs… seeing is believing The movies below are not mine, but linked from youtube.com. It’s worth trialling yourselfs, you won’t be disappointed.

Click here to view the embedded video.

Click here to view the embedded video.

Download the Technology preview of Citrix HDX Mediastream for Flash here.

We will try not to disapoint you. We have some very interesting projects comming-up which involve very mission critical XenApp and XenDesktop environments. We will post our hands-on experiences here! So stay tuned !

Haven’t tried it myselfs so i’m curious to your experiences, please leave a comment, thanks.
Overview of latest xendesktop patches here: http://support.citrix.com/product/xd/v3.0/

Citrix is working on a hotfix to have XenDesktop working with vSphere 4. Currently people are experiencing issues with the Desktop Delivery Controller (DDC) to communicate properly with the vSphere SDK webservice. Also the XenDesktop Setup Wizard, which automates creation of Virtual Desktops, seems to be broken.

A partial workaround seems to be availlable; reapply the hack to enable /SDK over plain HTTP and HTTPS.

Change “c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\proxy.xml”

The section should look similar like this:

<e id=”1″>
<_type>vim.ProxyService.LocalServiceSpec</_type>
<serverNamespace>/sdk</serverNamespace>
<accessMode>httpAndHttps</accessMode>
<port>8085</port>
</e>

The hotfix, when availlable, will be posted here. More info can be found in this support thread of the Citrix Forums

Viance is the new product line of XenDesktop optimized endpoint devices from Wyse.

Click here to view the embedded video.

Wyse also announced a mobile Viance product, the Wyse Viance Pro Mobile. The questions is how this will work in the real-world, since you’ll need to have connectivity to XenDesktop farm in order to work.

Product Page Wyse Viance Thin Client
Product Page Wyse Viance Pro Mobile

Since we do a lot a of VMWare and Citrix we looked at both VDI products. VMware relies for 100% on a remote display protocols but Citrix has bought Ardence which now has been rebranded into Citrix Provisioning Server.
Ardence / Citrix Provisioning Server is able to stream a full-blown OS over the network to physical and virtual machines. It actually mounts a disk over the network.

Check the video below for a very cool demo

Ardence Demo

So with Ardence all the limits of remote display protocols are gone for demanding applications.

Next to this all VDI vendors are fighting for the best remote display protocols. Microsoft bought Calista, VMWare Teradici (www.teradici.com) and Citrix is extending the ICA Virtual Channels with all kinds of nifty extensions like Flash HDX (Still techpreview) and 3D rendering using GPU’s at the server side. We did a PoC with Flash HDX which offloads flash rendering to the client and this rocks, although still beta with some quirks. Finally full quality Flash on XenDesktop and XenApp. Another nice feature of XenDesktop is that it supports smartcards from the endpoint device

What’s new in FP1 of Xendesktop 3:
http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1686118

How does the Citrix VDI solution work?

It is actually based on a bunch of existing (proven) technologies:

- Ardence OS Streaming
- Application hosting / streaming from XenApp
- ICA into a client OS (XP / Vista / Window 7), sort of single user Citrix box.

VDI into the Physical Standardized Desktop

OS Streaming on the LAN based on Citrix Provisioning Server (rebranded from Ardence). Citrix Provisioning server streams a single disk image over the LAN to multiple desktops which then are able to run a full-blown OS without the limitations of remote display protocols and leveraging local computing power. By default the streamed disk image is non persistent and the OS on the desktop will return to the initial state after a reboot. When required dedicated, read-write images can be provisioned, however this breaks the single image storage advantage.

The application are then delivered onto the desktop using (“traditional”) XenApp either streaming or hosted.

And all personal settings are stored in a traditional roaming profile, profile management however will be necessary to keep al the bloat out. This can be done using Citrix Profile manager which comes with XenDesktop or your favorite profile manager.

VDI into a virtual Infrastructure

The same happens applies when you want to run Virtual Desktops in Virtual Infrastructue like XEN, VMWare or Hyper-V (All supported by XenDesktop). Not sure when vSphere 4 will be supported. The main difference is that you’ll need to access the Virtual Desktop using ICA/HDX and all the limitations involved. But the major limitation of flash over ICA is due to be solved with Flash HDX, which rocks. You’ll need to see this for yourselves, it’s 100% like running Flash locally.

XenDesktop 3 Architecture

Check www.brianmadden.com on all the pro/cons of the different VDI solutions.