Piszki Lab | EN

My case study in the clouds…

Horizon Workspace: F5 BIG-IP and multiple instances of the connector-va.

| 0 comments

In this post I will explain further configuration of Horizon Workspace 1.8.1 and F5 BIG-IP. We passed the stage of balancing traffic to duplicate gateway-va machines, now we will replicate the connector-va machine. In addition to balancing traffic, We configure everything so that it was possible “Windows” authentication type and set option “Enable redirect” to access from the Internet. As a result, the computer that is located away from AD domain, may still use Kerberos authentication when accessing ThinApp applications (available directly from the portal Workspace).

conn1

Based on the diagram it is easy to guess that the virtual address connector-va must be fully accessible from the Internet and local area network (configured NAT). He must have also configured with the correct FQDN (correct local and Internet PTR record in DNS) and import the valid SSL certificate (in the Horizon Workspace, the best solution is a wildcard certificate). Certificate of connector-va machine is generated each time using a script wizardssl.hzn, in F5, we will use the same SSL profile that we created for workspace.pulab.pl address.

The configuration of the whole start of the preparation of the local DNS record for a new machine connector-va. Then log in to the machine configurator-va and issue the following command:

ughocf1:~ # hznAdminTool addvm –type=CONNECTOR –ip=172.18.30.59 –useGatewayAsIDP=n –directoryPassword=xxx –activateOnly=n –maintenanceMode=n

conn4

In accordance with the principle that each new machine at the Horizon Workspace is a clone of recently generated (this applies to service-va and gateway-va) or a cloned snapshot created during installation (this applies to connector-va and data-va (template)) before generation another, always properly configure the previous one. To do this, log in to the new instance of the connector-va ( https://ughocn2.pulab.local:8443/hc/admin ), configure the connection to the AD domain and perform all the steps in the “Setup Wizard”. With one exception, except the first instance, all subsequent need to have disabled the option Directory Sync.

conn3

This option is useful when using multiple domain AD (multiforest). If you want to use it, and a new connector-va was added to a different domain than the original, before the first sync, it should be to add new users store (in the admin section of Horizon Workspace Setting-> User Stores). If we do not, or if you do not disable the “Directory Sync” on one AD domain, users attempt to synchronize completed with the “Sync actions can not be calculated at this time. Please try again later (User store not found for sync client). “

conn5

At this stage, its all when it comes to configuring the connector-va, the next step is to prepare an external DNS record for the virtual F5 address (connector.pulab.pl) and properly configure the local NAT address. Once this is done, we can proceed to configure the BIG-IP F5. Start by adding nodes and prepare the pool:

conn6

Contrary to what you can find online, F5 Monitor https_head_f5 is not suitable for monitoring gateway-va or connector-va. Although F5 everything is illuminated in “green” in the logs machine accumulates a lot of entries “not supported method of access to the site”. If anyone does not mind that you can leave, but it is safer to use a monitor icmp_gateway (or prepare proper monitor).

conn7

Balancing We set to a standard priority, the least loaded member of the pool.

conn8

At the end we create a virtual server. We do it the same way as we did in the case of gateway-va. Absolutely not are required for the steps described here (establish ssl trust), we provide this a SSL profile.

conn9

For this virtual server will use the same profile “persistence” as in the case of gateway-va.

conn10

This is the so-called “sticky session”, according to the documentation, Horizon Workspace SSL session expiration time in the load balancer must be greater than 30 minutes.

conn11

At this point, F5 configuration is completed, we have a properly configured virtual server with connected the two connector-va.

conn12

To do the remaining last two steps, log on to all new connector-va and in the section “Identity Provider” rename “IdP hostname” to be compatible with our FQDN record (connector.pulab.pl). Because we use SSL profile on the F5 do not need to change anything in the “SSL Certificate” (ie, locally we have an SSL certificate compatible with local CA and remote wildcard certificate!).

conn13

Now log in to the admin panel and under “Settings-> Identity Providers” change the order so that the first on the list is the machines from our pool F5.

conn14

As you can see in the figure, the Application Manager detects a change of address “IdP hostname” this is correct and consistent with our requirements. That’s all. If you have the impression that the entire installation of Horizon Workspace becomes unstable, it is good after such modifications in the environment, restart the entire vApp. In our LAB this setup works without any problem.

At the end, yet another note, remember that the computer account in AD domain (each newly generated connector-va) to add to the permissions of the directory from which ThinApps are made ​​available to connector-va! That the “Setup Wizard” ends properly, including ThinApp applications synchronization, does not mean that everything is ok. If we do not add computer accounts to the directory, no error will be displayed, but applications do not synchronize. The more, applications do not copy locally with the option “Enable account based access” and Agents installed with the option HTTP_DOWNLOAD will not be able to download the application.

horr1

 

Was this information is helpful? Tell me, please leave a comment!

Source

Rate this article:
[Total: 0    Average: 0/5]

Author: Piotr Pisz

Computer always, since I got a Commodore 64 at the end of primary school, through his beloved Amiga and Linux infinite number of consoles, until today, fully virtual day. Since 2001, Unix/Linux Systems Administrator, for seven years a faithful companion and protector of Solaris system, until his sad end. In the year 2011 came in the depths of virtualization, then smoothly ascended into the clouds and continues there today. Professionally working as Systems Architect in the Polish Security Printing Works.

Leave a Reply

Required fields are marked *.


.

Enjoyed the post? Support Piszki Lab | EN, click on the AD! :-)

.