Eric Monjoin
Staff Consulting Architect but also pilot, spending time in front of my computer or flying in the air...

Tagged: Horizon

ADFS with VMware Unified Access Gateway (UAG)

This article talks about configuration of ADFS with VMware Unified Access Gateway without the use of Workspace One Access.

There’re two use cases here to configure ADFS with Unified Access Gateway

  1. Use Case #1: ADFS as MFA, so users first authenticate using ADFS, and then authenticate using standard credential to get the list of available resources (desktop or apps)
  2. Use Case #2: ADFS for single authentication method, so users will authenticate once with ADFS and then will connect to VDI VMs or published apps without the need to enter any other credentials. This use case of course required VMware TrueSSO to works

Initial configuration is the same for both and to make it short here the different steps required:

  1. Change Expiration Period for Service Provider Metadata
    1. https://my-virt.alfadir.net/index.php/2022/01/12/change-the-expiration-period-for-service-provider-metadata-on-connection-server/
  2. Deploy UAG
    1. Configure Edge Service and specify a Connection Server fqdn (not the load-balancer)
    2. Check connection is working
  3. Connect to <federation fqdn> and save the FederationMetadata.xml file
  4. Import FederationMetadata.xml in UAG (Upload Identity Provider Metadata)
  5. Configure UAG for SAML or SAML and Passthrough auth methods
  6. Specify Identity Provider
  7. Download SAML Service Provided .xml file
  8. Configure ADFS
    1. Add a new Relying Party Trusts
    2. Specify UAG SP .xml file as source
    3. Configure Claim Issuance Policy
  9. Connect to UAG as “client”
    1. Auth using ADFS
    2. Auth using AD credential

Now if we want to go further and implement ADFS with TrueSSO:

  1. Generate SAML IdP Settings
    1. Import signed cert or use Generated one
    2. Copy Content of Download IDP Settings
  2. Configure Horizon Connect Server for SAML auth with UAG and ADFS
    1. Connect to admin console of Horizon Connection Server
    2. Add SAML Authenticator for UAG
      1. Mode Static
      2. Past Content of UAG Download IDP Settings
      3. Change EntityId if required
    3. Add SAML Authenticator for ADFS
      1. Mode Static
      2. Past Content of FederationMetadata.xml
  3. Enable TrueSSO for UAG and ADFS
    1. Using vdmUtil, enable both authenticator
  4. Check True SSO connection
    1. Connect to UAG as Client
    2. Once authenticated to ADFS, the list of available resource appears, and you can login without any other cred

That said, let see with some nice pictures how we do that :

Continue reading…

AppVolumes 2103 (4.4) Tools – Off line packaging for both AppVolumes On-Prem and on Azure

One of the great update from AppVolumes 2103 (aka 4.4) is now you can install only App Volumes Tools and package applications offline from a simple VM on VMware Workstation for example and produce the same package for App Volumes on Prem (.vmdk file) and for App Volumes on Azure (.vhd files). So exactly the same package for both environment.

So let me describe how I created my “Capture and Build” VM, how to capture and import your applications….

Continue reading…

Adding Static Route to WS1 Access

I had a request from Spanish colleagues about adding static routes to Workspace One Access (in their case it was because of database in a different network).

I first had a look on our internal channel on Slack and find a first way to do it … but with Identity Manager version 3.3. However, when I try to test it in my Home Lab using my on-premise WS1 Access 20.10 it was totally different. vIDM 3.3 is based on Suse Linux when WS1 Access 20.10 is based on Photon 3. After some exchange by mail with my colleagues, they sent me the procedure they used for their deployment… different for the first two !!!
Yes they deployed Workspace One Access 20.01…

Basically both method work with vIDM 3.3 and Workspace One v20.01 as both are running Suse Linux

Method 1 : for Identity Manager 3.3 and WS1 Access 20.01: (thanks to Mahmood Ramzan for this one)

First edit “routes” files in /etc/sysconfig/network

vi /etc/sysconfig/network/routes

Then add your route in this form : <net_range>/<mask> <gateway> <interface>

10.1.2.0/24 192.168.12.254 eth0

Then restart your network and confirm the route is persistent:

# /etc/init.d/network restart
# ip route list

Method 2 : for Identity Manager 3.3 and WS1 Access 20.01: (thanks to Javier Perez for this one) :

After connecting to WS1 using sshuser and sudo as root (or direct login as root), create the ifroute-eth0 file

# vim /etc/sysconfig/network/ifroute-eth0	

Add your route (same format as for vIDM 3.3)
and set permission on this file:

# chmod 644 /etc/sysconfig/network/ifroute-eth0

Restart your network as explained above.

Method for Workspace One Access 20.10 and upward :
Starting with Workspace One Access 20.10, appliance are based on Photon 3.0. So adding a file call route-eth0 in /etc/sysconfig/network-scripts make it works by running /etc/sysconfig/network-scripts/ifup-routes but it doesn’t works when booting the appliance.

To add static routes to Photon appliance you need to follow this procedure :

So once logged as root edit this file : /usr/local/horizon/scripts/networkwizard.hzn

# vi /usr/local/horizon/scripts/networkwizard.hzn

Find the section “function save_sysconfig_properties” around line 800 (803 to be precise)

Alter the file to set the routes by adding the following lines in green :

function save_sysconfig_properties() {
    if [ $ETHO_DEVICE_RESTORED -eq 0 ]; then
      # any DHCP
      local DHCP=no
      if [ "$SYSCONF_IPV4_IP0" = "DHCP" -a "${SYSCONF_IPV6_IP[0]}" = "DHCP" ]; then
          DHCP="yes"
      elif [ "$SYSCONF_IPV4_IP0" = "DHCP" ]; then
          DHCP="ipv4"
      elif [ "${SYSCONF_IPV6_IP[0]}" = "DHCP" ]; then
          DHCP="ipv6"
      fi
      echo save $ETH0_CONF
      echo -n > $ETH0_CONF
      echo "[Match]" >> $ETH0_CONF
      echo "Name=eth0" >> $ETH0_CONF
      echo "" >> $ETH0_CONF
      echo "[Network]" >> $ETH0_CONF
      echo "DHCP=$DHCP" >> $ETH0_CONF
      if [ -n "$SYSCONF_IPV4_IP0" -a "$SYSCONF_IPV4_IP0" != "DHCP" ]; then
          echo "Address=$SYSCONF_IPV4_IP0/`mask2cdr $SYSCONF_IPV4_NETMASK`" >> $ETH0_CONF
          echo "Gateway=$SYSCONF_IPV4_GATEWAY" >> $ETH0_CONF
          echo "DNS=$SYSCONF_NET_DNS" >> $ETH0_CONF
          echo "LinkLocalAddressing=no" >> $ETH0_CONF
          echo "IPv6AcceptRA=no" >> $ETH0_CONF
          echo "[Route]" >> $ETH0_CONF
          echo "Destination=10.0.0.0/24" >> $ETH0_CONF
          echo "Gateway=192.168.0.250" >> $ETH0_CONF
          echo "GatewayOnlink=true" >> $ETH0_CONF
      fi
      if [ -n "${SYSCONF_IPV6_IP[0]}" -a "${SYSCONF_IPV6_IP[0]}" != "DHCP" ]; then
          local ndx=0
          while true
          do
              local tmpip=${SYSCONF_IPV6_IP[$ndx]}
              local tmppfx=${SYSCONF_IPV6_PFX[$ndx]}
              if [ -z "$tmpip" ]; then
                  break
              fi
              echo "Address$ndx='$tmpip/$tmppfx'" >> $ETH0_CONF
              ndx=$(($ndx + 1))
          done
      fi
    fi
}

Reboot the appliance to ensure it works fine

App Volumes, load balancer health check

I recently had an issue with one of my App Volumes server: even if my server was down in an App Volumes point of view (connection lost the database), my Kemp load balancer see it up and running because: the web interface was up and favicon.ico was also available.

The template for App Volumes (part of Horizon 7 Template) is, in my opinion not complete and it missed the right way to configure health check

So the right way to configure load balancer ‘s health check is the following :

For Kemp :

VMware Horizon on Windows Server Core 2019

I recently have a customer requesting to install VMware Horizon on a Windows 2019 Core server. Most of customers prefer to have the “Desktop Experience” but for security reason some other prefer to limit to shell only interface.

Before installing VMware Horizon, ensure that all updates are applied to Windows 2019 Core (I had some strange behavior before doing that, like impossible to have the Flex Admin console or get “Login failed” on the new HTML 5 consoles)

The first main concern is getting signed certificate ready so Horizon will use it instead of its self signed certificate.

After copying the certificate in a local folder :

1 ) From the Administrator command prompt, type “powershell” to execute PowerShell command

Composer Firewall Port

Ok by default Composer must be in the same domain or at list have Trust Relationship with domains where Linked Clone will be deployed….

But with Composer you can also deploy on other domains, the caveat however is that you can’t browse the OU on Horizon Admin console so you need to Copy/Past or write the full path for the correct OU.

That said, if you look at the firewall port required by Composer, unless 18433 between Horizon Connection Server (brokers) and Composer plus 1433 to join the Ms SQL Server, nothing is really explained and a doubt can exist about which port is required (and also who create account in the domain). So here the answer 🙂 :

First I confirm, Composer server is responsible to reach the AD domains and create Computer accounts. So the required port are :

Source                  Destination        Ports                 Service

Composer           AD Controllers   88/TCP                  Kerberos

Composer           AD Controllers   135/TCP               RPC

Composer           AD Controllers   389/TCP               LDAP

Internal View Composer error – another reason..

Ok, I know that View Composer is depreciated but sometime we don’t have other choice to use it, eg. when you need to deploy VMs is a more cost effective way than Full Clone on domain with no Trust Relationship with the one on which the brokers is joined to.

So I have a customer who have 3 domains with trust relationship:

  • dom-adm for all admin account
  • dom-res for all computers account (composer and brokers are on this domain)
  • dom-usr for all users accounts

We created a service account in dom-adm for Composer and added it to “Administrator” local group in Composer server.

When I tried to add Composer server on Horizon admin console, it failed with the “Internal View Composer error. Contact your administrator.” message and absolutely nothing into the log, both on Composer and Horizon logs (sic.)

I first suspected an issue with the certificate but even after putting a signed certificate the issue was the same.

Finally I created a service account for Composer in the dom-res domain and used it to add Composer on my vCenter… and it worked !!