Forum Discussion

Jeff_Giroux's avatar
Jeff_Giroux
Icon for Cirrus rankCirrus
Jun 02, 2014

View User Name Persistence vs_ad_auth Not Loading from iRule view_ssl_auth

Hi, I'm working on a VMware View deployment for a customer. The user name persistence is not getting through it's entire flow in regards to the iRules. I have included a bunch of info below. My problem is that the "view_ad_auth" virtual server is not being hit when called from within the "view_ssl_auth" iRule which is attached to the initial connection broker virtual server.

 

P.S. I have already opened a support case for this issue, but given that the user name persistence iRule set is basically maintained by devcentral community...I'll ask here too.

 

What are the exact steps to make the issue happen?

 

regular iApp

 

1. Followed deployment guide and created iApp for View using http://www.f5.com/pdf/deployment-guides/vmware-view5-iapp-dg.pdf

 

2. Tested connection to VS with View Client and it works fine. I can connect to desktop every time

 

3. At this point, I know the View environment works, the iApp works, my client works, and the access policy works.

 

Adding username persistence iRules and items

 

1. Then I followed the devcentral doc https://devcentral.f5.com/wiki/iApp.VMware-Applications.ashx to add username persistence using the "Advanced Load Management" doc

 

2. Followed deploy doc steps, added iRules to virtual servers as instructed, then tested my View Client again.

 

3. View Client makes a successful connection hitting the initial HTTPS connection broker VS "view-west_proxy_https"

 

4. If no connection is found, that first VS "view-west_proxy_https" has an iRule attached and is supposed to call the "vs_ad_auth" VIP according to the deploy guide

 

5. The vs_ad_auth VIP is never hit and therefore the rest of the "username persistence" is not functioning.

 

6. I have tried placing multiple log commands as well as enabling the static:: debugging variable to watch all logs. I cannot determine why the vs_ad_auth rule is not getting hit.

 

 

What is the expected behavior? - the sequence of flow is documented in the devcentral "Advanced Load management" deploy guide page 5 mentioned above. Here's a quick summary of what should happen.

 

1. View Client connects to F5 VIP "view-west_proxy_https" and has attached iRule "view_ssl_auth"

 

2. F5 runs iRule "view_ssl_auth" to determine if there is an existing username-to-desktop mapping

 

3. If no connection found, iRule basically sets "virtual vs_ad_auth" to call the "vs_ad_auth" VIP

 

4. The "vs_ad_auth" VIP has an iRule attached "username_sql_apm" that checks for user/group mappings in AD to determine which POD user should access

 

5. Meanwhile in the background, the eventsDB iRules and healthchecks are running in order to query the View events DB and build a local F5 connection table based on username and desktops.

 

 

What is the actual result?

 

1. View client connects to VIP "view-west_proxy_https", iRule triggers

 

2. no connection found which should cause "vs_ad_auth" VIP to hit

 

3. vs_ad_auth is never hit

 

4. F5 serves desktop to View Client as if I didn't have the iRule or any username persistence logic even added at all

 

 

What is the frequency of reproducing the issue?

 

every time

 

What servers are involved and what are their versions?

 

Windows 7 desktop client with horizon view agent 5.3

 

Windows 2008 R2 domain controller

 

Windows 2008 R2 Horizon View 5.3 connection server

 

 

APM version and build?

 

11.5.1 HF2

 

Is this VMware View?

 

VMware Horizon View? yes

 

Connection server version? 5.3

 

vCenter server version? not using it

 

VMware Horizon View Client? yes

 

VMware Horizon View Client Version? 5.3

 

What version of os is running on? Windows 7

 

HTML5 connection? not using it

 

 

APM
application delivery
deployment
devops
iApps
iRules
LTM
security

2 Replies

Sort By
  • Greg_Crosby_319's avatar
    Greg_Crosby_319
    Historic F5 Account
    Jun 02, 2014

    Are you using ssl offload or bridging to your Connection servers? Is your vs_ad_auth vip using 443 or 80 and if it is 443 do you have a client and server ssl profile attached?

     

    It would be helpful to see were the communication is failing, are you able to include a sanitized LTM log during a view client connection request?

     

  • Jeff_Giroux's avatar
    Jeff_Giroux
    Icon for Cirrus rankCirrus
    Jun 02, 2014

    SSL Offload to the connection servers. The vs_ad_auth VIP is also 80. All relevant logs are in the support case C1587416 if you have access to look. I'll also send you a separate email with the actual /var/log/ltm and /var/log/apm logs combined which is also on the ticket.

     

    I've tried stipping the view_ssl_auth down to the basics but still cannot get it to fire the vs_ad_auth VIP. According to what I know, the below 2 examples should both trigger the "virtual [name] line and call the vs_ad_auth VIP. Only the 2nd example works.

     

     

    Code

 FIRST TEST BROKEN DOWN TO BASICS 

 THIS NEVER CALLS THE vs_ad_auth VS when "virtual [name]" is inside HTTP_REQUEST_DATA
when HTTP_REQUEST {
    HTTP::collect
}
when HTTP_REQUEST_DATA {
    log local0. "inside call to vs_ad_auth"
    virtual vs_ad_auth
}


 SECOND TEST BROKEN DOWN TO BASICS 

 When "virtual [name]" is inside regular HTTP_REQUEST", the "virtual [name]" command triggers the "vs_ad_auth" virtual server fine
 test rule to trigger a "virtual [name]" statement
when HTTP_REQUEST {
    HTTP::collect
    log local0. "inside call to vs_ad_auth"
    virtual vs_ad_auth
}