Deploy Horizon Cloud on Azure – Part 3: Configure General Settings

by Ian · 12th August 2020

Quick Links

Part 2 – Deploy Horizon Cloud Infrastructure

Part 3 – Configure General Settings (This Post)

Part 4 – Deploy Windows 10 Multi-Session Host Image

Background

Following on from the previous two parts in the series, where we configured Azure and deployed the Horizon Infrastructure services, we will look at integrating with Active Directory and how to access the Horizon service.

Configuration

Active Directory Integration

Before proceeding with this section, it is worth noting that we need at least 3 Active Directory accounts configured and one security group. They are used for the following purpose.

Bind account – Allows Horizon services to contact Active Directory using LDAP protocol. Does not need admin permissions, only read permission.
Auxiliary bind account – The same as above, but a backup account. You can use the same account for both but it will generate a warning.
Domain join account – This will be the account used to join desktop machines to the domain. This account should have enough privileges to perform this task.
Horizon admin security group – A security group used to access the Horizon Cloud services.

First things first, log back into the Horizon Cloud portal, navigate to the General Setup section, and click configure.

You will then presented with the following screen. In step 1, define the DNS and NetBIOS name for the domain. My demo domain is called Horizon-Cloud

In steps 2 and 3, enter the details for the bind accounts I mentioned at the beginning of this section.

In the advanced section, you can change the LDAP connection port if required and change the base search DN for the domain.

On the next screen, enter the DNS server details, define the Organisational Unit that desktop machines will be placed into when they are deployed, and enter the details for the domain join account. You can specify a secondary domain join account if you wish, but it is not essential.

The DNS server in this instance is the domain controller and also the same DNS server the VNET in Azure utilises.

On the following screen, define a security group that will be used to access the Horizon Cloud service. This group will become a Super Administrator group.

And click save. If the process worked, you will be automatically logged out of Horizon Cloud.

Log back into the portal as you have done previously with your MyVMware account details.

There is now a second authentication prompt when logging in, which is to provide domain credentials. Use an account that is a member of the Horizon admins security group.

And you should now be successfully logged back in.

I tried the login process above when the domain controller was powered down. You are still able to login with the My VMware credentials only to perform maintenance tasks on the Horizon pod.

Additional Config

When you have completed the AD integration, you will see a screen similar to below, however, the Broker and Cloud monitoring services will not be configured. as shown in my screenshot.

I will show you what each option provides.

Roles and Permissions

Nothing much to this one, you have already seen it :). You can add additional security groups here and define different role-based permissions.

Broker

This is an interesting one for me. At the time of deployment, this was not mentioned in the VMware quickstart guide. This may have since been updated though. There are two options here which I will run through in the screenshots.

The broker address is the gateway address to many different Horizon pods.

The default option is to define a subdomain on the vmwarehorizon.com domain. I will come back to the custom domain.

I am not sure how the mapping works for this as the public IP returned on an NSlookup defined for my deployment on mydomain.vmwarehorizon.com is not the same as the public IP address defined on the UAG load balancer in Azure.

On the next screen, you can enable 2FA if you wish. I show below what options are supported. I am still surprised that there is no integration with Microsoft MFA or 3rd party Identity Providers / MFA Providers when this functionality exists in Horizon 7.11 and above.

I chose not to enable 2FA for this demo environment.

If you are familiar with Horizon on-premises deployments, then the options below are no surprise. Define how long a user session and authentication token should be valid for.

It is nice to see an option to wait for a VM to be powered on. I will show why this is useful in Part 4 of the blog series.

Or if you chose the custom route, you can create a broker FQDN on your own domain. This time though when importing the certificate it has to be in PFX format and with a password!

In part 2 the certificate had to be in PEM format and without a password. Just something to watch out for. Once you click next on the screen below, you have the same options as shown above for 2FA and session timeout.

And then for my setup in public DNS, I created a CNAME record to point my own domain to the vmwarehorizon.com domain. It seems to work fine this way.

Cloud Monitoring Service

And finally, you can choose to turn on the cloud monitoring service if you wish.

And that’s it. Check out Part 4 where I look at deploying Windows10 Multi-Session hosts through Horizon Cloud on Azure

Part 1 – Azure Environment Preparation