Home > Blogs > Horizon Tech Blog

Setting up Kerberos Single-Sign-On (SSO) access in Horizon Workspace 1.5

One of the most commonly asked questions amongst customers and partners are how-to setup Kerberos Single-Sign-On (SSO) into Horizon Workspace. Therefore I decided I should create this detailed step-by-step blog post on how to configure Kerberos in Horizon Workspace version 1.0 and 1.5.

Configuring Kerberos SSO into Horizon Workspace greatly enhances the end-user experience. If the end-user login to their domain joined desktop and access the Horizon Workspace web portal they will not be asked to sign-in once more, but are allowed access based on their Kerberos token. The Horizon Client version 1.5.2 also makes use of Kerberos SSO. Seamless to the users the Horizon Client will try to authenticate to the Horizon Workspace using Kerberos. If successful no further interaction from the end-user is required. This is especially useful in a Horizon View environment using non-persistent floating desktop pools.

First some background of my environment, hopefully this helps with the print screens throughout this blog post.

  • My Active Directory domain name: pinata.local
  • My publicly accessible Horizon Workspace instance: https://workspace1.myhorizondemo.com
  • I have an internal Microsoft CA which I will use to issue a trusted certificate for my internal connector.

In order to activate Kerberos SSO there are some prerequisites.

  • You cannot use the first connector, automatically created upon deployment of Horizon Workspace, for Kerberos SSO.
  • The second connector configured to handle Kerberos SSO must have a Fully Qualified Domain Name (FQDN) in the same Active Directory domain namespace, as you will authenticate your users. For example, in my case my AD domain is pinata.local. Therefore my connector must have a hostname in that domain name space. I will in this blog post use the hostname: int-connector.pianta.local.
  • In order for Internet Explorer (and the Horizon Workspace Client) to support passing Kerberos tokens to the connector your clients must:
    • Trust the certificate on the connector
    • The connector and Horizon Workspace FQDN should be in Local intranet security zone.
    • Internet Explorer must have Internet Options – Advanced – Enable Integrated Windows Authentication enabled.

  • In order to create the second connector you must have both forward and reverse DNS records for the new appliance. In my case I’ve created a DNS record for int-connector.pinata.local pointing to and a reverse record using the same information.

So let’s get started. First thing is to create the new virtual appliance of the internal connector.

1. Create the second connector

1.1.  SSH into your configurator-va using SSHUSER (same password as root which was specified by you during the CLI based setup of your Workspace instance).

1.2.  Run command:

 root –

1.3. Run command:

hznAdminTool addvm --type=CONNECTOR --ip= --useGatewayAsIDP=n --directoryPassword=BindDN_ADPassword
ip= is the ip-address of your new connector (must correspond to your DNS settings)
useGatewayAsIDP=n is very important. This will tell Horizon Workspace not to use the common namespace of your Horizon installation when redirecting users to this connector. Remember, in order for Kerberos to work we must access the connector with a FQDN within the AD domain.
directoryPassword= Is your Bind DN password. The Bind DN is the first administrator created in Horizon Workspace and is the user you specified for AD sync operations.

1.4.  Verify all parameters are correct and type Y and hit Enter

1.5.  Once completed, verify there where no error messages and that a new connector appliance have been created within the vApp of Horizon Workspace.

2. Create a trusted certificate for your new connector

2.1.  When I generate certificate requests I use OpenSSL version 0.9.8. I think it is by far the easiest method. You can download OpenSSL for Windows here: http://slproweb.com/products/Win32OpenSSL.html. If you are a Mac user you already have OpenSSL on your machine.

2.2.  Create a OpenSSL configuration file using a text editor other than Notepad (on Windows I prefer Notepad ++ and on Mac TextWrangler). This file will be dictating the parameters for your certificate.

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = SE
stateOrProvinceName = Stockholm
localityName = Stockholm
0.organizationName = pinta.local
organizationalUnitName = IT
commonName = int-connector.pinata.local

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS: int-connector.pinata.local, DNS: int-connector, DNS:

Change all red entries to fit your implementation. Please note your commonName (CN) must be listed as subjectAltName (SAN) as well.

2.3.  Generate a certificate request using OpenSSL by running the command:

openssl req -new -nodes -out c:\cert\int-connector.csr -keyout c:\cert\private.key -config c:\cert\openssl-config.cfg


-out is your Certificate Request file which will be generated.

-keyout is the file name of the private key which will be generated. You must keep this private key safe. Without it your certificate becomes useless.

-config is the configuration file create in step 2.2.

2.4.  Open up the certificate request file in a text editor (in my case the filename is int-connector.csr). Copy the content of the file.

2.5.  Navigate to your Certificate Authority and use the CSR to request a new certificate. In my case I’m using a Microsoft CA so that’s where the print screens comes from.

Click Request a certificate

Chose advanced certificate request

Paste your Certificate Request, make sure you chose Web Server certificate template and click Submit.

Your certificate is issued. Chose Base 64 encoded and Download certificate.

Verify your certificate looks okay.

2.6.  Before we go ahead and upload this new certificate to our connector we must build a full certificate chain. My new connector does not trust my Microsoft root CA so that is why I must upload it as a part of the certificate. Luckily building a certificate chain is quite simple. The only trick is to never use Notepad because it cannot do correct ANSI formatting. First, download your CA’s root certificate.

Click Download a CA certificate, certificate chain or CRL

Chose Base 64 and click Download CA certificate

Create a new text file and paste your connector certificate into the file. Copy and paste your root CA certificate after the connector certificate.

Now you have your certificate chain. Save the file.

3. Add the new certificate to your connector.

3.1.  Login to your new connector. In my case using: https://int-connector.pinata.local:8443

3.2.  Click SSL Certificate

3.3.  Paste your certificate chain and private key into the form and click Save.

3.4.  Reboot your new connector to make the new certificate active.

3.5.  Verify your certificates are trusted. Launch a web browser on a domain member (automatically trusts my Microsoft CA) and enter the URL for your connector. In my case https://int-connector.pinata.local.

You should receive no certificate errors accessing the connector.

4. Configure your new connector for Windows Authentication (Kerberos SSO)

4.1.  Access the new connector’s admin (https://int-connector.pinata.local:8443)

4.2.  First, join the connector to the domain, click on Join domain

Fill in your domain details. You can use any user authorized to join a computer to the domain. The new connector will get a domain account created using the hostname of the connector, in my case int-connector.

4.3.  Now activate Windows Authentication by going to Windows Auth and activate Enable Windows Authentication. Make sure to Enable Redirect as well.

5. Configure identity provider order and network filter.

5.1.  Open your Workspace admin page, in my case https://workspace1.myhorizondemo.com/admin

5.2.  Navigate to Settings – Identity Providers

Click Edit on the record representing your new connector. In my case hznConnector1.

5.3.  Specify the network range for your LAN clients.

This connector will only handle clients within the specified network range. My internal network is but since I don’t use any other 10.x.x.x ranges I might as well specify the whole range.

5.4.  Next you have to move the new connector to the top in the order of identity providers.

5.5.  Now your setup should look something like below.

Horizon Workspace uses a combination of the identity provider order and network range of the connectors to decide which sessions should be using which connector. In above configuration all clients using ip-address will be rerouted to the second connector. Please note the URL for hznConnector1. This indicates clients will be redirected to the internal hostname of the second connector. Since its hostname is within the AD domain name space Kerberos tokens can be used.

6. Verify your setup

6.1.  Make sure your client is setup according to the prerequisites mention in the beginning of this post.

–       Trusts the certificate of the new connector

–       Connector and workspace FQDN are listed as Local intranet sites

–       Internet Explorer is configured to pass Kerberos

–       Client must be within the specified network range and a domain member

6.2.  Launch Internet Explorer and navigate to your Horizon Workspace URL, in my case https://workspace1.myhorizondemo.com.

Notice the automatic redirection to your Kerberos configured connector.

Once the connector have authenticated the user using Kerberos the user are automatically redirected back to Workspace URL.

If you have followed all instruction correctly your user should now have been automatically signed in to Horizon Workspace.

Deploying Horizon Client version 1.5.2 or later will utilize the Kerberos sign-in as well.

Please note. If you are using VMware ThinApp and/or VMware Horizon View desktops brokering you must configure the second connector to mirror the settings of your other connector. If not users may fail to launch their View desktops. The connector you authenticate against is the View and ThinApp settings you will get.

6 thoughts on “Setting up Kerberos Single-Sign-On (SSO) access in Horizon Workspace 1.5

  1. Pingback: VMware Horizon Tech Blog: Setting up Kerberos Single-Sign-On (SSO) access in Horizon Workspace 1.5 | Virtual-Blog

  2. BrianK

    Thanks for putting together this guide! I tried to enable single sign-on with the default connector and that didn’t turn out so great. We had single sign-on inside the network, but you had to log in twice from outside, so we promptly turned it off. Getting it going should be a piece of cake with these instructions.

    Please keep up with providing Horizon Workspace content like this article. There isn’t much information out there on the product, so I feel like I am winging it quite a bit!

  3. Brian W

    Excellent article, this will help me greatly as I begin pilot testing Horizon Workspace and View. How would user accounts in a child AD domain be handled by this configuration?

    1. Peter Bjork

      That should work – the requirement is that the connector-va FQDN must match the SPN value in the domain it is joined to.

  4. Pingback: Configure Kerberos SSO in Horizon Workspace 1.8 | Horizon Tech Blog - VMware Blogs

Comments are closed.