Upgrading Workspace Portal to VMware Identity Manager (vIDM)

In this post, we'll be upgrading an HA Cluster of Workspace Portal 2.1.1 to vIDM 2.4 per the official documentation instructions. Some technical knowledge of pgAdmin and other tools is assumed in the official guide, so hopefully this post can help fill the gaps.

Step 1: Break the HA configuration

Upgrading requires us to temporarily revert to a single-node configuration which is a little daunting to hear, but fortunately it's much easier than reverting all the steps it took to create the cluster in the first place. If you don't have Workspace setup in HA mode, then you can move on to Step 2.

1. Verify you see more than 1 node listed when running curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' // This means there are multiple nodes in the cluster, just like you configured it to be.
   


2. Launch pgAdmin and connect to the primary node
   


3. Expand Databases > saas > Schemas > saas > Tables
   


4. Find the Table called ServiceInstance and right click > View Data > View Top 100 Rows
   


5. Your nodes should all be listed here. Go ahead and delete all rows except for the master node
   


6. Perform the same steps for the FailoverConfiguration Table, but make sure to delete all rows


7. Run curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' again and ensure only 1 node is returned
   


8. Now we need to update the Load Balancer in place to only use the master node. This will likely be different for most people since not everyone uses the same LB. In my case, I'm using NGINX as a Reverse Proxy. Consult your Load Balancer's documentation to achieve this step.

Step 2: Perform an Online Upgrade

1. Verify the prereqs. There are actually quite a few but the big ones are:
   
   
   
   1. Verify there is at least 2.5GB of space on root available
      
   
   
   2. Take a snapshot of the Workspace vApp
   
   
   3. Take a snapshot of the Workspace Database (if on an external DB server)
   
   
   4. Verify you can reach vapp-updates.vmware.com (where the update will be downloaded from)
      
   
   
   5. In the Map User Attributes page, make distinguishedName a required attribute, if you plan to sync Citrix-published resources (XenApp) to vIDM.
   
   
   6. Unjoin the master node from the Domain (Required if if coming from Workspace 2.1.0 and if planning on configuring HA cluster... Workspace 2.1.1 does not require this).
   
   
   
   


2. On the Appliance Console, run the following commands to verify vIDM 2.4 shows available:
   /usr/local/horizon/update/updatemgr.hzn updateinstaller
   /usr/local/horizon/update/updatemgr.hzn check
   


3. Run /usr/local/horizon/update/updatemgr.hzn update to update the appliance
   


4. If it completes successfully, you should be prompted to reboot the VM
   

Congratulations! Workspace has now been upgraded to vIDM! You should be able to confirm this in the blue console window.

Reconfigure the HA Cluster

If you would like to reconfigure the HA cluster, follow the below steps:

1. In the vSphere console, clone the master node. It may save time if you power down the master node before cloning.


2. Name the clone whatever you want, and we'll configure it's FQDN after.
   


3. Once the clone operation is complete, edit the vAPP properties of the VM to configure it's FQDN (Hostname) and IP. These must be unique values (as in, different than the master node).
   
   


4. Click ok and power on (first power on the master node before powering on the clone if need be).


5. The initial boot will check for a new hostname and IP and if they're different than the master, it will pass as a clone, then get autoconfigured as necessary. Once the boot is complete and the blue console screen is visible, login as root and type the following commands to ensure you see all the nodes in the cluster (in this case, 2 nodes)
   

   curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'

   
   

   rabbitmqctl cluster_status

   
   


6. Now add the clone back into your Load Balancer's configuration. Once again, you must consult your LB's documentation in order to complete this step.


7. You can perform this cloning operation as many times as needed to build out your HA cluster. You can also perform these steps at any time - the HA cluster does not have to be built out right away.

What about my old slave-nodes from 2.1.1?  -- These can be deleted or stored for backup/reference use. The new vIDM cluster will not be referencing or using them in any way.

Post-Upgrade Configuration

The official post-upgrade steps can be found here, but here are some additional things to check:

• Ensure admin users and end-user accounts can both login to the portal. If you have trouble using one of the domain users to log in, then in an upgraded environment, append /SAAS/login/0 to the login URL using the local admin account. For example, if your login URL is https://myco.example.com, you would change it to https://myco.example.com/SAAS/login/0.


• Re-join the domain if you had left it prior the upgrade


• Verify apps and desktops launch as expected (a View sync may be a good idea at this point - Keep in mind View Sync should only be enabled on 1 node)


• Upgrade end-user's Desktop Clients to version 2.4. Be sure to uninstall the current Workspace Desktop Client, then install the 2.4 client.

I hope you've found this post helpful in upgrading your Workspace Portal deployment to vIDM! Let me know in the comments how it went!

Read More

VMware Identity Manager (vIDM) Web App Integrations

Our vIDM (FKA Workspace Portal) developers are hard at work delivering SAML-based SSO integration documentation for Web apps and other 3rd party identity provider integrations. Since previous versions of Workspace had a "This functionality exists.. so good luck!" mentality, I'm really excited to share a new landing page for these support resources:
https://www.vmware.com/support/pubs/vidm_webapp_sso.html 

At the time of this post, white papers are available for

• AirWatch Applications


• Office365


• Salesforce


• ServiceNow


• Webex


• vIDM and ADFS 2.0

Read More

Workspace Portal, Access Policies, and Kerberos authentication

You've decided it's time to expand your Workspace Portal deployment from internal-only, to also allow external access. You've setup your Load Balancer, gotten your certificates in place, and now you're tasked with configuring internal and external authentication methods.

This post covers the configuration needed for Kerberos on internal connections, while allowing username/password authentication from external connections.

Access Policies

First, let's setup your access policies. Access Policies allow you to specify criteria that users must meet in order to access Workspace Portal. We're going to configure the Default Access Policy Set to include two policies: internal and external

For our internal connections, we're going to utilize Kerberos. Configuring Kerberos isn't covered in this post, so ensure you have it working first. Here are some helpful posts for setting it up:

Configuring Kerberos for Workspace
Kerberos SSO in Workspace 1.8 (basic config flow still applies to Workspace Portal 2.1)

For our external connections, we'll let our users utilize their Active Directory synced username and passwords for authentication. Ensure your Directory Sync rules from the Connector Service Admin page include all desired AD groups and that they're synced regularly.

First: ensure you've created both an internal and an external Network Range:

1. Log into the Workspace Admin Portal > Settings > Network Ranges


2. Click + Network Range to add our internal range. Configure this to the appropriate subnets used in your LAN.


3. We'll use the default ALL RANGES entry for our external connections

Then, from the Policies tab, we'll edit the default_access_policy_set to correspond to these network ranges.

1. Click + Access Policy and name it internal. Set it to use a Minimum Authentication Score of 1. 


2. Then select the default 'web policy' which corresponds to our external network range. We'll set this to a Minimum Authentication Score of 2 as seen below:

NOTE: Be sure to re-arrange the policies so that internal is on top, and 'web policy' is on bottom and click Save.

Authentication method

Now, head to Settings > Authentiation Methods and order the options as seen here. Be sure to click each entry to edit the Authentication Score to match the below screenshot. Once again, order is important.

Notice that Kerberos is on top, with an authentication score of 1.

Set Kerberos as the Default Method

Password will be set to an authentication score of 2.

At this point, you should be able to verify that your user portal loads from both internal and external locations, as well as verify that your internal users aren't prompted for their credentials.

Troubleshooting

Scenario 1:

When launching Workspace Portal externally, the page times out and doesn't load, but internally it launches.

Scenario 2:

When launching Workspace Portal externally, the page loads, but internally, users are prompted for username and password (Kerberos fails to login the user)

   - In either case, verify the order of your Access Policies have Kerberos on top, password on bottom. Also verify that the scores are set appropriately, per the screenshots

Read More

Workspace Portal Administrative Consoles

Workspace Portal has had a few facelifts over the years. Some remember the Horizon Workspace 1.x days of the multi-vm vApp where 5 different VMs were responsible for 5 different services. One difficulty resulting from this architecture was different VMs, with different URLs, that had different settings. This vApp then went down to 4 VMs with Workspace Portal 2.0, and now all necessary services are handled in a single-vm vApp with Workspace Portal 2.1, simplifying deployment and configuration.

The configuration, however, done through Workspace's administrative links can still be a bit daunting to the new administrator.

Workspace Portal has 3 primary locations used to customize and configure the appliance. These 3 locations, or "Quick Links" can be accessed from https://:8443



Set it and forget it.

The first link is the Appliance Configurator. I like to think of this link as the "Set it and forget it" link. When you configure the settings from this page, you won't need to access the page very often anymore - things like your FQDN and your database connection. Clicking on this link, you'll notice it prompts for your Admin password you initially setup upon first connecting to Workspace, which brings us to the Configurator Admin page

NOTE: you can also access this page directly by navigating to https://:8443/cfg/setup



The most important settings configured from this page are the Database, SSL Cert, and FQDN. The optional settings are for setting up a syslog server, changing admin/ssh account passwords, and generating support log bundles. If you're ever opening up a support request with VMware Support, be sure to include a log bundle collected from this location.

Connecting services to Workspace Portal.

Next we'll look at the Connector Services Admin link. Think of this as where we'll "connect" Workspace to other services in your environment, whether it's your existing Active Directory users and groups, Horizon View desktops and hosted apps, SaaS applications, and the authentication methods for said services.

NOTE: you can also access thsi page directly by navigating to https://:8443/hc/admin/about



Finally you have the Workspace Admin Portal. Think of this as where you refine the end-results of your working instance. From here, you can access a tab called Settings which has some misceallaneous settings - things from obtaining SAML Metadata for your SaaS service providers, to tweaking your Authentication Methods for your synced internal and external users.

Related Documentation:
Introduction to Workspace for Administrators

Read More

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!

Read More

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

Troubleshooting changing the Workspace Portal FQDN
Apply Public Certificate Authority to vIDM

Using SSL Certificates in Workspace

Apply Workspace Root Cert to the Load Balancer

Read More

How to setup NGINX as a reverse proxy for Workspace Portal 2.1

Per Workspace Portal's installation guide,

During deployment, Workspace is set up inside the internal network. If you want to provide access to Workspace for users connecting from outside networks, you must install a load balancer, such as Apache, nginx, F5, and so on, in the DMZ.

This process is unfortunately outside of VMware's Documentation scope as every environment is different and we do not recommend a particular vendor/service over another.

NGINX, however, is a free and robust option that can at least get you up and running for your external users fairly quickly. This won't be a comprehensive how-to, but should certainly be useful in getting you started!

In this example, we'll be using Ubuntu Server 12.04 for the NGINX server. I performed a default install and enabled only the OpenSSH service during install. Once Ubuntu is installed and has the desired IP and hostname, go ahead and install nginx: sudo apt-get install nginx

Now you can configure nginx.conf to include all the reverse proxy information in a single file, however, in my setup, NGINX needs 3 things in order to work with Workspace:

1. nginx.conf


2. default.conf


3. SSL Certificates

Here is a copy of what my nginx.conf looks like: /etc/nginx/nginx.conf (HUGE thanks to Tomi Vakala from vReality)

_______________________________________
# nginx configuration file
# hws21

# User to run nginx processes as. Ensure this user exists on your system!
user hadmin;

# Worker processes
worker_processes 4;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
    multi_accept on;
    # Use epoll on Linux, kqueue on *BSD and Mac OS X
    use epoll;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    # Enable sendfile for improved performance on Linux
    sendfile on;

    # Enable nagle algorithm to buffer more data before sending
    tcp_nopush on;

    keepalive_timeout 65;

    # Setup client buffers
    client_body_buffer_size 256k;
    client_header_buffer_size 2k;

    # Enable gzip compression
    gzip             on;
    gzip_buffers     128 8k;
    gzip_min_length  512;
    gzip_proxied     any;
    gzip_types       text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
    gzip_comp_level  3;

    include /etc/nginx/conf.d/*.conf;
}

# eof
_____________________________________

Next, we need to configure the default.conf which we told nginx.conf to include toward the end of the file.

The default.conf  (/etc/nginx/conf.d/default.conf)  you'll create and customize for your environment. The things you'll need to customize are:

1. server_name (this is the public facing FQDN)


2. ssl_certificate (your certificate's full chain)


3. ssl_certificate_key


4. proxy_pass (what nginx is proxying to - the internal Workspace instance name)


5. [Updated] proxy_redirect off;
   -- I originally missed number 5 here in my config and it caused issues when enabling Kerberos in my environment. More on proxy_redirect here

________________________________________

# /etc/nginx/conf.d/default.conf

# hws2.1

 

server {

    # IPv4 listen directive, enable SSL

    listen 443 ssl;

 

    server_name workspace.vcloud.local;

 

    server_tokens off;

 

    # Strict Transport Security (HSTS), force browser to use encrypted

    # connection to this site at all times

    add_header Strict-Transport-Security "max-age=31536000;";

 

    # Configure SSL

    ssl on;

    ssl_certificate /etc/ssl/workspace_chain.crt;

    ssl_certificate_key /etc/ssl/workspace.key;

    ssl_session_cache shared:SSL:50m;

    ssl_session_timeout 10m;

    ssl_prefer_server_ciphers on;

    # Set list of preferred ciphers to enable use of ciphers with perfect

    # forward secrecy to improve security

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM- SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK';

 

    # Reverse proxy directives

    location / {

        proxy_pass https://hws21.vcloud.local:443/;
        proxy_redirect off;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_read_timeout 1800;

        proxy_connect_timeout 1800;

        proxy_http_version 1.1;

        proxy_max_temp_file_size 5m;

 

        # Increase proxy memory buffers

        proxy_buffering on;

        proxy_buffer_size 32k;

        proxy_buffers 16 32k;

        proxy_busy_buffers_size 32k;

    }

}

 

# eof

___________________________________

If you're not much of an SSL wizard, the following two links will be extremely useful in setting up an internal CA with openSSL, then generating your internally signed certs (assuming you don't have Third Party CA signed certs)

How to setup a CA

The Most Common OpenSSL commands

Once default.conf and nginx.conf have been configured, and your certificate is valid, you should be able to start nginx. If the service fails to start, it should indicate which component it's having an issue with, whether it's one of the .conf files themselves, or the provided certificate or key file.

The next steps would be to then login to the Workspace Configurator portal at https://:8443/cfg/setup

Click on Install Certificate > Terminate SSL on a Load Balancer. Here you can install the root CA cert from the Load Balancer. Then under Workspace FQDN you can set your new public FQDN.

If you have issues changing your FQDN, check out this excellent troubleshooting blog on VMware Blogs

Good luck!

Read More

How to patch Shellshock in Workspace Portal

VMware has released official bash patches for Horizon Workspace and Workspace Portal to address the recently discovered shellshock bug.

Be sure to review kb.vmware.com/kb/2091067 as you must apply the correct patch for your exact version of Workspace.

How to tell if your Workspace instance is currently vulnerable

To test, run the following command on each VM in the appliance:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

A system vulnerable to shellshock will show output similar to this:

Here is how you can patch your Workspace servers:

1. Head over to vmware.com/downloads and select your current version of Workspace. in this example, we'll be using Workspace Portal 2.1


2. Download the listed RPM update at the bottom of the page
   


3. Copy the downloaded patch to /tmp on your Workspace VM (use something like SCP or WinSCP to accomplish this). If you are on an earlier Workspace instance with multiple VMs in the Workspace appliance, you'll need to do this on all the VMs.
   


4. Login to the Workspace VM as root, and unzip the patch
   


5. Change directory to the unzipped folder, and apply the patch by running
   rpm -U --nodeps *.rpm
   
   


6. Run the test command from above again to verify you aren't still vulnerable

 

Read More

Running Workspace Portal 2.1 in VMware Workstation 10

With the release of Workspace Portal 2.1, the vApp has been reduced to a single VM providing simpler deployment and administration. [See my post What's New in Workspace Portal 2.1] This also means it's extremely easy to run inside of VMware Workstation or Fusion. In this post, we'll be covering how to import Workspace Portal 2.1 into VMware Workstation.

Why would you want to run Workspace Portal in a desktop solution like Workstation?

Well it's by no means a production solution. It does provide a decent lab environment at best though! This is great for tinkering with the product before implementing in a vSphere environment. You can get a pretty good idea for how the product flows. If you happen to have a more advanced home lab setup in Workstation already (With Active Directory, vCenter Server, etc). If you don't, luckily there is a Demo User Store that can be selected during the Web GUI configuration which will create dummy accounts for you and use an embedded OpenLDAP instance on the VM. Pretty cool!

More info on using the Demo User Store here

To install Workspace Portal 2.1 in Workstation:

1. Download the Workspace Portal 2.1 OVA


2. In Workstation, choose File > Open


3. Configure your desired Name and Location, and choose Import


4. Review the details of the VM
   
   


5. Power on the VM, and you'll run through the Setup Wizard
   
   
   
   1. Choose [1] for a complete installation
   
   
   2. Enter [y] to accept
   
   
   3. Next configure your hostname, DNS, and IP settings
   
   
   4. When done, hit [q] to continue, then [y] to confirm
   
   
   
   


6. After it performs its initial boot and configuration, you'll see the familiar Login screen with an IP address.
   
   NOTE: in this example, we're using a Bridged network connection. This can be verified and configured under VM > Settings > Network Adapter


7. In my setup, I want to be able to access Workspace with the hostname I provided earlier in the setup. In order to do that, I need to modify my computer's /etc/hosts file. My daily OS is Linux Mint, so I will perform this via the command line:
   
   
   
   1. First ensure you can ping the appliance from the IP listed in the console window
      ping 192.168.3.161
   
   
   2. Then add an entry for the appliance in the hosts file
      vi /etc/hostsThe entry should follow this format:
      FQDN shortname
      
      e.g., 192.168.3.161 workspace21.mycomputer.local workspace21
   
   
   
   


8. Once your hosts file is updated, you should be able to ping the appliance by the name you gave it.


9. Final step is to open a browser and login per the console window's instructions!
   
   

Next Steps: Run through the web GUI to further configure the appliance. See my post on Installing/Configuring Workspace Portal

Read More

Installing VMware Workspace Portal 2.1

The Workspace vApp design and deployment has been dramatically simplified in this release. If you've dabbled with Workspace in the past, got frustrated with the vApp complexity, and ended up putting it on the shelf - now's the time to revisit this amazing product.

Some things that make Workspace Portal 2.1 easier to deploy than previous releases:

1. Single VM - Workspace is now a singular VM handling all its services. No more SSHing to other VMs within the vApp and messing with proxy over and over.


2. No more IP Pools - the requirement of IP Pools is a thing of the past. Hooray!


3. No more vCenter dependency - deployment doesn't require vCenter URL and credentials


4. Much faster deployment - the vApp deploys with 4 VMDKs by default and takes much less time than previous instances.

NOTE: Older instances of Workspace cannot be upgraded to Workspace Portal 2.1. Instead, a migration is required. Please see the Migration Guide here: http://pubs.vmware.com/workspace-portal-21/topic/com.vmware.ICbase/PDF/workspace-portal-21-migration.pdf  And see my post covering this process (coming soon)

Installation:

1. Deploy the OVA like normal (In vCenter, File > Deploy OVF Template)
   
   
   
   1. In the Properties section of the deployment, Ensure "Connector Only Install" remains UNchecked.
   
   
   2. Set your correct timezone settings (this will affect vApp time and log times)
   
   
   3. Opt in/out of the Customer Experience Program
   
   
   4. If you don't want to rely on DHCP, enter the FQDN, Default Gateway, DNS, IP, and Netmask for the appliance.
      
   
   
   
   


2. Once the vApp is deployed, power it on. You'll be greeted with familiar instructions to navigate to your Workspace Portal's URL for configuration
   
   


3. Once you're there, you'll see a new configuration wizard


4. Notice you can now configure separate passwords for root, sshuser, and your administrator accounts
   
   


5. 
   
   New in the Map User Attributes page is an attribute for DaaS (Desktone), the distinguishedName
   

   

   
   


6. 
   
   Once setup is complete, it will link you to the Admin Dashboard!
   

   

   
   

Official Workspace Portal 2.1 Installation Guide

Read More

What's New in VMware Workspace Portal 2.1

VMware's Workspace Portal was just brought to version 2.1. This release comes with some exciting changes and new features that make this the best Workspace release yet.

Simplified Deployment - Workspace is now a single VM (still deployed as an OVA). This architectural change makes SO MANY things easier including log locations, configuration changes (like Proxy settings), and much more. The single Connector-va service within the vApp is capable to handle most AD environments. Additional instances can be cloned for high availability and unique domain configurations.

Another handy tidbit is that (finally!) the Bind DN account used during deployment to perform the initial user sync will be added/synced itself by default. Hooray!

AirWatch and Desktone integration - AirWatch 7.3 and Desktone 6.1 can be fully integrated with SSO using Workspace Portal 2.1

All new Dashboard with reporting  - I might be the most excited about this one. Out of the box, the new Admin Dashboard shows incredibly useful reporting data such as user engagement, historical trends, system health, and active users. I'm happy to report that this dashboard also dynamically updates - no need for manual refresh (not pointing fingers... Horizon View...)

Also new is the Administrative Service Links (aka, QuickLinks). Going to https://:8443 will take you to a shortcuts page to perform administrative tasks like configure SSL certificates, administer user entitlements, and manage user authentication.

Check out the official Release Notes for Workspace Portal 2.1

Related Posts:

Installing Workspace Portal 2.1

Upgrading Workspace Portal 2.1 [Coming Soon]

Read More

Accessing Horizon Workspace Gateway-va URL fails with HTTP 404 Error

Symptoms

• HTTP 404 Error accessing gateway


• Service-va logs show something similar to
  
  com.vmware.horizon.analytics.exception.HorizonException: Setting up Message Broker connection failed: Connection refused


• Running df -h on the service-va shows /db as full

Cause

 

The internal Postgres Database is full and must be expanded. This article does not apply to Workspace implementations that have an external database configured.

 

 

Resolution

 

To resolve this issue, add a new, large VMDK to the service-va and copy the contents from the old disk to the new one. This process works on service-va VMs with and without internet access.

 

1. Take a snapshot of the service-va


2. Power off the Workspace vApp


3. Add a VMDK to the service-va
   
   3a. Right click the service-va and choose Edit Settings > Add > Hard Disk and choose Create new virtual disk
   3b. Ensure the new disk is at least 30GB in size


4. Power on the service-va VM only and login as root


5. Change to run level 1
   
   init 1
   
   5a. Verify you are in Run Level 1 by typing who -r


6. Determine the name of the new disk (e.g., /dev/sdxx)
   
   fdisk -l


7. Format the new disk with default parameters
   
   fdisk /dev/sdxx
   n (for new partition)
   p (for primary partition)
   Press Enter to accept Partition Number Default
   w (to write changes)


8. Unmount /db (first take note of the device name, e.g., /dev/sdb1)
   
   umount /db


9. Copy the contents of /db (in this example, /dev/sdb1) to the new partition
   
   dd if=/dev/sdb1 of=/dev/sdxx bs=1024
   
   NOTE: This copy operation may take a long time


10. Resize the filesystem using resize2fs
    
    e2fsck -f /dev/sdxx
    resize2fs /dev/sdxx


11. Mount /dev/sdb1 to /db
    
    mount /dev/sdb1 /db


12. Update /etc/fstab to reflect the new partition mounted at /db


13. Run this command to shutdown the service-va 
    
    shutdown -h now


14. Power on the Workspace vApp.
    
    NOTE: be sure to commit the snapshot previously taken after verifying the environment is stable

Read More

Working with Horizon Workspace Virtual Users and zmprov

One nifty feature of Horizon Workspace is the ability to share files and folders with external users. An "external user" could mean one of two things:

1. A directory server user not synced to Horizon Workspace


2. Someone outside of the enterprise

An invited user is then created as a virtual user in the Workspace instance. You can find more information about virtual users in the Horizon Workspace Administrator's Guide under User and Group Types: http://hrzn.ws/1nqI0ZS

When a virtual user is created, they are assigned to a hidden Class of Service (COS) called defaultExternal. This class of service comes with its own parameters, notably, all virtual users are defaulted to a file upload size of 2GB. You may notice the following error when a virtual user tries to upload a file larger than 2GB:

exceeds single file maximum upload size 2147483648 bytes

Additionally, the virtual user will share the quota of the internal user that shared the file with them. So if the inviter has an unlimited quota, files the invitee uploads won't have a negative impact. Conversely, if the inviter has a 10GB limit, any file the invitee uploads will go toward that internal user's 10GB quota.

So how can we increase the virtual user's file upload size limit?

Though the defaultExternal COS is hidden in the Administration Console, you can still configure its attributes via the data-va command line.

 

To change the upload file size limit for virtual users:

1. Login to the data-va as root


2. Change to the zimbra user:
   
   sudo su - zimbra


3. Switch to the virtual user tenant and modify the upload attribute to the desired file size limit, in bytes:
   $ zmprov
   prov> st __virtual__
   prov> mc defaultExternal hzndataFileUploadMaxSize filesize-in-bytes
   prov> mc defaultExternal hzndataFileUploadMaxSizePerFile filesize-in-bytes
   prov> quit
   
   
   
   
   
   
   
   
   
   
   
   

   

   Increasing virtual user file upload limit to 3GB

   
   


4. Restart the service
   
   zmcontrol restart

Note: to clear the Tenant specifier back to default, use the unsetTenant command:

$ zmprov

prov> ut

To view all COS, you can use 'gac.' Notice my example below doesn't show defaultExternal because I do not have any virtual users:

Additionally you can run "zmprov gac -v" which will show all the configured attributes for each COS. The process outlined above can be used to edit any COS manually. Keep in mind a COS you've created in the Administrator Console GUI will be in the default tentant, not the __virtual__ tenant.

Happy modding!

Read More