Ejecting CD ISO’s in vCloud Director

With vCloud Director 5.1 every once in a while a CD will refuse to eject, or worse it will say it ejected the CD but it will not make the change in vCenter.

To get around this with PowerCLI connected to the vCenter use this command:

get-folder | get-VM | Get-CDDrive | Set-CDDrive -NoMedia -Confirm:$false

This will allow the CD to be ejected without having to Deploy, Eject, Re-Capture the vApp Template. To use for a normal vApp use the vApp Name/UUID.

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.

Enabling SAML Providers in vCloud 5.1

As a system or organization administrator head to the ‘Administration’ page, and then the federation tab. Paste or upload the SAML configuration XML. Ensure the certificate at the bottom of the page is recent, if not click re-generate certificate. It will produce a certificate for 1 year.

After the certificate is re-newed enter this URL in to the web browser: cloud/org/[orgName]/saml/metadata/alias/vcd ; save the XML file on that page. This is the file you will need to provide the SAML or 3rd party authentication service with in order to authenticate you.

Now you have SSO or SAML or 3rd authentication, enabled on your organization. Once configured/enabled the Org login page will now use the SAML provider, meaning any local users will be locked out.

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.

New Year… Brings Changes

With the New Year brings some new changes; I am transferring inside of VMware to a new group that is focusing on Cloud Consumption.

Cloud Consumption… WTH is that?

For the past, well as long as I have been in IT, I have been doing ‘Ping, Power and Pipe’. With IaaS it is in my opinion it has been done, most any experienced IT person could stand up IaaS.

In my new role I will be focusing on methods to consume the cloud offerings. For example, how does one define a service (in the ITIL sense) from this ‘Ping, Power, and Pipe’? Another example, what requirements does a consumer have? How can the cloud offering satisfy those requirements?

More importantly… “Define the services that consumers will utilize, while driving the architecture of the physical”

Happy New Years! 2013 will most definitely be a challenging year.

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

Host Isolation Response Settings

Over the past few weeks I have had some people ask what I would recommend for host isolation addresses and responses, when using vSphere x.x with high availability (HA) enabled.

First off as with most everything in computers ‘It depends’.

Items to consider with host isolation response is what type of storage is being utilized? Is it considered an outage if the vSphere hosts can talk to each other but the virtual machines (VMs) cannot? How stable is my management network? Is datastore heart-beating setup correctly? The list can of things to consider can be quite long.

Here is what I generally recommend…

NAS Based Storage Options (iSCSI or NFS)

First, set one of the host isolation response addresses to the virtual IP (VIP) or the IP of the storage array. This will tell you if you can at least talk to the array; chances are that is you cannot talk to the array your machines have already failed.

That brings me to the isolation response, since the VMs should already be dead, remember the NAS array and host are no longer able to communicate, I recommend ‘Power Off’. If you were to leave the response to ‘Leave Powered On’ you can run into a chance of corruption on the guest disks. Think about it, the disk goes away for 60 seconds, then comes back. Do you think that VM is going to be able to recover, what are the odds of it corrupting that vital disk? What about ‘Shutdown Guest’, well that has a chance of the same exact thing happening.

Power Off in this setting is the safest setting, not only will it allow for that VM to be brought up elsewhere, you run a less chance of corruption or VM failure.

Fiber based storage (SAN)

With fiber the network isolation address does not matter as much, reason being the storage is not relying on the network for communication.

General Host Isolation Techniques

If it is considered a down time for the VM network to fail but not the management network, is there a way we can mitigate this?

Of course, put a vmkernel port on the virtual machine network, enable it for HA traffic, then place an isolation address of that networks gateway in to the HA configuration.

vCNS App – Spoofguard Deployment

Spoofguard records the IP address of each vNIC secured by vShield App. Spoofguard can be configured in two different modes, automatic and manual.

In Automatic mode the first IP that is presented for each vNIC is recorded and allowed to communicate without authorization. If the IP of the vNIC changes, the machine will no longer be able to communicate on the network until the new IP is approved.

In manual mode all IPs must be approved prior to being allowed to communicate; even existing virtual machines will be blocked until approved.

When enabling Spoofguard in an environment where there are existing virtual machines, it is recommended to enable Spoofguard in ‘Automatic’ mode. Once the vNICs are learned and reviewed it is then acceptable to switch to Spoofguard to ‘Manual’ mode, which will restrict all new virtual machines from communicating until approved. When deploying vShield App to a greenfield environment Spoofguard can be enabled with ‘Manual’ mode.
Once Spoofguard has flagged a VNIC for approval, it must be approved prior to traffic being allowed to transmit. This is true even if Spoofguard is later disabled; all VNICs that are in ‘Require Approval’ will require approval before they can transmit.

When utilizing vShield App in a vCloud Director environment Spoofguard should not be enabled. The reason for this is that when vCloud Director brings a virtual machine online for the first time the machine will boot up and broadcast an IP (either DHCP or a pre-defined IP). When the machine is fully booted the guest customization script takes effect and changes the IP to the one defined in vCloud Director. Spoofguard will learn the first IP and not allow the VM to communicate on the network until the new IP is approved. It is possible to use vCenter Orchastrator to automate this approval process; that discussion and how to is out of the scope of this document.

Spoofguard currently supports only one IP per VNIC, so one cannot specify a secondary or failover IP.

iOS 6 – Ad Tracking

You can disable (well limit) the ad tracking that is done in iOS 6. This setting turns off the ability for advertisers to use what is called the ‘Advertising Identifier’. This replaces the devices UUID which is a non-anonymous way of tracking usage. The advertising identifier is ‘anonymous’ (though further research needs to be done).

Here is how to disable the ability for advertisers to track you at all (once they move from the old deprecated UUID model).

  1. Fire up your iOS device
  2. Under Settings
  3. Find General
  4. Click on About
  5. Scroll to the bottom and select ‘Advertising’
  6. Set the ‘Limit Ad Tracking’ to ‘On’

You are done. Now go forth, untracked from iOS ads (the Apple ones anyway).

Browse Categories