We currently have 2 View Environments, our production 5.3 and a new 6.1.1 environment that we want to migrate all users to eventually. However, due to application configurations and other initiatives, we need to keep both environments up and migrate some users faster than others (company separation). We do not currently proxy any of our View connections through our F5 cluster and just use DNS to point to either internal or external connection server with RSA enabled through a View Security Server. So, would it be possible to have a single connection point that will redirect you to your View Connection server based on something like an AD group membership? We would need this to work with Zero clients, Windows clients, Mac, etc. We have a lot of un-managed devices so it would be nice to be as seamless as possible. I have configured the Horizon View iApp 1.2.1, but I'm assuming I could possibly do this with an iRule and this iApp? I'm not an expert on this by no means, so please excuse me if I'm not asking the right questions or understanding the full capabilities. Any help would be greatly appreciated. Thanks!

Hi, If you use the iapp to create the initial config, then you should be able to modify the access policy, I've not tested it but this is the approach I would take, assumes native proxy mode and same RSA/AD servers. Run iapp to create config for 6.1Create 5.1 CS poolCreate Remote Desktop same as iapp generated one but with 5.1 CS poolEdit access policy and add AD Query item after AD AuthConfig AD Query to branch to existing View Client Resource Assign based on attribute for 6.1 user and another branch to new View Client Resource Assign configured the same as iapp Resource Assign but with 5.1 Remote Desktop cheers

Hi, guys... Just some thoughts here... This is definitely possible, with some caveats. There's logic that can be used to achieve what you're trying to do using our Dynamic Session Detection/username persistence solution for your internal users. Right now, it's iRules "but" we'll be releasing a beta iApp very soon via DevCentral that will help automate the entire setup. For internal users, we can use this iApp/Username persistence, as it already has logic to route internal users by AD group. The external side is where it gets trickier because of the RSA integration. The username persistence iRule/beta iApp will not support RSA, since there's an extra layer of authentication to deal with. Additionally, some folks use different ID's for RSA than Active Directory - which makes locating users a more challenging. How many users access your View environment externally vs. internally? Justin

Justin, Thanks for the reply. That does sound like a viable solution. Right now all of our users connect both internally and externally (roughly 400). While there are many that have a zero client at their desk, we may give them the option of connecting from home using an RSA token. When a user connects internally, will their PCoIP traffic bypass F5 and communicate between the client and desktop? I have been tossing around the idea of upgrading our 5.3 setup to 6.2 and look into Cloud Pod Architecture. Not sure if this will help, and I'm not exactly comfortable upgrading our production environment unless it's necessary. I would be interested in testing out the iApp when it's released. Do you have any ETA? Thanks! Jason

Internally, yes - the connection is handed off and will not pass through the BIG-IP. For external users, you may want to consider pass/proxying the traffic using the APM PCoIP Proxy, since we can then use some simple logic to route users to the right View Pod based on AD membership. If you choose to do this through Security Server with RSA, we can't do anything (as I mention above). Regarding Cloud Pod - not sure if this will help, since you have to merge pools together through the use of global entitlements. Also, you will need to upgrade your legacy environment. Regarding the iApp, I am waiting to test one item and then we'll release to BETA on DevCentral. Hoping to have that wrapped up this week (fingers crossed)... Justin

Makes sense. As for the RSA piece, why couldn't I just setup a separate iApp using the current load-balancing APM? The external IP will resolve differently anyway. I was able to get APM to select the appropriate View Connection Server based on AD groups, it just proxied everything through it, which I don't want for Internal. For external, I would definitely want that. The beta iapp could be setup for Internal only.

VMware View iApp Proxy - Two View Configurations - Route Based on AD Group

11 Replies

arpydays
Nimbostratus
Aug 31, 2015
Hi, If you use the iapp to create the initial config, then you should be able to modify the access policy, I've not tested it but this is the approach I would take, assumes native proxy mode and same RSA/AD servers.

Run iapp to create config for 6.1
Create 5.1 CS pool
Create Remote Desktop same as iapp generated one but with 5.1 CS pool
Edit access policy and add AD Query item after AD Auth
Config AD Query to branch to existing View Client Resource Assign based on attribute for 6.1 user and another branch to new View Client Resource Assign configured the same as iapp Resource Assign but with 5.1 Remote Desktop

cheers
Justin_Venezia_
Cirrus
Sep 08, 2015
Hi, guys...

Just some thoughts here...

This is definitely possible, with some caveats. There's logic that can be used to achieve what you're trying to do using our Dynamic Session Detection/username persistence solution for your internal users. Right now, it's iRules "but" we'll be releasing a beta iApp very soon via DevCentral that will help automate the entire setup.

For internal users, we can use this iApp/Username persistence, as it already has logic to route internal users by AD group.

The external side is where it gets trickier because of the RSA integration. The username persistence iRule/beta iApp will not support RSA, since there's an extra layer of authentication to deal with. Additionally, some folks use different ID's for RSA than Active Directory - which makes locating users a more challenging.

How many users access your View environment externally vs. internally?

Justin
- JSinclair_21981
  Nimbostratus
  Sep 08, 2015
  Justin, Thanks for the reply. That does sound like a viable solution. Right now all of our users connect both internally and externally (roughly 400). While there are many that have a zero client at their desk, we may give them the option of connecting from home using an RSA token. When a user connects internally, will their PCoIP traffic bypass F5 and communicate between the client and desktop? I have been tossing around the idea of upgrading our 5.3 setup to 6.2 and look into Cloud Pod Architecture. Not sure if this will help, and I'm not exactly comfortable upgrading our production environment unless it's necessary. I would be interested in testing out the iApp when it's released. Do you have any ETA? Thanks! Jason
Justin_Venezia_
Cirrus
Sep 08, 2015
Internally, yes - the connection is handed off and will not pass through the BIG-IP.

For external users, you may want to consider pass/proxying the traffic using the APM PCoIP Proxy, since we can then use some simple logic to route users to the right View Pod based on AD membership.

If you choose to do this through Security Server with RSA, we can't do anything (as I mention above).

Regarding Cloud Pod - not sure if this will help, since you have to merge pools together through the use of global entitlements. Also, you will need to upgrade your legacy environment.

Regarding the iApp, I am waiting to test one item and then we'll release to BETA on DevCentral. Hoping to have that wrapped up this week (fingers crossed)...

Justin
- JSinclair_21981
  Nimbostratus
  Sep 08, 2015
  Makes sense. As for the RSA piece, why couldn't I just setup a separate iApp using the current load-balancing APM? The external IP will resolve differently anyway. I was able to get APM to select the appropriate View Connection Server based on AD groups, it just proxied everything through it, which I don't want for Internal. For external, I would definitely want that. The beta iapp could be setup for Internal only.
Justin_Venezia_
Cirrus
Sep 08, 2015
That will work as well...
- JSinclair_21981
  Nimbostratus
  Sep 09, 2015
  Awesome. I'll look for the beta iApp. Thanks again!
JSinclair_21981
Nimbostratus
Sep 16, 2015
Just wanted to check in and see if you have a release date yet, and where I should be looking for it. Thanks again for your help!
Justin_Venezia_
Cirrus
Sep 18, 2015
We don't have a release date - we are working through 1 or more issues that are important for consistency and scalability that we would like to get addressed before the BETA. Feel free to check in regularly to see where we are at. I am hoping we'll have these 2 last remaining issues closed out very soon.

Justin
- JSinclair_21981
  Nimbostratus
  Sep 21, 2015
  Sounds good..looking forward to testing it!
JSinclair_21981
Nimbostratus
Nov 05, 2015
Any updates? I haven't seen any beta iApp's for View lately. Just wanted to check in and see if there's one down the pipe. Thanks!

Forum Discussion

VMware View iApp Proxy - Two View Configurations - Route Based on AD Group

11 Replies

Recent Discussions

Client certificate Authentication - open multiple tabs

google autenticator broken barcode

Chrome V 124+ on MacOS - Virtual Server Access Issue

vulnerabilities (CVE-2020-36363), CVE-2016-0736,CVE-2019-6593-FOR VERSION BIGIP LTM-16.1.4

Port Group on F5OS network setting

Related Content

Configure the F5 BIG-IP as an Explicit Forward Web Proxy Using LTM

Can APM be configured with two proxy addresses

BIG-IP VE VMWare Cluster HA triggering configuration

Integrating SSL Orchestrator with McAfee Web Gateway-Transparent Proxy

Configuring VMware Fusion for Device Services Clustering