Category: Uncategorized

vCloud Director and VMware Horizon Intergration

Requirements for SSO in vCloud Director

The SAML process and parties using them have formal roles and responsibilities:

  • Service Provider – An entity that receives the SAML Message from an Idenity Provider (vCloud Director )
  • Identity Provider – An entity that authenticates an user (Horizon)

The Identity provider must provide these fields in the response (case sensitive):

  • UserName
  • EmailAddress
  • FullName
  • Groups

While the only required field is UserName it is recommended that all fields be returned with proper information to allow for ease of management and administration of the users and their rights.

Configuring vCloud Director

In vCloud director you will first need to enable the use of a SAML Identity provider.

  1. Once logged in as a Organization Administrator or System Administrator go to the organization Administration page, click on Federation, then enable the ‘Use of SAML Identity Provider’

  2. The XML metadata file that you got from your SAML/SSO provider should be downloaded to the machine these actions are running from. Due to the use of special characters and copy/paste issues it is not recommended to paste in a value into the field. Instead use the upload function to upload the XML file in whole.

In the case of VMware’s Horizon Product the metadata can be found here: https:///SAAS/API/1.0/GET/metadata/idp.xml

  1. Now close the organization tab or log out and back into the UI to get the ‘Groups’ and Import from SAML options in the UI. After that is completed you can now import users into vCloud Director.

Since SAML users and groups are not searchable users will have to be added one per line for each role. Another option for granting access to the organization is through the use of groups.

At this point the configuration of vCloud Director is complete.

Exporting XML Metadata from vCloud Director

We now need to export a file much like what we imported from the SAML provider, so that the SAML provider will trust and validate requests coming from vCloud Director. This file and related certificates are controlled on the Federation page where we imported the SAML XML file. At the bottom of the page click on the ‘Regenerate’ button to create a new certificate with a validity of 1 year.

It will prompt you with a warning about changing the certificate. If you have already setup a SAML provider relationship, changing this certificate will break that relationship until the SAML provider replaces their current information with the new certificate.
Once the certificate is generated you can download it via this weblink:
Save this file as an XML file, then provide this to your SAML provider for the next section.

Configuring Horizon for vCloud Director SSO

First you will need to login to the administrator interface for Horizon and create a new Application, then follow these configuration items for that application.

  1. Configure the Login Redirection URL to be the organization URL in vCloud Director. This is required for vCloud Director to work properly, since the authentication sequence must start with vCloud Director and not Horizon.

  2. Check the ‘Include the Destination in the response’

  3. Check the Sign the entire response.
  4. Check the ‘Sign the assertion’
  5. Remove the ‘Include Cert’ checkbox
  6. Select the configure via Meta-data XML option. Then upload the certificate (copy/paste) the certificate in to the text box given.
  7. Click on ‘Populate Attribute Mapping’
  8. Configure the Attribute Mapping to match your deployment of Hoizon.

vCloud Network Security 5.1.2a Release

Heads up… VMware released vCloud Network Security 5.1.2a this morning, it is a MUST upgrade if you are on 5.1.2. Fixes a pretty big show stopper bug where a vShield Manager can stop responding to requests without warning/error and the only fix is to bounce the entire vShield Manager.

Release notes here.

Doumentation here.

vCloud Network Security Product page here.

Symform Security Analysis

This morning on twitter I was asked if Symform “Secure Online Backup” was as secure as SpiderOak (my favorite online storage/backup solution). Here is my analysis from reading Symform’s publically facing documents.

How it works:

According to Symform’s website, your data is processed at the folder level. Meaning that all files in a folder are encrypted together. This does give the benefit of being able to de-duplicate the files inside that folder, it is not clear if this is at the block or file level though. If done at the block level this would be analogous to compression, if done at the file level I would image not much savings in space since it is uncommon for duplicate files in the same folder.

These files are encrypted with AES256 (good job there), but what generates this key? Since there would be a separate key per folder/container it would be near impossible for the end user to manage these keys. That means the Symform Cloud Control is generating and managing these keys for you the end user. (This is confirmed by their own documentation)

After your files are encrypted (in 64MB folder chunks), they are then broken into 1MB chunks. Parity fragments are then generated out of those 1MB chunks, 32 parity fragments to be exact. Those parity chunks are then sent out to the Symform Global Cloud Storage Network, and distributed to 96 devices.


That seems fine right? Your data is spread among 96 random devices on the internet, encrypted and secure.

Well that is the problem, who controls the decryption/encryption keys? Symform does.
Who controls where your data is stored on this ‘Global Cloud Storage Network? Symform does.

From a stand point of Trust No One, Symform fails the test. A hacker can still get your AES keys, and the location of those blobs on the internet. A government agency can still subpoena for your data, and have access to the decrypted data.

While it looks like a neat technology, SpiderOak still wins in my opinion, since I control the encryption keys and where my data resides (Amazon S3 storage).


VMware this morning released a KB article and a fix for the Edge devices filling up on disk space. While it did not kill the edge or cause an outage, it did stop you from being able to make changes to the Edge’s configuration.

The official fix will be released on this site:

The upgrade/patch will require the standard vCloud Network Security (vShield) upgrade process where the Edge device will need to be replaced with the new code. (READ: Possible outage of network for a few moments while the Edge is swapped)

How do you know if you have this problem?

In vCloud Director, attempting a reconfig fails with this error:


In vCloud Director, when looking at Edge Gateways, you receive this error:

Edge VM backing the edge gateway is unreachable

Just remember, when this happens it is not causing an outage or a network failure. The edge is basically running ‘headless’ at that time, and will not accept any ruleset changes.

vCloud Network Security (formerly vShield)

Those of you that used the former product vShield that is OLD news, VMware’s marketing team has renamed it to be VMware vCloud Network Security, which is really what it is. vShield EndPoint is now free with vSphere host licenses, Enterprise Plus is needed of course.

Here is a highlight of what is new in vCloud Network Security:

  • The Edge product finally supports more than two interfaces, and becomes a more flexible and usable product. It now features 10 interfaces, it can be a mix of internal and external interfaces.
  • Edge now has an SSL VPN built in to it, this is truly interesting with vCloud Deployments. Instead of needed an IPSec VPN client, and the underlying requirements (looking at you GRE), now the requirement is port 443.
  • The new UI… can’t say enough about it. It is clearly a ground up re-design from the old design. Now it is more standard, easier to follow, and much easier to add/change/delete rules.
  • Throughput – Edge is now ‘officially’ supporting > 3Gb/s with 2,000 NAT and 2,000 Firewall rules. ‘Unofficially’ it tested much higher than that.
  • Load Balancer is actually getting smarter now, it is not just the round-robin as it was before, it now will do load balancing policies.

vCenter and vSphere 5.1

The latest versions of VMware’s vCenter, vSphere, vCloud Director, and vShield are now at version 5.1. The first major, ground breaking change…


That is right, a year after making the very unpopular choice to limit the amount of ‘vRAM’ you could use per license, VMware has heard the screams of pain and completely tossed the idea. While it only really effected a handful of the thousands of customer of VMware, it was a complexity that caused more confusion than answers.

Now to the news…

vSphere 5.1 has once again rev’ed the virtual hardware version to version 9. Version 9 will give you the ability to run 64 cores on a single VM, this makes the ‘Monster VM’ even larger!

vCenter 5.1 supports 20,000 VMs powered on in the same vCenter, 25 linked vCenters, 1,000 hosts per datacenter, 128 storage vMotions concurrently.

VMware is also moving away from the thick C# client that was tied to Windows only machines, to a web-based client. This new vSphere Web Client was there in 5.0 but it was incomplete and lacked basic functions still. 5.1 is the first version of the vSphere Web Client that is actually a near replacement for the old thick client. If the vSphere Web Client is used you can actually get around 150 concurrent client connections to your vCenter server(s).

More to come as information comes out of VMWorld this week!


Barcelona is going to be the first VCDX5 defenses, meaning you can submit a vSphere design and only be questioned on vSphere 5.x features. Sure with the current program you can submit vSphere 5 designs, but you will only receive a VCDX4 certification. So the real question what changes with VCDX 5?

The short answer is nothing. Nothing changes from all the blog posts and information that is out there for VCDX 5.