Wednesday, December 17, 2014

How to customize the "Download Workspace for Windows" URL in Workspace Portal

If you've found yourself directing users to download the Workspace for Windows Client by telling them to login to Workspace, click their name, and choose "Download" only to find it takes them to www.vmware.com.. you're not the only one!









Users should be able to download the Windows Client directly by clicking "Download"












There's even a pretty button for it!


Luckily this is pretty simple to address.


To change the Workspace Client Download URL:



  1. Login to the Workspace appliance as root, and type the following

    vi /usr/local/horizon/conf/client-download.properties

  2. You should see a single line that reads winSyncClientUrl=http://www.vmware.com


  3. Simply change the value of winSyncClientUrl to the desired URL. You could set this to the actual VMware Download page for Workspace Products (https://my.vmware.com/web/vmware/details?downloadGroup=HZNP210&productId=419&rPId=6533) or you can set it to an internal link to the .exe itself on your web server. I have mine set to my cloud share for direct access to the .exe:


  4. Restart the workspace service

    service horizon-workspace restart


  5. Reload your Workspace User page and you now have a working download link for the client! Good luck!


Share:

Monday, December 15, 2014

Workspace Portal SSL Certificates [updated for vIDM]

[Updated September 2015]


The below process was originally written for Workspace Portal 2.1 and can be applied to vIDM. Any differences in process has been placed appropriately within the post.




VMware strongly recommends that you configure SSL certificates that are signed by a valid Certificate Authority (CA) for use by Workspace Portal.

A default SSL server certificate is automatically generated when the Workspace appliance is installed. Although you can use the default, self-signed certificate for testing purposes, it should be replaced as soon as possible for a production environment. The default certificate is not signed by a CA. Use of certificates that are not signed by a CA can allow untrusted parties to intercept traffic by masquerading as your server.

If you deploy Workspace with the self-signed SSL certificate, the Workspace root CA certificate must be available as a trusted CA for any client who accesses Workspace. The clients can include end user machines, load balancers, proxies, and so on. You can download the Workspace root CA from https://workspacehostname.com/horizon_workspace_rootca.pem.

Before you can import a certificate, you must generate a Certificate Signing Request (CSR) and obtain a valid, signed certificate from a CA. If the CSR is not generated according to the example procedure described in this document, the resulting certificate and its private key must be available in a PEM format file.

There are many ways to obtain SSL certificates from a CA. This post shows how to use OpenSSL to generate a CSR and make a certificate available to Workspace Portal. You can use another method if you are familiar with the required tools, and they are installed on your server.

If your organization provides you with SSL certificates that are signed by a CA, you can use these certificates. If these certificates are not in the necessary PEM format, you can convert them with third party tools, such as that from SSLShopper

To make a certificate available to Workspace Portal 2.1, three things must be done:

  1. Create a configuration file

  2. Generate a certificate signing request (CSR) from the configuration file

  3. Send the signing request to a CA


When the CA returns the certificate, you must import the signed certificate into Workspace Portal using the Appliance Configurator. If using a Load Balancer, you must import the signed certificate onto to the Load Balancer per the vendor's instructions, and then install the Load Balancer's Root CA Certificate on Workspace Portal.

Creating the configuration file


We will be using OpenSSL as it comes pre-installed on the Workspace Portal appliance, though you can use OpenSSL on a wide variety of operating systems, including Windows. The below instructions will be assuming a Linux based OS.




  1. Login to your system that has OpenSSL installed (if using the Workspace appliance, either open a vSphere console, or SSH into the appliance).

  2. Create a folder to perform the certificate work in:mkdir certificates
    cd certificates

  3. Copy openssl.cnf into that foldercp /etc/ssl/openssl.cnf openssl.cnf

  4. Edit the file using vi.
    vi openssl.cnf
    The part of the file you have to modify in order to generate a certificate request is highlighted below. For a wildcard certificate request, subjectAltName is not relevant.



[ req_distinguished_name ] # Change these settings for your

environment

countryName_default = US

stateOrProvinceName_default = Colorado

localityName_default = Broomfield

0.organizationName_default = EUC

organizationalUnitName_default = IT



 

[ CA_defaults ] # Change sha1 to sha512

default_md = sha512

 

[ req ]

default_bits = 2048



[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment,

dataEncipherment

extendedKeyUsage = serverAuth, clientAuth

subjectAltName = DNS: ext-con.company.com, DNS:

view.company.com, DNS: gtw.company.com, DNS:

services.company.com Since we will request a wildcard

certificate these additional hostnames are not of importance.



NOTE: We are not setting the commonName here, we will do that below when prompted. If you plan to not use a wildcard, consider adding your subjectAltNames




Save this file

:wq


Generating the certificate request




  1. Create your CSR and private key by typingopenssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cnf


  2. Accept the default values you configured on the .cnf file. When prompted for the common name, enter either the wildcard value, or the external name you will be referencing for Workspace from outside your network (e.g., portal.acme.com)Make sure you store your private key in a safe place. Without it, your certificate becomes useless.

  3. Congrats! You've successfully created a certificate signing request for a sha512 hashed, 2048-bit encrypted certificate. Now to get this CSR signed.


Send the CSR to a Certificate Authority (CA) for signing



Your CSR must be submitted to a CA in order to be issued a usable certificate. You can use either a publicly trusted CA (GoDaddy, DigiCert, etc), or an internal CA your company has, or perhaps one you even built yourself. If you don't go with a publicly trusted CA, there are plenty of options for setting up your own CA. The important thing to ensure is when you've been issued your certs, download them as Base 64 encoded.

Installing the certificate


Once you've obtained your certificate(s), it's time to put it together so that Workspace can understand it. Workspace needs the certificate to be in PEM format. PEM is a widely used format these days because of its flexibility and ease of use. PEM allows you to bundle multiple certificates into a single file which a server can read and understand. This is important for Workspace. If you need to convert the certs you received to PEM format, you can use the link provided earlier in this post, or even use OpenSSL. Workspace needs at least 2 certs (usually 3) which you should have received from your CA.

Server (host) cert
Intermediate cert(s)
Root cert

This is how we will build our PEM file, with the host cert on top, any intermediate certs in the middle, and root on the bottom:
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate)
-----END CERTIFICATE----

It's important to use a text editor like WordPad or Notepadd++ when handling these PEM files. Using something like Notepad can cause formatting issues that we certainly want to steer clear of.

Once you've built your new PEM file containing the components above, it's time to install it. If you don't have a load balancer or reverse proxy server in place, you can install this right on Workspace. This is considered terminating SSL on the Workspace Appliance.

To do this on Workspace Portal:

  1. Login to the Appliance Configurator (https://your_workspace:8443), click Install Certificate

  2. In the Terminate SSL on Workspace appliance tab, paste the complete certificate chain (what we created above) and also include the private key in its box.

  3. Save the SSL certificate.


To do this on vIDM:

  1. In the Administration Console, click Appliance Settings

  2. Click Manage Configuration and enter the admin password

  3. Click Install Certificate

  4. In the Terminate SSL on Identity Manager Appliance tab, select Custom Certificate.


If you're using a Load Balancer or Reverse Proxy, you'll need to instead install the cert on that device per the vendor's instructions. Using something like NGINX is quite simple as you simply include the cert and private key path in the configuration file (See How to Setup NGINX as a reverse proxy for Workspace Portal 2.1)

If you're using an internal CA, or otherwise a lesser known CA, it may be necessary to install the Root CA on Workspace in order for it to gain trust. Back at the Install Certificate page, click the Terminate SSL on a Load Balancer tab, and paste the PEM output of the Root CA here.

NOTE: if you've previously installed custom certs on Workspace itself, and are now trying to instead use a Load Balancer, you will need to first re-generate the self signed certs on Workspace before you'll be able to properly reconfigure the Workspace FQDN.

[Important]
If you happen to use a KEMP load balancer with Workspace, you may run into issues configuring your FQDN after following the recommended SSL Certificate process. Please review Kemp's Workspace Documentation which should help get the load balancer configured properly.

Related documentation and references




Share:

Friday, December 12, 2014

How to remove your License from VMware Horizon View

Licensing Horizon View is quite simple. Grab your key, enter it into the GUI and you're off. What you  might have noticed, however, is that once you've submitted your key, it's as if you've deposited it into a black hole, never to be seen again. Per the licensing section in View Administrator (View Configuration > Product Licensing and Usage) the only information we get is which features are enabled and our expiration.



So what if you need to remove this license without replacing it? Or what if you're getting an error replacing the License and wish you could just wipe it out? The answer is quit simple and outlined below.


In order to clear your license from View:


  1. First, take a backup of the ADAM database (http://kb.vmware.com/kb/1008046) by opening a command prompt on the Connection Server and type: vdmexport > vdmconfig.ldf

  2. Connect to ADAM via ADSI Edit (kb.vmware.com/kb/2012377)

  3. Expand OU=Properties, OU=Global then right click CN=License and choose Properties.

  4. Scroll down to pae-LicenseKey2, choose Edit, and remove all entries.

  5. Wait 2 minutes for ADAM to replicate to other brokers (if applicable) then go verify View is unlicensed in View Administrator. If you run into any issues, you can follow the first KB I linked above to restore the ADAM database.

Share: