Jump to content
Welcome to our new Citrix community!

multiple Virtual Servers - routing based on IP or AD-group


Mark Norton

Recommended Posts

Good morning,

 

I have a bit of a specific scenario that I'm trying to find a solution for.

 

I have two independent on-prem XenApp farms - an old v6.5 farm and a new v1912 farm. Staff are slowly being transitioned from the old to the new farm.

 

I run a single ADC v13 to provide external access to the v6.5 farm. ADC is connected to AD. The ADC currently has two virtual servers - both accessing the v6.5 farm. vServer1 is enforcing MFA, vServer2 is bypassing MFA.  The routing is done based on the client-IP using 'listening priorities' and 'listening policies' within the respective virtual servers (e.g. CLIENT.IP.SRC.TYPECAST_TEXT_T.CONTAINS_ANY("MFA_Whitelist_SingleIP")). After successful authentication, both virtual servers forward to a Citrix WebInterface.

 

I now need to add external access for my v1912 farm while retaining existing access to the v6.5 farm. v1912 access needs to be based on AD group-membership and once authenticated, forwarded to an internal StoreFront. I have added a 3rd virtual server for v1912 access. It's up and running but I can't use AD group-memberships within the listening policies as that's not supported. 

Routing my v6.5 users through the new StoreFront is not an option as some of the client computers are old and run unsupported browsers.

 

I'm running out of ideas and need some help.

 

I basically need to end up with a construct like this where ADC loops through these based on the scenario:

 

  1. User in in group 'newXenApp' -> run MFA challenge & go to StoreFront
  2. User is in group 'new XenApp' and IP is whitelisted -> bypass MFA & go to StoreFront
  3. User is not in group 'new XenApp' -> run MFA challenge & go to WebInterface
  4. User is not in group 'new XenApp' and IP is whitelisted -> bypass MFA & go to WebInterface

 

Thanks

 

Link to comment
Share on other sites

[edited] I'm going to revise this answer, as I saw you mention external access, so I assume that means with Gateway. I'll add the original thoughts below this.

 

If you are going to provide separate access to legacy WI/xa farm and NEW StoreFront/CVAD environment, you don't need the content switching/lb to do it. The listen policies don't help with the user group decision at all. And gateway needs to know which environment it is talking to for this to work.

 

If both sets of users go to the same Gateway, then the gateway session policy can base decisions of which storefront store or WI site to send you too based on the GROUP and IP list.  It will work best with separate session policies going to separate lb vservers for storefront1 and legacywi environment.

 

The gateway would have to be able to use advanced authentication AND you'd have to test that it will still frontend WI just fine.

1) Define the lb vserver for storefront and the lb vserver for wi:  lb_vsrv_stf and lb_vsrv_wi

2) On the Gateway, you would need an advanced authentication config with the authentication vserver integration.  The Group Extraction policy Or a username/password prompt would be your first factor authentication and then based on GROUP and/or IP address the second factor would be triggered.   The authentication design is the trickier part of if you don't know how nfactor policies are configured to do the MFA or not.  See a partial example here of setting up a 1) group extraction policy and then 2) a Ldap only login vs. ldap/radius based on group membership. This would have to be tweaked slightly for your scenario AND to handle the ip filter:  https://support.citrix.com/article/CTX220793

 

3) The gateway session policies would then determine whether user goes to store

session_pol1_newsite   policy expression:  aaa.user.is_member_of("<newgroup>")  session profile:  storefront store settings... via lb_vsrv_stf

session_pol2_legacyfarm policy expression:  !aaa.user.is_member_of("<newgroup>") session profile:  wi settings via lb_vsrv_wi

Gateway needs to KNOW there are different storefronts and WI servers involved in the different session policies.  Be sure gateway had complete list of all STAs.

 

I would still test to confirm that this version of gateway + wi will work against your legacy environment and the same gateway + stf will work against the new environment.

 

My original thoughts before I re-read your post:

Are these for Gateway users so the decision of which storefront or WI to hit is after gateway authentication OR is this purely storefront load balancing, in which case the ADC can't make a user-group decision without integration AAA vserver in front of storefront.  

 

Content Switching/Load Balancing alone is unlikely to solve this if you are trying to use one FQDN and store path to hide this from Users; CS could sort traffic based on Source IP only.  Separate access urls for old wi and new storefront would be ideal instead. If its behind the gateway connection, then the gateway can use both source IP and user group membership after authentication  to direct users to legacy WI/XA farm vs. New Storefront/CVAD/XD 7.x environment.

 

I know you said you can't, do this but I'm going to throw the comment out there (though I know its not what you asked):
StoreFront might front end a 6.5 environment; though 6.5 is no longer supported:  https://discussions.citrix.com/topic/408205-storefront-1912-and-xenapp-65/. 
So getting your 6.5 only users to storefront and then let storefront switch between LegacyFarm and NewSite (1912) would make this a much easier thing.   
 

Edited by Rhonda Rowland
updated answer
Link to comment
Share on other sites

Hi Rhonda,

 

Thanks for your comprehensive and quick reply and apologies for the lack of details in my initial post.

 

14 minutes ago, Rhonda Rowland1709152125 said:

Are these for Gateway users so the decision of which storefront or WI to hit is after gateway authentication OR is this purely storefront load balancing, in which case the ADC can't make a user-group decision without integration AAA vserver in front of storefront.  

 

The decision on which way to go is to be made after authentication. We're using the ADC purely as an external gateway to access internal XenApp resources, no loadbalancing/no content switching. All it does is authenticate the user against AD and forward it to a WebInterface which lives on an internal server.

 

I'm using different external (and internal) FQDNs for old and new access. The Netscaler runs on a wildcard cert so at least that bit was easy.

 

19 minutes ago, Rhonda Rowland1709152125 said:

If its behind the gateway connection, then the gateway can use both source IP and user group membership after authentication  to direct users to legacy WI/XA farm vs. New Storefront/CVAD/XD 7.x environment.

This is exactly what I'm trying to achieve but tbh not sure where to start as I need to cover all scenarios

 

- old with MFA

- old w/o MFA based on IP

- new with MFA & AD-group

- new w/o MFA based on IP & AD-Group

 

Our ADC is a bit of an unloved stepchild to be fair. We appreciate it, we feed it updates every so often but no one understands it entirely and we don't dare to change it ;)
 

22 minutes ago, Rhonda Rowland1709152125 said:

I know you said you can't, do this but I'm going to throw the comment out there:

StoreFront can front end a 6.5 environment; though 6.5 is no longer supported:  https://discussions.citrix.com/topic/408205-storefront-1912-and-xenapp-65/

So getting your 6.5 only users to storefront and then let storefront switch between LegacyFarm and NewSite (1912) would make this a much easier thing.   

Are you dealing with clients older than Win 7? Or is Win 7 the oldest? There's still a wide range of "out of support" considerations and legacy client versions...but it *might* work.  IE 11 and later (which is win 8.1/Win 7).

Yes, thank for your comment here as well. I had my 6.5 connected to StoreFront and that was very straightforward. The major issue though is that a lot of my clients are W7 Embedded ThinClients with IE8/IE9. Storefront 1912 requires IE11 as a minimum and updating these ThinClients is an absolute pain. We have a hardware refresh coming next year so I'm trying to push this away as far as possible.

 

Thanks

Link to comment
Share on other sites

I won't be able to do more until after work; so if someone else can answer you before hand, hopefully they will.

 

Which version of ADC are you running and do you have access to the advanced authentication engine?  (Really hard to do conditional two factor on a single gateway in classic engine; better off with separate gateways)

 

I think your issue is more with configuring the authentication flow then the session policies. The article I gave you is a step in the right direction, but the flow would take a little bit to adjust for your needs.

Link to comment
Share on other sites

Hi Rhonda,

 

Thanks for your response and taking the time to help me with this quest.

 

My ADC is running version 13.0 82.45.nc at the moment. I don't think I have access to Advanced Authentication.

 

MFA is being taken care of by my RADIUS. I have one RADIUS-server enforcing Azure MFA and a 2nd one with no MFA. I have a RADIUS-policy for each on the ADC and assign them to the Virtual Servers as required.

 

Hope that makes sense.

 

Kind regards

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...