Author: Carl Stalhood

SmartAccess / SmartControl – Citrix Gateway

Last Modified: Aug 3, 2024 @ 9:39 am

55 Comments

This article applies to NetScaler Gateway 14.1, Citrix Gateway 13.x, Citrix Gateway 12.1, and NetScaler Gateway 12.0.

Navigation

💡 = Recently Updated

Change Log

SmartAccess / SmartControl

SmartAccess and SmartControl let you change ICA connection behavior (e.g. disable client device mappings, hide icons) based on how users connect to Citrix Gateway. Decisions are based on Citrix Gateway Virtual Server name, Session Policy name, and Endpoint Analysis scan success or failure.

SmartAccess vs SmartControl:

  • SmartAccess lets you control visibility of published icons, while SmartControl does not.
  • SmartControl is configured exclusively on Citrix Gateway, while SmartAccess requires configuration on both Citrix Gateway, and inside Citrix Studio.
  • SmartControl requires Citrix ADC Premium Edition licensing, while SmartAccess is available in all Citrix ADC Editions.
    • Both features require Citrix Gateway Universal licenses for every concurrent connection.

Prerequisites

Both SmartAccess and SmartControl have the same prerequisites. You can configure SmartAccess in Citrix Virtual Apps and Desktops (CVAD) at any time, but it won’t work, until you do the following:

  1. Citrix ADC appliance license: See Feature Licensing in the Gateway Tweaks post. In summary:
    • SmartAccess is available in all editions of Citrix ADC appliances.
    • SmartControl is available only in Citrix ADC Premium Edition.
  2. Citrix Gateway Universal Licenses – On the Citrix ADC, go to System > Licenses, and make sure you have Citrix Gateway Universal Licenses allocated to the appliance.
    1. Most Citrix ADC Editions (except Citrix Gateway Enterprise VPX) come with built-in Gateway Universal licenses: Citrix ADC Standard Edition = 500 licenses, Citrix ADC Advanced Edition = 1,000 licenses, and Citrix ADC Premium Edition = unlimited licenses.
    2. Additional Citrix Gateway Universal licenses can be acquired through other means. See Feature Licensing in the Gateway Tweaks post for details.
    3. The Universal licenses are allocated to the hostname of the appliance (click the gear icon to change it), not the MAC address. In a High Availability pair, if each node has a different hostname, then you can allocate the licenses to one hostname, then reallocate to the other hostname. See Feature Licensing in the Gateway Tweaks post for details.
  3. Citrix Gateway must have ICA Only unchecked.
    1. On the Citrix ADC, go to Citrix Gateway > Virtual Servers, and edit your Gateway Virtual Server.
    2. In the Basic Settings section, click the pencil icon.
    3. Click More.
    4. Uncheck the box next to ICA Only, and click OK. This tells Citrix Gateway to start using Universal licenses and enables the SmartAccess and SmartControl features.
  4. Enable Trust XML on the Citrix Virtual Apps and Desktops (CVAD) Site/Farm:
    1. On a CVAD Controller, run PowerShell as Administrator.
    2. Run asnp citrix.* to load the snapins.
    3. Run Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true to enable Trust XML.
  5. Configure Callback URL in StoreFront:
    1. In StoreFront Console, right-click the Stores node, and click Manage Citrix Gateways.
    2. Edit a Gateway.
    3. On the Authentication Settings page, make sure a Callback URL is configured. The Callback URL must resolve to a Citrix Gateway VIP on the same appliance that authenticated the user. The Callback Gateway’s certificate must match the FQDN entered here. If you are configuring Single FQDN for internal and external, then the Callback FQDN must be different than the Single FQDN.

Once the prerequisites are in place, do the following as detailed below:

Endpoint Analysis

Endpoint Analysis (EPA) scans are completely optional. You can configure SmartControl and SmartAccess without implementing any Endpoint Analysis.

Endpoint Analysis is supported on Windows and Mac devices. Other devices, like iOS and Android, do not support Endpoint Analysis. If you want to allow mobile device connectivity, then make sure you have an access mechanism (e.g. ICA Proxy) that works if the Endpoint Analysis scan fails.

Citrix ADC 12.1 and newer support two methods of doing EPA: nFactor EPA, or Classic EPA. Classic EPA will no longer be supported in ADC 13.1 and newer so you should eventually switch to nFactor EPA.

Workspace app on Windows supports EPA when configured using nFactor EPA. Workspace app does not support Classic EPA.

nFactor EPA

EPA can be one of the factors of an nFactor flow. EPA can be performed before authentication, or after authentication.

EPA doesn’t work on iOS/Android. To skip those platforms, see CTX572334 Eliminate Advanced Endpoint Analysis scans on Mobile devices/iOS.

  1. Create an nFactor EPA Action.
    1. The easiest way to find EPA is to use the Search box on the top of the left menu. Or, navigate to Security > AAA > Policies > Authentication > Advanced Policies > EPA.
    2. The EPA Editor link on the right-side of the Expression box lets you configure EPA Expressions. See OPSWAT EPA Expressions below for more details on how to configure an Opswat expression.
    3. For SmartAccess based on the results of the EPA scan, configure the Default Group field with a new group name (doesn’t exist in Active Directory). You’ll later use the Group name in a Session Policy and use the Session Policy name in your Citrix Policy Access Filters or Delivery Group Access Control. Default Group probably only works if the EPA Factor is performed after authentication.
  2. After creating an EPA Action, create an Advanced Authentication Policy of type EPA and select the EPA Action you created earlier.
    1. The expression is either true, or an expression that defines who needs EPA scanning. If you are configuring post-authentication EPA, then you can use group membership (e.g. AAA.User.Is_Member_Of()) expressions.

  3. Create a Policy Label for the EPA Factor. Login Schema should be LSCHEMA_INT.

    1. Bind the EPA Policy to your Policy Label.
    2. If you don’t bind any other policies, then if EPA fails, then the user shown the Access Denied page. If you want authentication to continue even with a failed EPA scan, then bind another policy to the Policy Label.
    3. Create an Advanced Authentication Policy named similar to NoAuth and change Action Type to NO_AUTHN. Expression = true. Bind the NoAuth policy to the Policy Label.
    4. The final Policy Label should have an EPA Factor with Goto = NEXT and the second policy as NoAuth.
  4. In earlier factors that authenticate the user, when binding an authentication policy, click in the Select Next Factor field and select your EPA Policy Label.

    • In the earlier authentication factor, edit the Login Schema Profile, click More, and check the box next to Enable Single Sign On Credentials. EPA as later factor overrides the password collected in earlier factors causing Single Sign-on to StoreFront to fail and this checkbox fixes that problem.
  5. Create a Citrix Gateway Session Policy that is applied when the EPA factor succeeds.
    1. Go to Citrix Gateway > Policies > Session.
    2. On the tab named Session Profiles, click Add.
    3. Name it FullAccess or similar and click Create. The Session Profile does not need any settings.
    4. Switch to the tab named Session Policies and click Add.
    5. Select the Profile you just created.
    6. If you are doing Advanced Policies, then the Expression is AAA.USER.IS_MEMBER_OF(“GroupName”) where “GroupName” is the name of the Default Group you specified when you created the EPA Action. Click Create. If you are doing Classic Policies, then the expression is ns_true.
  6. If your session policy is Advanced syntax, then bind the Session Policy to your Gateway vServer.
    1. Go to Citrix Gateway > Virtual Servers and edit an existing vServer.
    2. Scroll all the way down to the Policies section and click the Session Policies line.
    3. Add Binding and select the Session Policy you will use for SmartAccess. Priority doesn’t matter.
  7. For both Advanced Session Policies and Classic Session Policies, create a AAA Group that matches the Default Group you specified in the EPA Action. CTX278960 says this is also required for IS_MEMBER_OF expressions.
  8. If you are doing Classic Session Policies, then create bind the Session Policy to the AAA Group. If you are doing Advanced Session Policies bound directly to the Gateway Virtual Server, then you don’t need to bind anything to the AAA Group.
  9. You can now use the Session Policy in your SmartAccess configuration. See the SmartAccess section below for more details.

Classic EPA Policies

There are two methods of Classic Endpoint Analysis: pre-authentication and post-authentication. For pre-authentication, configure an Endpoint Analysis expression in a Preauthentication Policy. For post-authentication, configure the Endpoint Analysis expression on one or more Session Policies.

  • With a Preauthentication Policy, if the Endpoint Analysis scan fails, then users can’t login.
  • With a Postauthentication Policy, Endpoint Analysis doesn’t run until after the user logs in. Typically, you create multiple Session Policies. One or more Session Policies have Endpoint Analysis expressions. Leave one policy without an Endpoint Analysis expression so there’s a fallback in case the client device doesn’t support Endpoint Analysis (e.g. mobile devices). The name of the Session Policy is then used later in Citrix Policies and Citrix Delivery Groups.
    • Inside the Session Profile is a field for Client Security expression, which supports an EPA expression. This field is for VPN only, and does not affect SmartAccess.

Preauthentication Policies and Profiles are configured at Citrix Gateway > Policies > Preauthentication.

  1. On the right, switch to the Preauthentication Profiles tab, and create a Preauthentication Profile to allow access.

  2. Switch to the Preauthentication Policies tab, and create a Preauthentication Policy with an EPA expression. Select the Request Action that allows access.

  3. The right side of the Expression box has links to create EPA expressions, as detailed below.

Classic Post-authentication Policies and Profiles are configured at Citrix Gateway > Policies > Session.

  1. When creating a Session Policy, the right side of the Expression box has links to create EPA expressions, as detailed below.
  2. Classic Syntax vs Default Syntax – EPA expressions can only be added to Classic Syntax Policies. If you click Switch to Default Syntax, then the OPSWAT EPA Editor disappears. Use nFactor EPA instead.
  3. If you edit a Session Profile, on the Security tab…
  4. Under Advanced Settings, you will see a Client Security Check String box that lets you enter an EPA Expression. This field applies only to VPN and does not affect SmartAccess. Also, this field does not function if your Session Policy is Advanced instead of Classic.

EPA Expressions

Citrix ADC has two Endpoint Analysis engines: the original Client Security engine, and the newer OPSWAT EPA engine.

OPSWAT EPA Expressions

To configure OPSWAT EPA expressions:

  1. When creating an nFactor EPA Action, click the EPA Editor link.

    • When creating a Classic Preauthentication Policy, or Session Policy, click the OPSWAT EPA Editor link.
  2. Use the drop-down menus to select the scan criteria.
  3. You will see some fields with a plus icon that lets you configure more details for the scan.

    • Note: the text in these policy expressions is case sensitive.
  4. Then click Done.

Additional OPSWAT EPA Info

See the following links for more Advanced EPA information:

Original Client Security Expressions

To configure the original Client Security expressions:

  1. When creating a Classic Preauthentication Policy or Classic Session Policy, click the Expression Editor link.
  2. Change the Expression Type to Client Security.
  3. Use the Component drop-down to select a component.
    1. A common configuration is to check for domain membership as detailed at Citrix CTX128040 How to Configure a Registry-Based Scan Expression to Look for Domain Membership.
    2. Citrix CTX128039 How to Configure a Registry-Based EPA Scan Expression on NetScaler to Look for the Active Device or Computer Name of an Explicit Workstation

Once the Classic Preauthentication and/or Classic Session Policies are created, bind them to your Citrix Gateway Virtual Server:

  1. Edit a Citrix Gateway Virtual Server.
  2. Scroll down to the Policies section, and click the plus icon.
  3. Select either Preauthentication or Session, and select the policy you already created. Then click Bind.
  4. Session Policies with EPA Expressions are typically higher in the list (lower priority number) than non-EPA Session Policies.

EPA Libraries

In NetScaler 12.0 build 57 and newer, the EPA Libraries are updated out-of-band.

  1. Download the latest EPA libraries.
  2. In the Citrix ADC menu, click the Citrix Gateway node.
  3. On the right, in the left column, click Upgrade EPA Libraries.
  4. Click Choose File
  5. Browse to one of the .tgz library files, and click Open.
  6. Click Upgrade.
  7. Click OK when prompted that EPA Library upgraded successfully.
  8. Click Upgrade EPA Libraries again.
  9. Click Choose File.
  10. Browse to the other .tgz EPA library file, and click Open.
  11. Click Upgrade.
  12. Click OK when prompted that upgraded successfully.
  13. To see the versions, click Upgrade EPA Libraries.

EPA Plug-in

The EPA plug-in is automatically deployed when the user connects to Citrix Gateway – either before the logon page, or after the logon page.

To pre-deploy EPA plug-in, see CTX124649 How to Deploy NetScaler Gateway Plug-in and Endpoint Analysis Installer Packages for Windows by Using Active Directory Group Policy. This article describes how to extract the plug-in .msi file, and deploy using Group Policy.

EPA and Portal Themes

The webpages displayed to the user when downloading the EPA plug-in and running the EPA plug-in can be customized by editing a Portal Theme.

Look in the Advanced Settings column on the right for the three EPA pages. Citrix CTX222812 How to Customize Custom Error Messages for NetScaler Gateway EPA Scans.

EPA Troubleshooting

From Citrix CTX209148 Understanding/Configuring EPA Verbose Logging Feature:

  1. Go to Citrix Gateway > Global Settings.
  2. On the right, click Change Global Settings.
  3. On the Security tab, click Advanced Settings.
  4. Scroll down, check the box next to Enable Client Security Logging, and click OK.
  5. When the scan fails, the user is presented with a Case ID.
  6. You can then grep /var/log/ns.log for the Case ID. Or search your syslog.

For client-side logging, on the client machine, go to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Secure Access Client.

  • Make a DWORD value named “EnableEPALogging“, and set the value to 1.
  • After attempting the scan again, you’ll find the file %localappdata%\Citrix\AGEE\epaHelper_epa_plugin.txt with details for each scan expression.

NetscalerAssasin EPA OPSWAT Packet flow and Troubleshooting shows a Wireshark trace of an EPA scan.

SmartAccess

Links:

Make sure the prerequisites are completed. This includes:

  • ICA Only unchecked on Citrix Gateway Virtual Server
  • Gateway Universal licenses installed
  • Callback URL configured at StoreFront
  • Trust XML enabled on Delivery Controllers

SmartAccess is configured in two places:

  • Delivery Group > Access Policy page in Web Studio in CVAD 2407 and newer has been redesigned. There are built-in Access Policies that you can edit. And you can add Access Policies. They support both inclusions and exclusions. See Citrix Docs for details.

    • CVAD 2402 and older looks like the screenshot below.
  • Citrix Policy (user settings only) > filters > Access control in Web Studio looks like the screenshot below.

    • Group Policy looks like the screenshot below.

In any case, you enter the name of a matching Gateway Virtual Server, and the name of a matching Session Policy (or Preauthentication Policy).

  • Set AG farm name or Site or Farm name to the name of the Citrix Gateway Virtual Server.
  • Set Access condition or Filter to the name of the Citrix Gateway Session Policy (or Preauthentication Policy).
  • You can use * as a wildcard in either field.
  • The matching Citrix Gateway Session Policy typically has an EPA Factor in an nFactor flow that puts the user in a AAA Group that has a group-specific Session Policy bound to the AAA group. That way the Session Policy only applies to connections that match the EPA Expression.

Icon visibility – Access Control at the Delivery Group controls visibility of icons published from that Delivery Group.

  • Access Control on a Delivery Group is Allow only. Icons are hidden from non-matching connections.
  • You can uncheck Connections through Citrix Gateway to hide the published icons from all Citrix Gateway connections.
  • It’s not possible to hide individual published applications. You can hide all applications from a single Delivery Group, or none of them. If you need more granularity, then you’ll have to split the applications onto different Delivery Groups.
  • App Groups do not have an Access Control option. It’s Delivery Groups only.

Citrix Policy Settings – Access Control filter on a Citrix Policy determines if the Policy settings apply or not.

  • Access Control filter applies to User Settings only. It’s not configurable for Computer Settings.
  • You typically configure the Unfiltered Citrix Policy to block all client device mappings. Then you configure a higher priority Citrix Policy with Access Control filter to re-enable client device mappings for endpoint machines that match the Session Policy and EPA Expression.

When connected to a session, Director shows SmartAccess Filters on the Session Details page. Notice the Farm Name (Gateway Virtual Server name) and Filter Name (Session Policy name)

SmartControl

The SmartControl feature lets you configure some of the SmartAccess functionality directly on the appliance. See Configuring SmartControl at Citrix Docs for detailed instructions.

  • Note: SmartControl requires Citrix ADC Premium Edition. If you don’t have Premium Edition, you can instead configure SmartAccess.
  • SmartControl cannot hide published icons. If you need that functionality, configure SmartAccess, either as a replacement for SmartControl, or as an addition to SmartControl.

To configure SmartControl:

  1. Make sure the Prerequisites are completed. This includes: ICA Only unchecked and Gateway Universal licenses installed. Callback URL and Trust XML are not needed.
  2. If you are using a Preauthentication Policy to run an Endpoint Analysis scan:
    1. Edit the Preauthentication Profile.
    2. Configure the Default EPA Group with a new group name. You’ll use this group name later.
  3. If you are instead using a Session Policy to run the post-authentication Endpoint Analysis scan:
    1. Edit the Session Profile
    2. On the Security tab, use the Smartgroup field to define a new group name for users that pass the scan. You’ll use this group name later.
  4. On the left, expand Citrix Gateway, expand Policies, and click ICA.
  5. On the right, switch to the Access Profiles tab, and click Add.

    1. Configure the restrictions as desired, and click Create.
  6. Switch to the ICA Action tab, and click Add.

    1. Give the ICA Action a name.
    2. Select the ICA Access Profile.
    3. Click Create.
  7. Switch to the ICA Policies tab, and click Add.
  8. In the Create ICA Policy page, do the following:
    1. Give the ICA Policy a name.
    2. Select the previously created ICA Action.
    3. Enter an expression. You can use HTTP.REQ.USER.IS_MEMBER_OF(“MyGroup”).NOT where MyGroup is the name of the SmartGroup you configured in the session profile or preauth scan.
  9. Click Create when done.
  10. Edit your Gateway Virtual Server.
    1. Scroll down to the Policies section, and click the plus icon.
    2. Change the Choose Type drop-down to ICA, and click Continue.
    3. Select the SmartControl policy you created earlier, and click Bind.

Related Pages

EUC Weekly Digest – August 26, 2017

Last Modified: Nov 7, 2020 @ 6:34 am

Leave a comment

Here are some EUC items I found interesting last week. For more immediate updates, follow me at http://twitter.com/cstalhood.

For a list of updates at carlstalhood.com, see the Detailed Change Log.

 

XenApp/XenDesktop

App Layering (Unidesk)

HDX

WEM/Profile Management

StoreFront

Receiver

NetScaler

NetScaler Gateway

XenMobile

Global Server Load Balancing (GSLB) – Citrix ADC

Last Modified: Mar 30, 2023 @ 10:18 am

242 Comments

Navigation

💡 = Recently Updated

Change Log

GSLB Planning

GSLB is nothing more than DNS. GSLB receives a DNS query, and then GSLB sends back an IP address, which is exactly how a DNS server works. The user then connects to the returned IP, which doesn’t even need to be on a NetScaler ADC.

GSLB can do some things that DNS servers can’t do:

  • Don’t give out an IP address unless it is UP (monitoring)
    • If the active IP address is down, then give out the passive IP address (active/passive) instead
  • Give out the IP address that is closest to the user (proximity load balancing)
  • Give out different IPs for internal users vs external users (DNS View)

GSLB is only useful if you have a single DNS name that could resolve to two or more IP addresses. If there’s only one IP address, then use normal DNS instead.

Citrix Blog Post Global Server Load Balancing: Part 1 explains how DNS queries work and how GSLB fits in.

Citrix has a good DNS and GSLB Primer.

When configuring GSLB, don’t forget to ask “where is the data?”. See Citrix Blog Post XenDesktop, GSLB & DR – Everything you think you know is probably wrong!

GSLB Configuration Overview

GSLB Configuration can be split between one-time steps for GSLB infrastructure, and repeatable steps for each GSLB-enabled DNS name.

One-time GSLB Infrastructure configuration

  1. Create ADNS listener on each ADC pair – DNS clients send DNS queries to the ADNS listeners. GSLB resolves a DNS query into an IP address, and returns the IP address in the DNS response.
  2. Create GSLB Sites (aka MEP Listener) – GSLB Sites usually correspond to different datacenters. GSLB Sites are also the IP address endpoints for Citrix ADC’s proprietary Metric Exchange Protocol (MEP), which is used by GSLB to transmit proximity, persistence, and monitoring information.
  3. Import Static Proximity Database – Citrix ADC includes a database that can be used to determine the geographical location of an IP address. Or you can subscribe to a geolocation service, and import its database.
  4. Delegate DNS sub-zone to ADC ADNS – in the original DNS zone, create a new sub-zone (e.g. gslb.company.com), and delegate the sub-zone to all ADNS listeners.

Repeatable GSLB Configuration for each DNS name:

  1. Create one or more GSLB Services per DNS name, and per IP address response – each GSLB Service corresponds to a single IP address that can be returned in response to a DNS Query.
    • Optionally, bind a Monitor to each GSLB Service. Monitors determine if the GSLB Service is up or not.
  2. Create a GSLB Virtual Server per DNS name
    • Bind a DNS name to the GSLB Virtual Server.
    • For active/active – bind multiple GSLB Services to the GSLB Virtual Server, configure a load balancing method (e.g. proximity), and configure site persistence.
    • For active/passive – bind the active GSLB Service. Create another GSLB Virtual Server with passive GSLB Service and configure as Backup Virtual Server.
      • Alternatively, NetScaler ADC 13.1 and newer let you bind GSLB Services in priority order. See Citrix Docs for details.
  3. Create CNAME records for each delegated DNS name – in the main DNS zone, create a CNAME that maps the original DNS name to the delegated sub-zone. For example, CNAME citrix.company.com to citrix.gslb.company.com.

You will create separate GSLB Services, separate GSLB Virtual Servers, and separate CNAMEs for each DNS name. If you have a bunch of DNS names that you want to GSLB-enable, then you’ll repeat these steps for each GSLB-enabled DNS name.

Each datacenter has a separate ADNS listener IP address. DNS is delegated to all GSLB ADNS Listener IPs, and any one of them can respond to the DNS query. Thus, all ADC pairs participating in GSLB should have the same Per-DNS name configuration.

One ADC appliance for both public DNS/GSLB and internal DNS/GSLB?

GSLB can be enabled both publically and internally. For public GSLB, configure it on DMZ ADC appliances, and expose the DNS listener to the Internet. For internal GSLB, configure it on separate internal ADC appliances/instances, and create an internal DNS listener.

Each ADC appliance only has one DNS table, so if you try to use the same ADC for both public DNS and internal DNS, then be aware that external users can query for internal GSLB-enabled DNS names.

  • As described by Phil Bossman in the comments, you can use a Responder policy to prevent external users from reading internal DNS names. 
    add policy patset GSLB_INTERNAL
bind policy patset GSLB_INTERNAL internalHostname.gslb.domain.com -index 1
add responder action DNS_Empty_Response respondwith DNS.NEW_RESPONSE
add responder policy GSLB_DNS_Empty_Response "(!(CLIENT.IP.SRC.IN_SUBNET(10.0.0.0/8)||CLIENT.IP.SRC.IN_SUBNET(192.0.0.0/16)||CLIENT.IP.SRC.IN_SUBNET(172.0.0.0/12)) && DNS.REQ.QUESTION.DOMAIN.CONTAINS_ANY(\"GSLB_INTERNAL\"))" DNS_Empty_Response
bind responder global GSLB_DNS_Empty_Response 100 END -type DNS_REQ_DEFAULT

One appliance resolving a single DNS name differently for internal and public

Let’s say you have a single DNS name citrix.company.com. When somebody external resolves the name, it should resolve to a public IP. When somebody internal resolves the name, it should resolve to an internal IP.

For internal GSLB and external GSLB of the same DNS name on the same ADC appliance, you can use DNS Policies and DNS Views to return different IP addresses depending on where users are connecting from. See Citrix CTX130163 How to Configure a GSLB Setup for Internal and External Users Using the Same Host Name.

If the Internet circuit in the remote datacenter goes down, then this should affect public DNS, since you don’t want to give out a public IP that isn’t reachable. But do you also want an Internet outage to affect internal DNS? Probably not. In that case, you would need different GSLB monitoring configurations for internal DNS and external DNS. However, if you have only a single GSLB Virtual Server with DNS Views, then you can’t configure different monitoring configurations for each DNS View.

To work around this limitation, create two separate GSLB Virtual Servers with different monitoring configurations. Internal DNS uses a CNAME record to reach the GSLB Virtual Server configured for internal monitoring:

  • External citrix.company.com:
    • Configure ADC GSLB for citrix.company.com.
    • On public DNS, delegate citrix.company.com to the ADC DMZ ADNS services.
  • Internal citrix.company.com:
    • Configure ADC GSLB for citrixinternal.company.com or something like that.
    • On internal DNS, create CNAME for citrix.company.com to citrixinternal.company.com
    • On internal DNS, delegate citrixinternal.company.com to ADC internal ADNS services.

Remote Internet Monitoring

For public DNS/GSLB, you don’t want to give out a remote public IP address if that remote public IP address is not reachable. That means the local ADC will need to somehow determine if the remote datacenter has Internet connectivity or not. Here are some methods of verifying the remote Internet connection:

  • Route GSLB Metric Exchange Protocol (MEP) across the Internet. If MEP goes down, then all IP addresses associated with the remote GSLB Site are assumed to be down, and thus the local ADC will stop giving out those remote IP addresses.
  • Bind explicit monitors to each GSLB Service, and ensure the monitoring is routed across the Internet.

GSLB IP Addresses

GSLB is separate from data traffic. The GSLB IP addresses are separate from the IP addresses needed for data.

Some GSLB-specific IP Addresses are needed on each ADC pair:

  • ADNS Listener IP: An ADC IP that listens for DNS queries.
    • The ADNS listener IP is typically an existing SNIP on the appliance.
    • For external DNS, create a public IP for the ADNS Listener IP, and open UDP 53 and TCP 53, so Internet-based DNS servers can access it.
    • A single ADC appliance can have multiple ADNS listeners – typically one ADNS listener for public, and another ADNS listener for internal.
  • GSLB Site IP / MEP listener IP: An ADC IP that will be used for ADC-to-ADC GSLB communication. This communication is called MEP or Metric Exchange Protocol. MEP transmits the following between GSLB-enabled ADC pairs: load balancing metrics, proximity, persistence, and monitoring.
    • GSLB Sites – On ADC, you create GSLB Sites. GSLB Sites are the endpoints for the MEP communication. Each ADC pair is configured with the MEP endpoints for the local appliance pair, and all remote appliance pairs.
    • TCP Ports – MEP uses port TCP 3009 or TCP 3011 between the ADC pairs. TCP 3009 is encrypted.
    • The ADNS IP address can be used as the MEP endpoint IP.
    • MEP endpoint can be any IP – The MEP endpoint IP address can be any IP address and does not need to be a SNIP or ADNS.
    • One MEP IP per appliance – there can only be one MEP endpoint IP address on each ADC pair.
    • Route MEP across Internet? – If you route MEP across the Internet, and if the MEP connection is interrupted, then Internet at one of the locations is probably not working. This is an easy way to determine if remote Internet is up or not. If you don’t route MEP across the Internet, then you’ll need to configure every remote-site GSLB Service with a monitor to ensure that the remote Internet is up.
      • Public IPs for MEP Enpoints – if you route MEP across the Internet, then you’ll need public IPs for each publically-accessible MEP endpoint IP address.
      • Public Port for MEP: Open port TCP 3009 between the MEP Public IPs. Make sure only the MEP IPs can access this port on the other ADC . Do not allow any other device on the Internet to access this port. Port 3009 is encrypted.
    • GSLB Sync Ports: To use GSLB Configuration Sync, open ports TCP 22 and TCP 3008 (secure) from the NSIP (management IP) to the remote public MEP IP. The GSLB Sync command runs a script in BSD shell and thus NSIP is always the Source IP.
  • Public IP Summary: In summary, for public GSLB, if MEP and ADNS are listening on the same IP, then you need one new public IP that is NAT’d to the DMZ IP that is used for ADNS and MEP (GSLB Site IP).
    • Each datacenter has a separate public IP.
    • DNS is delegated to all public ADNS IP listeners.

GSLB Wizard

NetScaler 12 and Citrix ADC 12.1 and newer have a GSLB Wizard at Traffic Management > GSLB.

However, the wizard doesn’t really save any time or steps, so it won’t be documented here.

ADNS Listener

  1. At System > Network > IPs, identify a Citrix ADC-owned IP that you will use as the ADNS listener. This is typically a SNIP.
  2. Create a public IP for the ADNS Service IP and configure firewall rules. UDP 53 and TCP 53 need to be opened from the Internet to the public IP that NATs to the ADNS Listener IP address.
  3. On the left, expand Traffic Management > Load Balancing, and click Services.
  4. On the right, click Add.

    1. In the Basic Settings section, do the following:
      1. Name the service ADNS or similar.
      2. In the IP Address field, enter an appliance SNIP.
      3. In the Protocol drop-down, select ADNS.
    2. Click OK.
    3. No other configuration is needed so scroll down and click Done to close the Load Balancing Service properties.
  5. Highlight the ADNS service you just added and then click Add to create another Service while copying some of the settings from the previously created Service.

    1. Change the Service Name to ADNS_TCP or similar.
    2. Change the Protocol drop-down to ADNS_TCP.
    3. Click OK to close the Basic Settings section.
    4. No other configuration is needed so scroll down and click Done to close the Load Balancing Service properties.
  6. You should have two ADNS services on the same IP address: one for ADNS, and one for ADNS_TCP.
  7. On the left of the console in the menu, expand System, expand Network, and then click IPs.
  8. On the right, you’ll see the SNIP is now marked as the ADNS svc IP.
  9. Repeat the ADNS configuration on the other appliance pair in the other datacenter. Except the other appliance will use its own SNIP as the ADNS Service listener IP address.
  10. Your ADC appliances are now DNS servers.

DNS Security

  1. Citrix ADC includes DNS Security Options, at Security > DNS Security, which can protect your ADNS service.
  2. To protect ADNS, set the Profile to All DNS Endpoints.

Metric Exchange Protocol

This section details MEP configuration between two GSLB Sites. See Citrix Docs for larger Parent-Child Topology Deployment Using the MEP Protocol.

GSLB Sites

  1. The local GSLB Site IP can be any IP, including the same SNIP that you used for ADNS.
  2. Open the firewall rules for Metric Exchange Protocol. The GSLB Site IP on this appliance pair uses TCP 3009 to communicate with the GSLB Site IP on the other appliance pair.
  3. On the left, expand Traffic Management, right-click GSLB, and enable the feature.
  4. Expand GSLB, and click Sites.
  5. On the right, click Add.
  6. In the Create GSLB Site page, do the following:
    1. We’re adding the local site first. Enter a descriptive name for the local site.
    2. In the Site Type drop-down, select LOCAL.
    3. In the Site IP Address field, enter an IP that this appliance will listen for MEP traffic. This is typically a SNIP and can the same as your ADNS IP.
    4. For Internet-routed GSLB MEP, in the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP.
    5. For internal GSLB MEP, there is no need to enter anything in the Public IP field.
  7. Scroll down, and click Create, to close the Create GSLB Site page.

  8. Go back to System > Network > IPs, and notice that the IP is now marked as a GSLB site IP.
  9. If you want to use the GSLB Sync Config feature, then you’ll need to edit the GSLB site IP, and enable Management Access.

    1. Scroll down, and enable Management Access. SSH is all you need.
  10. Go to the other appliance pair, and also create the Local GSLB site using its GSLB site IP, and its public IP that is NAT’d to the GSLB site IP.

    1. In System > Network > IPs on the remote appliance, there should now be a GSLB site IP. If GSLB Sync is desired, enable management access on that IP and ensure SSH is enabled.
  11. Now on each appliance, add another GSLB Site, which will be the Remote GSLB site.
  12. In the Create GSLB Site page, do the following:
    1. Enter a descriptive name for the remote site.
    2. Select REMOTE as the Type.
    3. Enter the other appliance’s actual GSLB Site IP as configured on the appliance. This IP does not need to be reachable.
    4. In the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP on the other appliance. For MEP, TCP 3009 must be open from the local GSLB Site IP, to the remote public Site IP. For GSLB sync, TCP 22, and TCP 3008, must be open from the local NSIP, to the remote public Site IP.
  13. Click Create.
  14. Repeat on the other appliance.

RPC

MEP defaults to unencrypted on TCP 3011. To fix that:

  1. On the left, expand System, expand Network, and click RPC.
  2. On the right, right-click the new RPC address (the other site’s GSLB Site IP), and click Edit.
  3. On the bottom, check the box next to Secure. In ADC 13.0 64.x and 12.1 build 61.x onwards, Secure is enabled by default. (source = Citrix CTX292743 Configuration Sync, Propagation and MEP Propagation Might Fail After Upgrade to 13.0 64.x\12.1 61.x)

    • If your local GSLB Site IP is not a SNIP, then you’ll need to change the RPC Node to use the local GSLB Site IP as the source IP. In the Source IP Address field, enter the local GSLB Site IP.
  4. Click OK when done.
  5. Do the same thing on the other appliance.
  6. If you go back to GSLB > Sites, you should see it as active.

See Citrix Tech Zone Troubleshooting Citrix GSLB MEP Cheat Sheet

If your MEP connection between GSLB Sites flaps, it might be useful to introduce a delay before remote GSLB Services are marked as Down.

  1. You can do this at Traffic Management > GSLB > Dashboard.
  2. On the right, click Change GSLB settings.
  3. In the GSLB Service State Delay Time (secs) field, enter a delay before the GSLB Services are marked as down when MEP goes down.

    set gslb parameter -GSLBSvcStateDelayTime 15

Static Proximity Geo Location Database

If you want to use DNS Policies, or Static Proximity GSLB Load Balancing, or Responders based on user’s location, import a geo location database.

Citrix ADC has a built-in database at /var/netscaler/inbuilt_db/ that you can use. Or you can download a database. Common free databases are:

For IP2Location, see the blog post Add IP2Location Database as NetScaler’s Location File for instructions on how to import.

CTX235799 NetScaler data formats for Location Database Import

Citrix Github has a Citrix-ADC-GSLB-GeoIP-Conversion-Tool that can convert Maxmind GeoIP City database to Citrix ADC (NetScaler) format.

Import the Built-in Geo database:

  1. In the Citrix ADC GUI, on the left, expand Traffic Management, expand GSLB, expand Database and Entries, and click Static Databases.
  2. On the right, click Add.
  3. Change the Import From selection to File.
  4. Click Choose File.
  5. Browse to /var/netscaler/inbuilt_db/. To browse to the directory, select var, and then click Open.
  6. Repeat for each directory until you reach /var/netscaler/inbuilt_db.
  7. In ADC 12.1, you can select the file named Citrix_Netscaler_InBuild_GeoIP_DB_IPv4. In NetScaler 12.0, select the only file shown. Then click Open.
  8. In the Location Format field, if using the built-in database, select netscaler, and click Create.
  9. After you later create a GSLB Service, when you open the GSLB Service, the public IP will be translated to a location based on the contents of the static proximity database.

Private IP Blocks

Geo Location databases only contain entries for Public IPs. For Private IPs, do the following:

  1. On the left, expand Traffic Management, expand GSLB, expand Database and Entries, and click Custom Entries.
  2. On the right, click Add.
  3. Enter a range of IP addresses for a particular location.
  4. Enter a Location Name in Geo Location format, which is typically six location words separated by periods. You can look in the static proximity database for examples.
  5. Make sure you enter coordinates. Google can find you coordinates for cities.
  6. Click Create.
  7. Continue creating Custom Entries for other private IP blocks.

Use Geo Locations

You can use the Geo locations in a DNS Policy, static proximity GSLB Load Balancing, Responders, and Rewrites:

Prior to Citrix ADC 12.1 build 50, the only option in policy expressions is to match a known location.

Citrix ADC 12.1 build 50 and newer lets you extract the user’s location and use it in policy expressions.

GSLB Services

GSLB Services represent the IP addresses that are returned in DNS Responses. The IP addresses represented by GSLB Services do not need to be hosted on a Citrix ADC, but Citrix ADC-owned IP addresses (e.g. load balancing VIPs) have additional GSLB Site Persistence options (e.g. cookie-based persistence).

  • Each potential IP address in a DNS response is a separate GSLB Service.
  • GSLB Services are associated with GSLB Sites.
  • GSLB Service configuration is identical for active/active and active/passive. GSLB Virtual Server configuration defines active/active or active/passive, not GSLB Services.

GSLB should be configured identically on all Citrix ADC pairs that are responding to DNS queries. Since you have no control over which Citrix ADC will receive the DNS query, you must ensure that both Citrix ADC pairs are giving out the same DNS responses.

To create a GSLB Service:

  1. On the left, expand Traffic Management > GSLB, and click Services.
  2. On the right, click Add.
  3. The service name should be similar to the DNS name that you are trying to GSLB. Include the site name in the service name.
  4. Select one of the GSLB Sites. The IP address you’re configuring in this GSLB Service should be geographically located in the selected GSLB Site.
  5. On the bottom part, if the IP address is owned by this Citrix ADC, then select Virtual Servers, and select a Virtual Server that is already defined on this appliance. It should automatically fill in the other fields. This option is only available when creating a GSLB Service in the Local GSLB Site.

    1. If the IP address is not owned by this Citrix ADC, then change the selection to New Server, and enter the remote IP address in the Server IP field.
    2. The Server IP field is the IP address that Citrix ADC will monitor for reachability.
    3. If the remote IP is owned by a different Citrix ADC that is reachable by MEP, then enter the actual VIP configured on that remote Citrix ADC. The Server IP does not need to match what is returned to the DNS Query.
  6. In the Public IP field, enter the IP address that will be returned to the DNS Query. If you leave Public IP blank, then Citrix ADC will copy the Server IP to the Public IP field. For Public GSLB, the Public IP field is usually a Public IP address. For internal GSLB, the Public IP field is usually an internal IP, and probably matches the Server IP.
  7. Scroll up, and make sure the Service Type is SSL. It’s annoying that Citrix ADC doesn’t set this drop-down correctly.
  8. Scroll down, and click OK, to close the Basic Settings section.
  9. GSLB Service Monitoring – on the right, in the Advanced Settings column, you can click Monitors to bind a monitor to this GSLB Service. Review the following notes before you bind a monitor.

    • Local Citrix ADC VIP – If the GSLB Service IP is a VIP on the local appliance, then GSLB will simply use the state of the local traffic Virtual Server (Load Balancing, Content Switching, or Gateway). There’s no need to bind a monitor to the GSLB Service.
    • Remote Citrix ADC VIP – If the GSLB Service IP is a VIP on a remote appliance, then GSLB will use MEP to ask the other appliance for the state of the remote traffic Virtual Server. In both cases. There’s no need to bind a monitor to the GSLB Service.
    • GSLB Monitor overrides other Monitoring methods – If you bind a monitor to the GSLB Service, then MEP and local Virtual Server state are ignored (overridden).
    • Here are some reasons for binding a monitor to the GSLB Service:
      • IP is not on a Citrix ADC– If the GSLB Service IP is not hosted on a Citrix ADC, then only a monitor can determine if the Service IP is up or not.
      • Monitor remote Internet – For Public DNS, if MEP is not routed through the Internet, then you need some method of determining if the remote Internet circuit is up or not. In that case, you’ll need to bind monitors directly to the GSLB Service. The route of the Monitor should go across the Internet. Or you can ping the Internet router in the remote datacenter to make sure it’s reachable.
      • Traffic Domains – If the GSLB Service IP is in a non-default Traffic Domain, then you will need to attach a monitor, since GSLB cannot determine the state of Virtual Servers in non-default Traffic Domains.
      • TCP monitor – for TCP services (not UDP), a simple TCP monitor is probably all you need. The TCP monitor tries to connect to the GSLB Service Public IP address using the SNIP of the local appliance. Make sure firewall on both sides allows this connection.
  10. Active/Active Site Persistence – If you intend to do GSLB active/active, and if you need site persistence, then on the right you can add Site Persistence and enable Connection Proxy or HTTP Redirect. See Citrix Blog Post Troubleshooting GSLB Persistence with Fiddler for more details. This only works with GSLB Service IPs that match Virtual Server VIPs on Citrix ADC appliances reachable through MEP.

  11. Scroll down, and click Done, to finish creating the GSLB Service.
  12. Create additional GSLB Services for each IP address that will be returned to a DNS query. There should be at least two for each DNS name.
  13. When creating a GSLB Service, select the correct Site, and make sure Service Type = SSL.
  14. The State will probably be down until the other ADC is configured.

Manually Synchronize GSLB Configuration

Copy the GSLB Service Configuration to the remote Citrix ADC pair. You can either repeat the GUI steps listed above. Or you can do the following:

  1. On the left, expand Traffic Management, expand GSLB, and click Dashboard.
  2. On the right, click View GSLB Configuration.
  3. This shows you all of the CLI commands for GSLB. Look for add gslb service commands. You can copy them, and run them (SSH) on other Citrix ADC pairs that are participating in GSLB.

GSLB Virtual Server

GSLB Virtual Server is the entity that links a DNS name with GSLB Services.

For Active/Passive GSLB in NetScaler ADC 13.1 or newer, GSLB Services can be bound in priority order. GSLB will give out the IP address of the lowest order GSLB Service. If that GSLB Service is down, then GSLB will give out the IP address of the next order GSLB Service.

  1. Create a GSLB Virtual Server.
  2. Bind the active GSLB Service but set the Order to 1.
  3. Bind the passive GSLB Service but set the Order to 2.
  4. Bind a DNS name to the GSLB Virtual Server.
  5. Repeat the GSLB Virtual Server configuration on other Citrix ADC pairs participating in GSLB.
  6. Delegate the DNS name to Citrix ADC ADNS.

For Active/Passive GSLB, the Active GSLB Virtual Server will give out a single IP address if that IP address up. If the GSLB Service is down, then it will fail over to a Backup GSLB Virtual Server that gives out a different IP address.

  1. Create a GSLB Virtual Server for the Passive IP address.
    1. Bind the Passive GSLB Service to the Passive GSLB Virtual Server.
  2. Create another GSLB Virtual Server for the Active IP address.
    1. Bind the Active GSLB Service to the Active GSLB Virtual Server.
    2. Configure Backup Virtual Server pointing to the Passive GSLB Virtual Server.
    3. Bind a DNS name to the Active GSLB Virtual Server.
  3. Repeat the GSLB Virtual Server configuration on other Citrix ADC pairs participating in GSLB.
  4. Delegate the DNS name to Citrix ADC ADNS.

For Active/Active GSLB, a single GSLB Virtual Server gives out multiple IP addresses based on load balancing method and site persistence.

  1. Create one GSLB Virtual Server.
    1. Bind two or more GSLB Services to the Virtual Server.
    2. Configure the GSLB Virtual Server Load Balancing Method – e.g., Proximity
    3. Configure Site Persistence:
      1. Source IP persistence is configured on the GSLB Virtual Server.
      2. Cookie Persistence is configured on the GSLB Services.
    4. Bind a DNS name to the GSLB Virtual Server.
  2. Repeat the GSLB Virtual Server configuration on other Citrix ADC pairs participating in GSLB.
  3. Delegate the DNS name to Citrix ADC ADNS.

Configure Active/Passive GSLB in NetScaler ADC 13.1 and newer

  1. On the left, expand Traffic Management, expand GSLB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Sevices you intend to bind.

      add gslb vserver <gslb_vserver_name> SSL
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLB Service Binding.

    1. Click where it says Click to select.
    2. Check the box next to the active GSLB Service and click Select.
    3. In the Order box, enter 1. Click Bind.
  6. To add another GSLB Service Binding, on the left, click where it says 1 GSLB Virtual Server to GSLB Service Binding.

    1. Click Add Binding.
    2. Click where it says Click to select.
    3. Check the box next to a passive GSLB Service and then click Select at the top of the page.
    4. In the Order box, enter 2 so that this GSLB Service is only used if all Order 1 GSLB Services are down. Click Bind.
  7. Click OK to close the GSLB Services and GSLB Service Group Binding section.
  8. On the left, click where it says No GSLB Virtual Server Domain Binding.

    1. Enter the FQDN that this GSLB Virtual Server will resolve.
    2. Click Bind.
    3. If you are doing CNAME (e.g., citrix.corp.com CNAME to citrix.gslb.corp.com, then add domain bindings for both the main FQDN and the CNAME FQDN. Click Close when done.
  9. Click OK to close the GSLB Virtual Server Domain Binding section.
  10. Click OK to close the ADNS Service section.
  11. With GSLB Services assigned to different Order numbers, it is not necessary to configure Backup Virtual Server.
  12. If you bound multiple GSLB Services to a single Order number, then you might want to adjust Method and Persistence.
  13. Click Done to finish creating the GSLB Virtual Server.
  14. On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records…
  15. You’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN, and has a default TTL of 5 seconds. You can also see which GSLB Virtual Server it is bound to.
  16. Configure an identical GSLB Virtual Server on the other NetScaler ADC appliance pair. Both NetScaler ADC pairs must be configured identically. You can use Traffic Management > GSLB > Dashboard > View GSLB Configuration to copy the add/set/bind gslb vserver commands from this appliance to other NetScaler ADC appliances.


Configure Active/Passive GSLB in NetScaler ADC 13.0 and older

Passive Virtual Server

  1. On the left, expand Traffic Management, expand GSLB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the Passive GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Services that you will bind to this Virtual Server.
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLB Service Binding.

    1. Click where it says Click to select.
    2. Check the box next to an existing Passive GSLB Service, and then click the blue Select button at the top of the screen.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. Click OK to close the GSLB Virtual Server Domain Binding section. The DNS name is bound to the Active Virtual Server, not the Passive Virtual Sever.
  8. Click OK to close the ADNS Service section.
  9. Click Done to finish creating the Passive GSLB Virtual Server.

Active Virtual Server

  1. On the left, expand Traffic Management, expand GSLB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the Active GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Services that you will bind to this Virtual Server.
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLB Service Binding.

    1. Click where it says Click to select.
    2. Check the box next to an existing Active GSLB Service, and click Select.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. On the left, click where it says No GSLB Virtual Server Domain Binding.
  8. In the Domain Binding page, do the following:
    1. Enter the FQDN that GSLB will resolve.
    2. Click Bind.
  9. Click OK to close the GSLB Virtual Server Domain Binding section.
  10. Click OK to close the ADNS Service section.
  11. On the right, in the Advanced Settings section, click Backup Virtual Server to add it to the left.
  12. On the left, in the Backup Virtual Server section, select the Passive GSLB Virtual Server, and click OK.
  13. Click Done when done creating the Active GSLB Virtual Server.
  14. On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records…
  15. On the right, you’ll see a new DNS record for the GSLB domain you just configured. Notice the Type is GSLB DOMAIN, and has a default TTL of 5 seconds. You can also see which GSLB Virtual Server it is bound to.
  16. Configure identical GSLB Virtual Servers on the other Citrix ADC appliance pair. Both Citrix ADC pairs must be configured identically. You can use Traffic Management > GSLB > Dashboard > View GSLB Configuration to copy the add/set/bind gslb vserver commands from this appliance to other Citrix ADC appliances.

Configure Active/Active GSLB

  1. On the left, expand Traffic Management, expand GSLB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Sevices you intend to bind.
    3. You can optionally check the box for Send all “active” service IPs in response (MIR). By default, GSLB only gives out one IP address per DNS query. This checkbox always returns all IPs, but the IPs are ordered based on the GSLB Load Balancing Method and/or GSLB Persistence.
    4. A new DNS feature called ECS will contain the actual DNS client IP. This dramatically improves the accuracy of determining a user’s location. Without this setting, GSLB can only see the IP address of the user’s configured DNS server instead of the real client IP. Check the box next to Respond with ECS option to enable ECS for site persistence.

      set gslb vserver <gslb_vserver> -ECS ENABLED
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLB Service Binding.

    1. Click where it says Click to select.
    2. Check the boxes next to multiple existing GSLB Services, and click Select.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. On the left, click where it says No GSLB Virtual Server Domain Binding.

    1. Enter the FQDN that this GSLB Virtual Server will resolve.
    2. Click Bind.
  8. Click OK to close the GSLB Virtual Server Domain Binding section.
  9. Click OK to close the ADNS Service section.
  10. On the left, in the Method section, click the pencil icon.

    1. For poximity load balancing, change the Choose Method drop-down to RTT with STATICPROXIMITY as backup.
      1. RTT = Round Trip Time. Each ADC appliance sends a ping to the user’s DNS server. Whichever ADC appliance gets the fastest response determines the site of the GSLB Service. RTT requires that ADC be able to ping anything on the Internet so adjust firewall rules accordingly.
      2. STATICPROXIMITY requires that the Geo Location database has already been installed on the appliance.
    2. Click OK to close the Method section.
  11. On the right, in the Advanced Settings column, click Persistence to add it to the left.

    1. On the left, at the bottom of the page in the Persistence section, change the Persistence drop-down to Source IP.
    2. Enter a Persistence Id.
      1. The Persistence ID signifies the persistence table that each ADC pair shares across the MEP connection.
      2. Each active/active GSLB Virtual Server should have a different Persistence ID (different persistence table).
      3. When you configure the same GSLB Virtual Server on each Citrix ADC pair, specify the same Persistence ID so every Citrix ADC has the same persistence information for this particular GSLB Virtual Server.
    3. In the Time-out field, enter the Persistence Time-out. This is typically the same or longer than the webpage timeout.
    4. Click OK to close the Persistence section.
  12. Click Done to finish creating the GSLB Virtual Server.
  13. On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records…
  14. You’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN, and has a default TTL of 5 seconds. You can also see which GSLB Virtual Server it is bound to.
  15. Configure an identical GSLB Virtual Server on the other Citrix ADC appliance pair. Both Citrix ADC pairs must be configured identically. You can use Traffic Management > GSLB > Dashboard > View GSLB Configuration to copy the add/set/bind gslb vserver commands from this appliance to other Citrix ADC appliances.


GSLB Configuration Synchronization Script

Manual GSLB Synchronization

  1. The synchronization script requires SSH to be enabled on your GSLB Site IPs.

  2. Ports TCP 3008, TCP 3010, and TCP 22 must be opened from the local NSIP to the remote GSLB Site IP. The source IP is NSIP, not SNIP.
  3. To manually run the script that syncs GSLB configuration from one GSLB Site to another, on the left, expand Traffic Management, expand GSLB, and click Dashboard.
  4. On the right, click the button labelled Auto Synchronization GSLB.
  5. Use the check boxes on the top, if desired. It’s usually a good idea to Preview the changes before applying them.
  6. Then click Run to begin synchronization.
  7. Click Close.
  8. You can Run it again without previewing it. It seems to take several seconds to complete.

Automatic GSLB Synchronization

  1. There is an automatic GSLB Configuration Sync feature, which automatically syncs the GSLB config every 15 seconds. To enable it on the master appliance, go to Traffic Management > GSLB > Dashboard. On the right, click Change GSLB settings.
  2. Check the box next to Automatic Config Sync. Only enable this on the one appliance where you are configuring GSLB, and want that GSLB config synced to other appliance.
  3. The automatic sync log can be found at /var/netscaler/gslb/periodic_sync.log.

Some notes regarding GSLB Sync:

  • When syncing GSLB Services, it tries to create Load Balancing Server objects on the remote appliance. If the GSLB Service IP matches an existing Load Balancing Server object, then the GSLB sync will fail. Check the Sync logs for details. You’ll have to delete the conflicting Load Balancing Server object before GSLB Sync works correctly.
  • GSLB Sync runs as a script on the BSD shell and thus always uses the NSIP as the source IP.
  • GSLB Sync connects to the remote GSLB Site IP on TCP 3008 (if RPC is Secure) and TCP 22.

Test GSLB

  1. You can test GSLB DNS name resolution from the GUI by going to Traffic Management > GSLB > Dashboard, and on the right, click the button labelled Test GSLB.

  2. Select a GSLB Domain Name.
  3. Select an ADNS Service IP to test it from, and click Test.
  4. The test performs a dig against the ADNS IP. Verify that the response contains the IP address you expected.
  5. Another method of testing GSLB is to simply point nslookup to the ADNS services and submit a DNS query for one of the DNS names bound to a GSLB vServer. Run the query multiple times to make sure you’re getting the response you expect.
    • The syntax is “nslookup <DNS_name> <ADNS_IP>”. The second argument specifies the DNS server that you send the DNS Query to.
  6. The Citrix ADC ADNS services at both GSLB sites should be giving the same response.
  7. To simulate a failure, if the GSLB Service IP is a Citrix ADC Load Balancing, Content Switching, or Citrix Gateway IP, you can disable the Virtual Server.
  8. Then the responses should change. Verify on both ADNS services.
  9. Re-enable the Virtual Server, and the responses should return to normal.

DNS Delegation

If you are enabling GSLB for the domain gateway.corp.com, you’ll need to create a delegation at the server that is hosting the corp.com DNS zone. For public GSLB, you need to edit the public DNS zone for corp.com.

DNS Delegation instructions will vary depending on what product is hosting the public DNS zone. This section details Microsoft DNS, but it should be similar in BIND or web-based DNS products.

There are two ways to delegate GSLB-enabled DNS names to Citrix ADC ADNS:

  • Delegate the individual record –  For example, delegate gateway.corp.com.
  • Delegate an entire subzone – For example, delegate the subzone gslb.corp.com. Then create a CNAME record in the parent DNS zone for gateway.corp.com that is aliased to gateway.gslb.corp.com. For additional delegations, simply create more CNAME records.
    • The incoming DNS query to the ADNS listener is for gateway.gslb.corp.com and not gateway.corp.com. You’ll need to bind gateway.gslb.corp.com to your GSLB Virtual Server. You can bind multiple FQDNs to a single GSLB Virtual Server.

A delegation consists of the following DNS records:

  • A records (host records) that resolve to each Citrix ADC ADNS IP address. If you have two ADC pairs participating in GSLB, then you’ll need one A record for each ADC pair.
    • The A record names are typically something like ns1.corp.com and ns2.corp.com, just like you would name any other DNS server.
    • You only create the A records once. The A records for ADNS services can be used by multiple delegations.
    • These A records for ADNS are sometimes called glue records.
  • NS records for each delegation. The NS records point to the A records that resolve to the ADC ADNS IP addresses. If you have two ADC ADNS IP addresses, then you need two NS records for each delegation.
    • When delegating individual records, you create separate NS records for each delegation. If you have two ADNS listeners, then you need two NS records for each delegation.
    • When delegating a subzone, you only need NS records for the subzone. To GSLB-enable a DNS name, you create a CNAME that aliases to a record under the subzone.

Delegate an individual DNS record

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the Citrix ADC pairs in each data center. These host records for ADNS are used for all GSLB delegations no matter how many GSLB delegations you need to create. These are sometimes called glue records.
  3. The first Host record is gslb1, (or similar) and should point to the ADNS service (Public IP) on one of the Citrix ADC appliances.
  4. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other Citrix ADC appliance.
  5. If you currently have a host record for the service that you are delegating to GSLB (e.g. gateway.corp.com), delete it.
  6. Right-click the parent DNS zone, and click New Delegation.
  7. In the Welcome to the New Delegation Wizard page, click Next.
  8. In the Delegated Domain Name page, enter the left part of the DNS record that you are delegating (e.g. gateway for gateway.corp.com). Click Next.
  9. In the Name Servers page, click Add.
  10. This is where you specify gslb1.corp.com and gslb2.corp.com as delegated name servers. Enter gslb1.corp.com, and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message. Note: you only add one name server at a time.
  11. Then click Add to add the other GSLB ADNS server.
  12. Once both ADNS servers are added to the list, click Next.
  13. In the Completing the New Delegation Wizard page, click Finish.
  14. The delegation is shown in the DNS Manager console.
  15. For proper delegation, the Name Server records should also be added to Citrix ADC. (source = Citrix CTX241493 Citrix Response on DNS Flag Day)
    1. On the GSLB Citrix ADC appliances, expand Traffic Management, expand DNS, expand Records, and click Name Server Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the name of the delegated DNS name (e.g. gateway.corp.com).
    4. In the Name Server field, leave it set to –<< New >>–, and enter one of the FQDNs for your GSLB ADNS services. This is one of the glue records you created earlier.
    5. Click Create.
    6. Add another Name Server Record for the same domain name. But this time, enter the second GSLB ADNS FQDN. Repeat this process until all GSLB ADNS FQDNs are specified.

  16. Also add an SOA record for the delegation. If you are delegating individual records, then you will need an SOA for each record. If you are delegating a subzone, you only need an SOA record for the subzone.
    1. On the left, in the menu, go to Traffic Management > DNS > Records > SOA Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the FQDN that you delegated to NetScaler. This can be an individual record, or a sub-zone.
    4. In the Origin Server field, leave it set to –<< New >> — and then enter the FQDN that resolves to one of your ADNS listeners. It doesn’t matter which one you enter.
    5. In the Contact field, enter an email address that is publicly viewable. Replace the @ symbol with a period.
    6. Click Create.
    7. Repeat this on the other ADCs that are participating in GSLB for this delegated DNS name.
  17. If you run nslookup against your Microsoft DNS server, it will respond with Non-authoritative answer. That’s because it got the response from Citrix ADC, and not from the original DNS server that you send the request to.

Delegate a Sub-zone

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the Citrix ADC pairs in each data center. These are sometimes called glue records.

    1. The first Host record is gslb1 (or similar), and should point to the ADNS service (Public IP) on one of the Citrix ADC appliances.
    2. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other Citrix ADC appliance.
  3. Right-click the parent DNS zone, and click New Delegation.
  4. In the Welcome to the New Delegation Wizard page, click Next.
  5. In the Delegated Domain Name page, enter the left part of the DNS sub-zone that you are delegating (e.g. gslb for gslb.corp.com). Click Next.
  6. In the Name Servers page, click Add.
  7. This is where you specify gslb1.corp.com and gslb2.corp.com. Enter gslb1.corp.com, and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message. Note: you only add one name server at a time.
  8. Then click Add to add the other GSLB ADNS server.
  9. Once both ADNS servers are added to the list, click Next.
  10. In the Completing the New Delegation Wizard page, click Finish.
  11. The sub-zone delegation is shown in the DNS Manager console.
  12. For proper delegation, the Name Server records should also be added to Citrix ADC. (source = Citrix CTX241493 Citrix Response on DNS Flag Day)
    1. On the GSLB Citrix ADC appliances, expand Traffic Management, expand DNS, expand Records, and click Name Server Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the name of the delegated sub-domain (e.g. gslb.corp.com).
    4. In the Name Server field, leave it set to –<< New >>–, and enter one of the FQDNs for your GSLB ADNS services. This is one of the glue records you created earlier.
    5. Click Create.
    6. Add another Name Server Record for the same domain name. But this time, enter the second GSLB ADNS FQDN.

    7. Repeat this process until all GSLB ADNS FQDNs are specified.
  13. Also add an SOA record for the delegation. If you are delegating individual records, then you will need an SOA for each record. If you are delegating a subzone, you only need an SOA record for the subzone.
    1. On the left, in the menu, go to Traffic Management > DNS > Records > SOA Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the FQDN that you delegated to NetScaler. This can be an individual record, or a sub-zone.
    4. In the Origin Server field, leave it set to –<< New >> — and then enter the FQDN that resolves to one of your ADNS listeners. It doesn’t matter which one you enter.
    5. In the Contact field, enter an email address that is publicly viewable. Replace the @ symbol with a period.
    6. Click Create.
    7. Repeat this on the other ADCs that are participating in GSLB for this delegated DNS name.

Each GSLB-enabled DNS name must be CNAME’d to GSLB:

  1. In Citrix ADC, go to Traffic Management > GSLB > Virtual Servers, and edit your GSLB Virtual Server.
  2. On the left, click in the GSLB Virtual Server Domain Binding section.
  3. Click Add Binding.
  4. Add a domain binding for the CNAME’d DNS name. For example, if the original DNS name is gateway.corp.com, then enter gateway.gslb.corp.com. gslb.corp.com matches the sub-zone that you delegated to Citrix ADC. Click OK.
  5. Repeat the Domain Binding on the other Citrix ADC appliances.
  6. In DNS Manager, if you currently have a host record for the service that you are delegating to GSLB (gateway.corp.com), delete it.
  7. Right-click the DNS zone, and click New Alias (CNAME).
  8. In the Alias name field, enter the left part of the original DNS name. For gateway.corp.com, enter gateway.
  9. In the Fully qualified domain name (FQDN) for target host field, enter the CNAME’d DNS name that is delegated to Citrix ADC. For example, if you delegated gslb.corp.com to Citrix ADC, then enter gateway.gslb.corp.com. The GSLB Virtual Server must be configured to match this longer DNS name.
  10. Click OK.
  11. If you run nslookup for the delegated DNS name, it will first CNAME to the longer name, and then respond with the IP address returned by Citrix ADC GSLB.
  12. You can repeat these steps to delegate (CNAME) additional DNS names to Citrix ADC GSLB.

RADIUS Authentication – Citrix Gateway

Last Modified: Mar 29, 2021 @ 11:28 am

225 Comments

This article applies to Citrix Gateway 13.0, Citrix Gateway 12.1, and NetScaler Gateway 12.0. Citrix ADC is the new name for NetScaler. Citrix Gateway is the new name for NetScaler Gateway.

Navigation

Change Log

RADIUS Overview

One method of two-factor authentication to Citrix Gateway is the RADIUS protocol with a two-factor authentication product (tokens) that has RADIUS enabled.

  • Another common two-factor authentication method is SAML to an Identity Provider, like Azure Active Directory or Okta. SAML is detailed in the Federated Authentication Service article.

RADIUS Clients and Source IP – On your RADIUS servers, you’ll need to add the ADC appliances as RADIUS Clients. When ADC uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the ADC SNIP (Subnet IP). When ADC uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the ADC NSIP (ADC Management IP). Use the correct IP(s) when adding the ADC appliances as RADIUS Clients. And adjust firewall rules accordingly.

  • For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client, since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

Links:

Some two-factor products (e.g. SMS Passcode) require you to hide the 2nd password field. Receiver 4.4 and newer supports hiding the 2nd field if you configure a Meta tag in index.html.

Two-factor Policies Summary

ADC has two methods of configuring multi-factor authentication:

  • Citrix Gateway Virtual Server has bind points for Primary and Secondary authentication. This functionality is available in all ADC Editions and is detailed in this post.
    • This is the older method of configuring authentication also known as Classic authentication policies. One challenge with Classic policies is that Citrix Workspace app requires the LDAP and RADIUS fields to be swapped.
  • nFactor Authentication supports unlimited factors, but requires ADC Advanced Edition (formerly known as Enterprise Edition) or ADC Platinum Edition.
    • nFactor is the newer authentication configuration method also known as Advanced authentication policies. With nFactor, there’s no need to swap the LDAP and RADIUS fields for Citrix Workspace app.

Workspace app authentication with a Classic Policy configuration looks like a Window that is very difficult to customize.

Workspace app authentication with an nFactor configuration looks like a webpage that is fully customizable.

See the ADC menu page for additional authentication mechanisms supported by Citrix Gateway. Some require nFactor.

When configuring the Citrix Gateway Virtual Server, you can specify both a Primary authentication policy, and a Secondary authentication policy. Users are required to successfully authenticate against both policies before being authorized for Citrix Gateway.

For browser-based StoreFront, you need two authentication policies:

  • Primary = LDAPS authentication policy pointing to Active Directory Domain Controllers.
  • Secondary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.

For Citrix Workspace app, the classic authentication policies need to be swapped. There’s no need to swap them if doing nFactor (Advanced) policies.

  • Primary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.
  • Secondary = LDAPS authentication policy pointing to Active Directory Domain Controllers.

With Classic Authentication Policies, if you need to support two-factor authentication from both web browsers and Citrix Workspace app, then you’ll need at least four authentication policies as shown below.

Primary:

  • Priority 90 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

Secondary:

  • Priority 90 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

LDAP Server/Action

See the LDAP post for instructions to create an LDAP Server/Action. Only the LDAP server/action is needed. The Policies will be created later.

RADIUS Server/Action

Create a RADIUS Server/Action:

  1. On the left, expand Authentication, and click Dashboard.
  2. On the right, click Add.
  3. Change Choose Server Type to RADIUS.
  4. Give the server a name.
  5. Specify the IP address of the RADIUS load balancing Virtual Server.
  6. Enter the secret key specified when you added the ADCs as RADIUS clients on the RADIUS server. Click Test RADIUS Reachability.
  7. Scroll down, and click More.
  8. Find the Password Encoding drop-down. Change it to mschapv2 if your RADIUS server supports it, c. Microsoft NPS requires mschapv2 to support changing expired Active Directory passwords. 💡
  9. If you want ADC to receive AAA Group information from RADIUS, see CTX222260 Radius Group Extraction from Windows Server 2008/2012 with NetScaler/CloudBridge.
    • RADIUS attribute = 26 (Vendor-Specific)
    • Vendor Code = 3845 (Citrix)
    • Vendor-assigned attribute number = any number (e.g. 1). Configure RADIUS policy on ADC with same attribute number.
    • Attribute value = Group Name
  10. Click Create.

    add authentication radiusAction RSA -serverIP 10.2.2.210 -serverPort 1812 -authTimeout 60 -radKey Passw0rd -passEncoding mschapv2

Advanced Authentication (nFactor) Policies for LDAP and RADIUS

For the older Classic Authentication policies, jump ahead to the Classic Policies section.

Create Advanced Authentication Policies:

  1. In the left menu, go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.
  2. On the right, click Add.
  3. In the Create Authentication Policy window:
    1. Change the Action Type to RADIUS.
    2. Select your RADIUS Action.
    3. Give the policy a name.
    4. Expression = true.
  4. Click Create.
  5. Create another Authentication Policy.
    1. Set Action Type to LDAP.
    2. Select your LDAP Action/Server.
    3. Give the policy a name.
    4. Expression = true.
  6. Click Create.

Create a Policy Label for the second factor, which is typically the RADIUS policy. The first factor (LDAP) does not need a Policy Label.

  1. In the left menu, click Policy Label.
  2. On the right, click Add.
  3. Give the Policy Label a name.
  4. Leave Login Schema set to LSCHEMA_INT. The Login Schema in the first factor will collect both password and passcode in one form so there’s no need for the second factor to collect it again.
  5. Click Continue.
  6. In the Select Policy field, select your RADIUS policy.
  7. Click Bind at the bottom of the page.
  8. Click Done to finish creating the Policy Label.

Create a Login Schema to collect the password and passcode on the same form.

  1. In the left menu, click Login Schema.
  2. On the right, switch to the tab named Profiles and then click Add.
  3. Give the Login Schema a name (e.g. DualAuth).
  4. Click the pencil icon and then open the LoginSchema folder.
  5. Click the DualAuth.xml file on the left. On the right, make sure you click the blue Select button. It’s too easy to miss this step.
    • See my nFactor article for some info on how to customize the Login Schema.
  6. Then click Create.
  7. On the right, switch to the tab named Policies.
  8. Give the Login Schema Policy a name.
  9. Select the Login Schema Profile you just created.
  10. Set the Rule field to true.
  11. Click Create.

Create an Authentication (AAA) Virtual Server to link the factors together.

  1. In the left menu, under AAA – Application Traffic, click Virtual Servers.
  2. On the right, click Add.
  3. Change the IP Address Type to Non Addressable.
  4. Give the AAA vServer a name and then click OK.
  5. In the Certificate section, you can optionally bind a certificate. It doesn’t matter what certificate you choose (typically the Gateway cert). The only thing this certificate binding does is make the AAA vServer show as UP instead of DOWN. Otherwise it has no effect on functionality. Click Continue.
  6. In the Advanced Authentication Policies section, click where it says No Authentication Policy.
  7. In the Select Policy field at the top of the window, select the LDAP policy.
  8. Near the bottom, in the Select Next Factor field, click where it says Click to select.
  9. Select your RADIUS Policy Label and then click Bind. After LDAP is done, nFactor will then move to your RADIUS Policy Label.
  10. Click Continue.
  11. On the right, in the Advanced Settings column, click Login Schemas.
  12. On the bottom left, click where it says No Login Schema.
  13. Select the DualAuth Login Schema you created earlier and then click Bind.
  14. Click Done at the bottom of the page.

Link the AAA vServer to your Gateway vServer:

  1. In the left menu, expand Citrix Gateway and then click Virtual Servers.
  2. On the right, edit your Gateway vServer.
  3. On the right, in the Advanced Settings column, click Authentication Profile.
  4. On the bottom left, in the Authentication Profile section, click the Add button.
  5. Select the AAA vServer you created earlier.
  6. Give the Profile a name and then click Create.
  7. Back in the Gateway vServer, make sure you click OK in the Authentication Profile section. If you forget to click OK then the Authentication Profile won’t be bound.

If you point your Workspace app to the Gateway that has nFactor configured, the authentication window will look like a web page.

Classic Authentication Policies for LDAP and RADIUS

For Advanced Authentication (nFactor) policies, jump back to the Advanced Policies section.

  1. Go to Citrix Gateway > Policies > Authentication > RADIUS.
  2. On the right, in the Policies tab, click Add.
  3. In the Create Authentication RADIUS Policy page:
    1. Name the policy RSA-ReceiverSelfService or similar.
    2. Select the RADIUS server created earlier.
    3. Enter an expression. You will need two policies with different expressions. The expression for Receiver Self-Service is REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver.
      Note: Citrix Gateway 12.1 does not natively support binding of Advanced Authentication Policies so you’ll have to create them as Basic Policies (classic expressions). You can only bind Advanced Authentication Policies using nFactor.
  4. Click Create.
  5. If you see a warning about deprecation, click OK, and ignore it.
  6. Create another RADIUS policy to match the ones shown below. Both RADIUS policies are configured with the same RADIUS server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS):
    Name Expression Server
    RSA-ReceiverSelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver RSA
    RSA-ReceiverForWeb REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver RSA

  7. Go to the Citrix Gateway\Policies\Authentication\LDAP node.
  8. On the Policies tab, create two policies with the expressions shown below. Both LDAP policies are configured with the same LDAP server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS).
    Name Expression Server
    LDAP-Corp-ReceiverSelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver LDAP-Corp
    LDAP-Corp-ReceiverForWeb REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver LDAP-Corp 

add authentication radiusPolicy RSA-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" RSA

add authentication radiusPolicy RSA-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" RSA

add authentication ldapPolicy Corp-Gateway-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" Corp-Gateway

add authentication ldapPolicy Corp-Gateway-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" Corp-Gateway

Bind Two-factor Policies to Gateway

  1. When you create or edit a Citrix Gateway Virtual Server, bind the Basic Authentication Policies as shown in the following table. Priority doesn’t matter because they are mutually exclusive.
    Policy Name Type Bind Point
    LDAP-Corp-ReceiverForWeb LDAP Primary
    RSA-ReceiverSelfService RADIUS Primary
    LDAP-Corp-ReceiverSelfService LDAP Secondary
    RSA-ReceiverForWeb RADIUS Secondary 

    bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverForWeb -priority 100

bind vpn vserver gateway.corp.com -policy RSA-ReceiverSelfService -priority 110

bind vpn vserver gateway.corp.com -policy RSA-ReceiverForWeb -priority 100 -secondary

bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverSelfService -priority 110 -secondary
  2. The Session Policy/Profile for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab is Credential Index. This needs to be changed to SECONDARY. Leave the session policy for Web Browsers set to Primary.

    set vpn sessionAction "Receiver Self-Service" -ssoCredential SECONDARY
  3. On the StoreFront server, when creating the Citrix Gateway object, on the Authentication Settings page, change the Logon type to Domain and security token. This instructs Receiver / Workspace app to properly handle two-factor authentication. If you change this setting after Receiver / Workspace app has already performed discovery, then users might have to remove the Account from Receiver / Workspace app and re-add it.

RADIUS Load Balancing – NetScaler 12

Last Modified: Apr 1, 2020 @ 6:41 am

33 Comments

Navigation

Change Log

  • 2018 Feb 17 – in RADIUS Monitor section, added Microsoft Network Policy Server Ping User-Name. (Source = Stefano Losego in the comments)
  • 2017 Dec 25 – updated entire article for 12.0 build 56. Monitor section has new build 56 instructions.

RADIUS Load Balancing Overview

One method of two-factor authentication to NetScaler Gateway is the RADIUS protocol with a two-factor authentication product (tokens) that has RADIUS enabled.

RADIUS Clients and Source IP – On your RADIUS servers, you’ll need to add the NetScaler appliances as RADIUS Clients. When NetScaler uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the NetScaler NSIP (NetScaler IP). Use the correct IP(s) when adding the NetScaler appliances as RADIUS Clients. And adjust firewall rules accordingly.

  • For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client, since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

RADIUS Monitor and Static Credentials – When load balancing RADIUS, you’ll want a monitor that verifies that the RADIUS server is functional. The RADIUS monitor will login to the RADIUS server and look for a response. The credentials in the load balancing monitor must have a static password.

  • If you don’t mind failed login attempts in your RADIUS logs, you can specify fake credentials in your load balancing monitor. The monitor would be configured to expect a login failure response, which means that at least a RADIUS service is responding to the monitor. Not as accurate as a successful login response, but better than ping.
  • The only other monitoring option is Ping. No credentials needed for this option. Adjust the firewall to allow ping to the RADIUS servers.

Active/passive load balancing – If you have RADIUS Servers in multiple datacenters, you can create multiple load balancing Virtual Servers, and cascade them so that the local RADIUS Servers are used first, and if they’re not available, then the Virtual Server fails over to RADIUS Servers in remote datacenters.

RADIUS Monitor

The RADIUS Monitor attempts to successfully log into the RADIUS server. For RSA, create an account on RSA with the following parameters as mentioned by Jonathan Pitre:

  • Setup a user with a fixed passcode in your RSA console.
  • Ensure you login with that user at least once to the RSA console because you’ll be asked to change it the first time.
  • There is no need to assign a token to your monitor user as long as you are using a fixed passcode. You don’t want to waste a token on a user just for monitoring.

Henny Louwers – Configure RSA RADIUS monitoring on NetScaler.

12.0 build 56 and newer

Monitor instructions changed in 12.0 build 56 and newer. If your build is older than build 56, then jump to the older Monitor instructions.

  1. In the NetScaler Configuration Utility, on the left, under Traffic Management > Load Balancing, click Monitors.
  2. On the right, click Add.
  3. Name the monitor RSA or similar.
  4. In the Type field, click where it says Click to select.
  5. Scroll down and click the circle next to RADIUS.
  6. Scroll up and click the blue Select button.
  7. In the Basic Parameters section, you might have to increase the Response Time-out to 4.
  8. In the Basic Parameters section, do the following:
    1. Enter valid RADIUS credentials. Make sure these credentials do not change or expire. For RSA, in the Password field, enter the fixed passcode.
    2. Enter the RADIUS key (secret) configured on the RADIUS server for the NetScaler as RADIUS client.
    3. For Response Codes, add both 2 and 3. 2 means success, while 3 indicates some kind of failure. Either result means that the RADIUS server is responding, and thus is probably functional. But 2 is the ideal response.
  9. Scroll down and click Create.

    add lb monitor RSA RADIUS -respCode 2-3 -userName ctxsvc -password Passw0rd -radKey Passw0rd -resptimeout 4
  10. Jump to the Servers section.

12.0 older than build 56

  1. In the NetScaler Configuration Utility, on the left, under Traffic Management > Load Balancing, click Monitors.
  2. On the right, click Add.
  3. Name the monitor RSA or similar.
  4. Change the Type drop-down to RADIUS.
  5. On the Standard Parameters tab, you might have to increase the Response Time-out to 4.
  6. On the Special Parameters tab, do the following:
    1. Enter valid RADIUS credentials. Make sure these credentials do not change or expire. For RSA, in the Password field, enter the fixed passcode.
    2. Also enter the RADIUS key (secret) configured on the RADIUS server for the NetScaler as RADIUS client.
    3. For Response Codes, add both 2 and 3. 2 means success, while 3 indicates some kind of failure. Either result means that the RADIUS server is responding, and thus is probably functional. But 2 is the ideal response.
  7. Click Create when done.

    add lb monitor RSA RADIUS -respCode 2-3 -userName ctxsvc -password Passw0rd -radKey Passw0rd -resptimeout 4

Servers

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter a descriptive server name; usually it matches the actual server name.
  4. Enter the IP address of the RADIUS server.
  5. Enter comments to describe the server. Click Create.

    add server RSA01 10.2.2.42
add server RSA02 10.2.2.43
  6. Continue adding RADIUS servers.

Service Groups

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, click Add.
  3. You will create one Service Group per datacenter. Enter a name reflecting the name of the datacenter.
  4. Change the Protocol to RADIUS.
  5. Scroll down, and click OK, to close the Basic Settings section.
  6. On the left, in the Service Group Members section, click where it says No Service Group Member.

    1. If you did not create server objects, then enter the IP address of a RADIUS Server in this datacenter. If you previously created a server object, then change the selection to Server Based, and select the server object(s).
    2. In the Port field, enter 1812 (RADIUS).
    3. Click Create.
  7. Click OK when done adding members.
  8. On the right, in the Advanced Settings column, click Monitors.

    1. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
    2. In the Select Monitor field, click where it says Click to select.
    3. Click the circle next to your new RADIUS monitor. It might be on page 2.
      • You must click the circle exactly (no room for error). If you click outside the circle, then the monitor will be opened for editing. If this happens, click Close to return to the selection screen.
    4. At the top of the window, click the blue Select button.
    5. Click Bind.
  9. To verify the members are up, click in the Service Group Members section.

    1. Right-click a member, and click Monitor Details.
    2. It should say Radius response code 2 (or 3) received. Click Close twice.
  10. Scroll down, and click Done to finish creating the Service Group.

    add serviceGroup svcgrp-RSA RADIUS
bind serviceGroup svcgrp-RSA RSA01 1812
bind serviceGroup svcgrp-RSA RSA02 1812
bind serviceGroup svcgrp-RSA -monitorName RSA
  11. Add additional service groups for RADIUS servers in each data center.

Virtual Server

  1. On the left, expand Traffic Management, expand Load Balancing, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Name it lbvip-RADIUS-HQ or similar. You will create one Virtual Server per datacenter so include the datacenter name.
    2. Change the Protocol drop-down to RADIUS.
    3. Enter a Virtual IP. This VIP cannot conflict with any other IP + Port already being used. You can use an existing VIP if the VIP is not already listening on UDP 1812.
    4. Enter 1812 as the Port.
  4. Click OK to close the Basic Settings section.
  5. In the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.

    1. Click where it says Click to select.
    2. Click the circle next to a previously created Service Group. It might be on Page 2.
      • You must click the circle exactly (no room for error). If you click outside the circle, then the Service Group will be opened for editing. If this happens, click the x on the top right, or click Done on the bottom, to return to the selection screen.
    3. At the top of the window, click the blue Select button.
    4. Click Bind.
  6. Click Continue.
  7. On the right, in the Advanced Settings section, click Method.
  8. On the left, in the Method section, do the following:
    1. Change the Load Balancing Method to TOKEN.
    2. In the Expression box, enter CLIENT.UDP.RADIUS.USERNAME.
  9. Click OK to close the Method section.
  10. On the right, in the Advanced Settings section, click Persistence.
  11. On the left, in the Persistence section, do the following:
    1. Change Persistence to RULE. Note: 12.0 build 56 and newer is slightly different than older builds.
    2. In the Expression box, enter CLIENT.UDP.RADIUS.USERNAME.
  12. Click OK to close the Persistence section.
  13. Scroll down and click Done to finish creating the Virtual Server.
  14. If you are configuring this RADIUS Load Balancer for more than just NetScaler Gateway, you can add another Load Balancer on port 1813 for RADIUS Accounting. Then you need a Persistency Group to tie the two load balancers together. See Configuring RADIUS Load Balancing with Persistence at Citrix Docs. 
    add lb vserver lbvip-RSA RADIUS 10.2.2.210 1812 -persistenceType RULE -lbMethod TOKEN -rule CLIENT.UDP.RADIUS.USERNAME
bind lb vserver lbvip-RSA svcgrp-RSA
  15. The new Virtual Server should show as Up. If not, click the Refresh icon on the top right of the screen (not the browser refresh).

Active/Passive Load Balancing

  1. Create additional Virtual Servers for each datacenter.

    1. These additional Virtual Servers do not need a VIP. so change the IP Address Type to Non Addressable. Only the first Virtual Server will be directly accessible.

      add lb vserver lbvip-RSA-Backup RADIUS 0.0.0.0 0 -persistenceType NONE -cltTimeout 120
    2. Notice that the additional datacenter Virtual Servers have an IP Address of 0.0.0.0 and port of 0.
  2. After you are done creating a Virtual Server for each datacenter, right-click the primary datacenter’s Virtual Server, and click Edit.
  3. On the right, in the Advanced Settings column, click Protection.
  4. On the left, in the Protection section, change the Backup Virtual Server to one of the other datacenter Virtual Servers. If all of the services in this datacenter are DOWN, the backup Virtual Server will be used instead. You can cascade multiple Virtual Servers using this method. Click OK and Done.

    set lb vserver lbvip-RSA -backupVServer lbvip-RSA-Backup
  5. You may now use this Virtual IP in your RADIUS authentication policies for NetScaler Gateway or NetScaler management login.

CLI Commands

Here is a list of CLI Commands for RADIUS load balancing.

# Load Balancing Global Parameters
# --------------------------------
enable ns mode FR L3 Edge USNIP PMTUD ULFD
set ns tcpParam -WS ENABLED -SACK ENABLED


# Monitors
# --------
add lb monitor RSA RADIUS -respCode 2-3 -userName rsamon -password Passw0rd -encrypted -encryptmethod ENCMTHD_3 -radKey Passw0rd -encrypted -encryptmethod ENCMTHD_3 -LRTM DISABLED -resptimeout 4


# Servers
# -------
add server RSA01 10.2.2.42

add server RSA02 10.2.2.43


# Service Groups
# --------------
add serviceGroup svcgrp-RSA-RADIUS-DR RADIUS -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport NO -cltTimeout 120 -svrTimeout 120 -CKA NO -TCPB NO -CMP NO
bind serviceGroup svcgrp-RSA-RADIUS-DR RSA01 1812
bind serviceGroup svcgrp-RSA-RADIUS-DR -monitorName RSA

add serviceGroup svcgrp-RSA-RADIUS-HQ RADIUS -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport NO -cltTimeout 120 -svrTimeout 120 -CKA NO -TCPB NO -CMP NO
bind serviceGroup svcgrp-RSA-RADIUS-HQ RSA02 1812
bind serviceGroup svcgrp-RSA-RADIUS-HQ -monitorName RSA


# Load Balancing Virtual Servers
# ------------------------------
add lb vserver lbvip-RADIUS-DR RADIUS 0.0.0.0 0 -persistenceType NONE -cltTimeout 120
bind lb vserver lbvip-RADIUS-DR svcgrp-RSA-RADIUS-DR

add lb vserver "lbvip-RADIUS HQ" RADIUS 10.2.5.70 1812 -persistenceType RULE -lbMethod TOKEN -rule CLIENT.UDP.RADIUS.USERNAME -cltTimeout 120 -backupVServer lbvip-RADIUS-DR
bind lb vserver "lbvip-RADIUS HQ" svcgrp-RSA-RADIUS-HQ

Citrix Gateway Tweaks

Last Modified: Jan 23, 2024 @ 3:58 pm

81 Comments

Navigation

💡 = Recently Updated

Change Log

Citrix Gateway Feature Licensing

Here is a listing of some Citrix Gateway features and the licenses they require:

Feature ADC Editions Universal Licenses?
StoreFront Load Balancing Standard/Enterprise/Platinum  
Global Server Load Balancing (GSLB) Enterprise/Platinum  
ICA Proxy and StoreFront Proxy All  
Two-factor Auth (RADIUS) All  
StoreFrontAuth (nFactor) Enterprise/Platinum  
nFactor Authentication Enterprise/Platinum  
Native OTP Authentication (nFactor) Enterprise/Platinum  
Self-Service Password Reset (SSPR) Enterprise/Platinum  
HDX Insight (AppFlow) Enterprise/Platinum  
SmartAccess All Yes
SmartControl Platinum Yes
RDP Proxy Enterprise/Platinum Yes
SSL VPN All Yes
PCoIP Proxy Enterprise/Platinum Yes
Unified Gateway Enterprise/Platinum Yes
Citrix SCOM MP for NetScaler Platinum  

All Editions = Citrix Gateway VPX, NetScaler Standard Edition, NetScaler Advanced Edition (formerly known as Enterprise Edition), and NetScaler Premium Edition (formerly known as Platinum Edition).

  • Citrix Gateway VPX is the inexpensive VPX appliance that only does Citrix Gateway. It doesn’t even do Load Balancing. This edition is no longer sold by Citrix.
  • NetScaler Advanced Edition is the minimum edition for many Gateway features, and thus is recommended for all Gateway purchases.

Gateway Universal Licenses – many Citrix Gateway features require Citrix Gateway Universal licenses for each concurrent connection to the Citrix Gateway Virtual Server. See the above table for which features require these licenses.

When you create a Citrix Gateway Virtual Server, in the Basic Settings section, the ICA Only setting determines if you need Citrix Gateway Universal licenses or not. If the Virtual Server is set to ICA Only is true, then features requiring Universal Licenses are disabled. But if ICA Only is set to false, then you need a Citrix Gateway Universal license for every user that connects to this Citrix Gateway Virtual Server.

Most editions of NetScaler include Gateway Universal licenses:

  • Citrix Gateway VPX does not come with any Gateway Universal Licenses. This edition is no longer sold by Citrix.
  • NetScaler Standard Edition comes with 500 Gateway Universal Licenses. This edition is no longer sold by Citrix.
  • NetScaler Advanced Edition comes with 1,000 Gateway Universal Licenses
  • NetScaler Premium Edition comes with unlimited Gateway Universal Licenses

If your NetScaler Edition does not include a sufficient number of Universal Licenses for your user load, then you can acquire these licenses through other means:

  • Citrix Virtual Apps and Desktops (CVAD) Premium Edition includes Gateway Universal licenses for each licensed user
  • “a la carte” Citrix Gateway Universal Licenses – these are very inexpensive

You can install more Gateway Universal licenses on the NetScaler appliance. The Gateway Universal licenses are allocated to the case sensitive hostname of each appliance. If you have an HA pair, and if each node has a different hostname, then allocate the Gateway Universal licenses to the first hostname, and then reallocate the same licenses to the other hostname.

To see the hostname, click your username on the top right.

To change the hostname:

  1. Click the gear icon on the top right. Note: this icon won’t work unless you are logged in as nsroot.
  2. Then click the third section.

Go to https://citrix.com/account and allocate your purchased Gateway Universal licenses to the hostname of the appliance.

To upload the allocated Gateway Universal licenses to the appliance, go to System > Licenses > Manage Licenses. A reboot is required.

To see the number of installed Gateway Universal licenses:

  1. On the left, expand System, and click Licenses.
  2. On the right, in the Maximum Citrix Gateway Users Allowed field is the number of licensed users for Citrix Gateway Virtual Servers that are not set to ICA Only.

RfWebUI Portal Theme

Citrix Blog Post Branding your Deployment Part 2: Matching NetScaler to StoreFront explains Citrix Gateway Portal Themes, how to edit the Portal Theme CSS, and warns about GUI changes overwriting CSS file changes.

NetScaler article Unleashing RfWebUI Potential: JavaScript-Powered Citrix Gateway Login Page Customization explains how to use JavaScript to customize the RfWebUI theme.

NetScaler article Visually change RFWebUI with CSS shows how to relocate the form header to the top of the username input field and make it bold and adjust the positioning of the “User name:” and “Password:” labels nearer to the input fields.

If you want the logon page for Citrix Gateway to look like Citrix Cloud, then see CTX258331 Customizing the on-premises Citrix Gateway authentication page to look identical to Citrix Cloud logon page.

If you want the logon page for Citrix Gateway to look more like StoreFront 3.0 and newer, enable the built-in RfWebUI or X1 theme. RfWebUI is optimized for Unified Gateway (Clientless VPN) since it provides the exact same appearance and user experience as StoreFront 3.x. The Unified Gateway RfWebUI theme can display RDP Links, Web Links (bookmarks), PCoIP published icons, along with the familiar StoreFront apps and desktops. Note: RfWebUI requires StoreFront 3.6 or newer.

  1. Go to Citrix Gateway > Virtual Servers and edit an existing Virtual Server.
  2. If you see the Portal Theme section on the left:
    • Then click the pencil icon.
  3. If you don’t see Portal Theme on the left:
    • On the right, in the Advanced Settings section, click Portal Themes.
  4. On the left, change the Portal Theme drop-down to RfWebUI. Click OK.
  5. Click Done to close the Gateway Virtual Server. 
    bind vpn vserver gateway.corp.com -portaltheme RfWebUI
  6. When you access the Citrix Gateway login page you’ll see the theme.

RfWebUI Customizations

Custom Portal Theme

You can create your own theme by starting from one of the built-in themes:

  1. Go to Citrix Gateway > Portal Themes.
  2. On the right, click Add.
  3. Give the theme a name, select RfWebUI as the Template Theme, and click OK.
  4. In the Look and Feel section, there are two sub-sections: one for Home Page Attributes, and one for Common Attributes.
  5. The Home Page Attributes section is for Unified Gateway (aka VPN Clientless Access). Notice that the Websites Sections can be disabled.
  6. The Help Legend link at the top of the section shows you what the other fields modify.

  7. If you want to modify some attributes of the logon page, use the Common Attributes sub-section. The labels are changed later.
  8. The Help Legend link at the top of the Common Attributes section shows you what the fields modify.
  9. Make changes as desired, and click OK at the bottom of the page.
  10. After you click OK, the Language section appears.
  11. In the Language section, select a language, and click OK.
  12. On the right, in the Advanced Settings section, click Login Page.
  13. Make changes as desired (e.g. Password Field Titles), and click OK.
  14. At the top of the screen, click the link to Click to Bind and View Configured Theme.
  15. Select a Gateway Virtual Server, and click Bind and Preview. Notice that you can also bind Portal Themes to AAA vServers.
  16. The logon page is displayed.
  17. You could go to /var/netscaler/logon/themes/MyTheme/css and make more changes to custom.css, but this file gets overwritten any time you make a change in the Portal Themes section of the NetScaler GUI.
  18. Citrix CTX209526 NetScaler; How to Copy a Portal Theme from the Device running version 11.0 to another Device running 11.0.

Public DNS SRV Records

When a user launches Receiver, instead of typing in the Gateway FQDN, the user can enter an email address. Receiver uses the email suffix to lookup the Gateway FQDN. It does this by looking for an SRV record named _citrixreceiver._tcp in the email suffix’s domain (e.g. _citrixreceiver._tcp.corp.com). If you have multiple email suffixes, then you need to add the SRV record to each email suffix DNS zone.

Note: to eliminate certificate and/or trust prompts, the Gateway certificate must match discoverReceiver.email.suffix (e.g discoverReceiver.corp.com). If you have multiple email suffixes, then you need the certificate to match every email suffix.

To enable email-based discovery, add a SRV record to each public email suffix DNS zone. Here are sample instructions for a Windows DNS server:

  1. In Server Manager, click Tools > DNS.
  2. In the left pane of DNS Manager, right-click your DNS domain, and click Other New Records.
  3. In the Resource Record Type dialog box, select Service Location (SRV), and then click Create Record.
  4. In the New Resource Record dialog box, do the following:
    1. In the Service box, enter the host value _citrixreceiver.
    2. In the Protocol box, enter the value _tcp.
    3. In the Port number box, enter 443.
    4. In the Host offering this service box, specify the fully qualified domain name (FQDN) for your Citrix Gateway Virtual Server in the form servername.domain (e.g. gateway.company.com).
  5. Click OK to close the New Resource Record dialog box.
  6. Click Done to close the Resource Record Type dialog box.

Customize Logon Page

Logon Page Labels

When two factor authentication is configured on Citrix Gateway, the user is prompted for User name, Password, and Password 2.

The Password field labels can be changed to something more descriptive, such as Active Directory or RSA:

To change the labels, edit a Portal Theme:

  1. Go to Citrix Gateway > Portal Themes, and edit an existing theme. You can’t edit the built-in themes, so you’ll have to create one if you haven’t already.
  2. If you see the Login Page section on the left:
    • Click the pencil icon in the Login Page section.
  3. If you don’t see the Login Page section on the left:
    • On the right, in the Advanced Settings column, click Login Page to add it to the left.
  4. On the left, in the Login Page section, change the two Password fields to your desired text.
  5. Click OK to close the Login Page section.
  6. If you are using the RfWebUI theme, the default text size for the form field labels is 17px. However, the Portal Themes editor defaults to 12px. You can change it back to 16px or 18px by doing the following:
    1. In the Look and Feel section, click the pencil icon.
    2. Scroll down to the Common Attributes section.
    3. Change the Form Font Size drop-down to 16px or 18px.
    4. Click OK to close the Look and Feel section.
  7. In the Portal Theme section at the top of the page, you can Click to Bind and View Configured Theme to Preview your changes.
  8. You might have to invalidate the loginstaticobjects Integrated Caching Content Group (Optimization > Integrated Caching > Content Groups) before the changes appear. This seems to be true even if Integrated Caching is disabled.

 Logon Security Message (Disclaimer, EULA)

You can force users to agree to a EULA before they are allowed to login.

Clicking the Terms & Conditions link allows the user to view the EULA text that you have entered.

Do the following to configure the EULA:

  1. Go to Citrix Gateway > Resources > EULA.
  2. On the right, click Add.
  3. Give the EULA a name, and enter some text. You can even enter HTML code. See the example posted by Chris Doran at Citrix Discussions.
  4. Scroll down, and click Create.
  5. Edit a Gateway Virtual Server.
  6. On the right, in the Advanced Settings column, click EULA.
  7. On the left, in the EULA section, click where it says No EULA.
  8. Click where it says Click to select.
  9. Click the radio button next to the previously created EULA, and click Select.
  10. Click Bind.
  11. Mike Roselli at Automatic EULA Acceptance by Cookie Rewrite Guide at Citrix Discussions details Rewrite policies that change the behavior so that users only have to accept the EULA once. It records acceptance in a cookie.
  12. Sam Jacobs Adding an EULA for AAA Login at CUGC explains how to enable the EULA on the AAA logon page.

Theme File Customization

The original themes (Default, Green Bubble, and X1) use files from /netscaler/ns_gui/vpn/js and /var/netscaler/logon/themes. A commonly edited file is /netscaler/ns_gui/vpn/js/gateway_login_form_view.js since this file is responsible for rendering the logon form.

The new RfWebUI theme is different than the original themes, because it pulls files from /var/netscaler/logon/LogonPoint/receiver. This means the customizations for NetScaler 11.0 won’t work with the new RfWebUI theme. When reviewing customization guides for NetScaler 11, be aware that most of them won’t work for the RfWebUI theme.

Citrix CTX202444 How to Customize NetScaler Gateway 11 logon Page with Links shows how to add links to the Citrix Gateway 11 logon page. This only works in the Default, Green Bubble, and X1 themes (no RfWebUI theme).

Other Customizations

CTP Sam Jacobs at Adding Text, Links and Other Elements to the NetScaler Logon Page – Part 2 at CUGC explains how to add text to the RfWebUI theme logon page. The process for RfWebUI is quite different than the older themes:

  • Text is stored in /var/netscaler/logon/themes/<theme>/strings.<language code>.json
  • Custom CSS is stored in /var/netscaler/logon/themes/<theme>/css/theme.css
  • Sample Logon Page:

CTP Sam Jacobs at Adding Text, Links and Other Elements to the NetScaler Logon Page – Part 1 at CUGC explains how to modify custom.css and en.xml to add text below the logon box on the Logon Page. No Rewrite policies or source code modifications needed.

Mike Roselli at Netscaler 11 Theme Customization – How to Add Links and Verbiage at Citrix Discussions has sample rewrite policies to customize the Citrix Gateway logon page with additional HTML.

 

Craig Tolley Customising the NetScaler 11 User Interface – Adding Extra Content: add new sections to login page. These sections pull content from local HTML files.

 

Daniel Ruiz Set up a maintenance page on NetScaler Gateway: configure a Responder policy (see the blog post for sample HTML code). During maintenance, manually bind the Responder policy to the Gateway. Manually remove the policy after maintenance is complete.

 

Manuel Kolloff Adding additional languages to NetScaler RfWebUI Theme

 UDP Audio Through Gateway

From John Crawford at Citrix Discussions and Marius Sandbu Enabling Citrix Receiver audio over NetScaler Gateway with DTLS

Note: Enabling DTLS on the Gateway also enables the Gateway to support EDT (Adaptive Transport) and Framehawk.

Requirements for UDP Audio:

  • Citrix Receiver 4.2 or newer
  • UDP 443 allowed to Citrix Gateway Virtual Server
  • UDP 16500-16509 allowed from Citrix SNIP to the VDAs

To enable UDP Audio through Gateway, make changes on both the Citrix Gateway Virtual Server, and in Receiver:

  1. Edit a Citrix Gateway Virtual Server.
  2. In the Basic Settings section, click the pencil icon.
  3. Click More.
  4. Enable the DTLS option, and click OK.
  5. After enabling DTLS, it probably won’t work until you unbind the Gateway certificate, and rebind it.
    1. On the left, click where it says 1 Server Certificate.
    2. Click Add Binding.
    3. Click where it says Click to select.
    4. Click the radio button next to the same certificate that’s already bound. Click Select.
    5. Click Bind.
    6. Click Close.
    7. Click Continue to close the Certificate section.

Client-side configuration

There are two methods of enabling RTP on the client side:

  • Edit default.ica on the StoreFront server
  • Use GPO to modify the client-side config

To edit the default.ica file on the StoreFront server (h/t Vipin Borkar): Edit the file C:\inetpub\wwwroot\Citrix\Store\App_Data\default.ica and add the following lines to the Application section:

EnableRtpAudio=true
EnableUDPThroughGateway=true
AudioBandwidthLimit=1

To use GPO to modify the client-side config:

  1. Copy the receiver.admx (and .adml) policy template into PolicyDefinitions if you haven’t already.
  2. Edit a GPO that applies to Receiver machines. You can also edit the local GPO on a Receiver machine.
  3. Go to Computer Configuration | Policies | Administrative Templates | Citrix Components | Citrix Workspace app | User Experience.
  4. On the right, edit the setting Client audio settings.
  5. Do the following in the Client audio settings dialog box.
    1. Enable the setting.
    2. Set audio quality as desired. Higher quality = higher bandwidth.
    3. Check to Enable Real-Time Transport.
    4. Check to Allow Real-Time Transport through Gateway.
  6. Click OK to close the Client audio settings dialog box.
  7. Look in the client-side registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Audio to make sure the registry keys applied.
  8. When you launch the first session after enabling Real-Time Transport, you might be prompted to enable it through the client-side firewall.

To view the current UDP Audio sessions:

  1. In the NetScaler GUI, click the Citrix Gateway node.
  2. On the right, click DTLS ICA Connections.
  3. This will show you all users that have UDP Audio connections through Citrix Gateway. Note: this is different than EDT. To see EDT (UDP) HDX connections, click ICA Connections instead.

Citrix VPN from Mobile Devices

Links:

Citrix VPN Clients on Mobile Devices (Android, iOS) contain one of the following in their User-Agent strings. You can use this text in a Session Policy expression.

  • CitrixReceiver/NSGiOSplugin
  • CitrixReceiver/CitrixVPN

To block the Citrix VPN client connections from mobile devices, do one of the following:

  • Create an AppExpert > Responder > Policy with Action = DROP and Expression = HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver/NSGiOSplugin")|| HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver/CitrixVPN"). Either bind the Responder Policy Globally, or bind it to the Gateway vServers.
  • In your Gateway Session Policies, on the Client Experience tab, set the Plug-in Type to Java. If any of them are set to Windows/MAC OS X, then VPN for Mobile is allowed.

StoreFront – Rewrite X-Citrix-Via

When Citrix Gateway communicates with StoreFront, it adds a header called X-Citrix-Via that contains the FQDN entered in the user’s address bar. StoreFront uses this header to find a matching Gateway object so StoreFront knows how to handle the authentication. In Citrix Gateway 11.0 and newer, you can create a rewrite policy to change this header. This is useful when changing URLs or using DNS aliases for Gateways. See CTX202442 FAQ: Modify HTTP Header X-Citrix-Via on NetScaler for more details.

Here’s a sample rewrite policy for this header:

enable ns feature REWRITE

add rewrite action rwact_storefront replace "HTTP.REQ.HEADER(\"X-Citrix-Via\")" "\"mystorefront.mydomain.com\""

add rewrite policy rwpol_storefront "HTTP.REQ.HEADER(\"X-Citrix-Via\").NE(\"mystorefront.mydomain.com\")" rwact_storefront

bind vpn vserver mygateway-vs -policy rwpol_storefront -priority 100 -type REQUEST

Device Certificates

Citrix Gateway can require Device Certificates (machine based) before a user can login. The Endpoint Analysis Plug-in reads the machine certificate, and compares it to a CA certificate that is bound to the Citrix Gateway Virtual Server.

  • Device Certificates are different from User Certificates.
  • Administrator permissions are required to access the machine certificate’s private key. Citrix Gateway Plug-in (VPN client) can workaround this requirement.
  • OCSP is required. You can use Microsoft Online Responder.

To enable Device Certificates on Citrix Gateway

  1. Create a OCSP Responder on NetScaler and bind it to the CA Certificate. See CTX200290 How to Configure Device Certificate on NetScaler Gateway for details. At Traffic Management > SSL > Certificates > OCSP Responder.

    1. The URL for Microsoft Online Responder is http://ocsp_server_FQDN:80/ocsp.
    2. Misja Geuskens at Netscaler Device certificate checks fails with W2K12R2 Online responder says don’t check the Nonce box.
  2. Import CA certificates for Root and Intermediate. At Traffic Management > SSL > Certificates > CA Certificates.
  3. Right-click each CA certificate, and click OCSP Bindings.

    1. Select the OCSP Responder you created earlier.
  4. Bind the CA certificates to the Gateway Virtual Server in the CA certificates section.

  5. Enable Device Certificates in the Citrix Gateway Virtual Server > Basic Settings > More section. Move the same CA certificates to the right.

Device Certificates in nFactor (AAA)

nFactor Endpoint Analysis also supports Device Certificates. OCSP (described earlier) is also required for this feature.

  1. It’s probably easier to search the menu for EPA than to actually navigate to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions > EPA.
  2. On the right, click Add.
  3. On the bottom right, click EPA Editor.
  4. Change the first drop-down to Common.
  5. Change the second drop-down to Device Certificate and then click Done
  6. Give the EPA Action a name and then click Create.
  7. You can now use this EPA Action in your nFactor configuration.
  8. On the Gateway Virtual Server, bind CA certificates as described in the previous section.
  9. On the AAA Virtual Server, click the pencil in the Basic Settings section.
  10. Click More.
  11. Near the bottom, click Add next to the CA for Device Certificate section to bind CA certificates. Then click OK.

User Experience

Users will be prompted to install the Endpoint Analysis plugin.

Click Yes to run the scan. Note: if the user is not an administrator of the local machine, then you must also install the Citrix Gateway Plug-in (VPN client) to handle the security restrictions.

If there are multiple certificates on the client machine, the user will be prompted to select one.

The chosen machine certificate is stored in %localappdata%\Citrix\AGEE\config.js. The user won’t be prompted for certificate selection again unless you delete this file.

This same folder contains nsepa.txt, which lets you troubleshoot device certificate checking. The most common issue is lack of permissions, which is handled by installing the Citrix Gateway VPN Plug-in. The Gateway VPN Plug-in version must match the firmware version.

LDAP Authentication – Citrix Gateway

Last Modified: Nov 7, 2020 @ 6:34 am

62 Comments

This article applies to Citrix Gateway 13.0, Citrix Gateway 12.1, and NetScaler Gateway 12.0. Citrix ADC is the new name for NetScaler. Citrix Gateway is the new name for NetScaler Gateway.

Navigation

💡 = Recently Updated

Change Log

  • 2018 Dec 21 – updated screenshots for Citrix Gateway 12.1

LDAP Load Balancing

Before you create an LDAP authentication policy, load balance the Domain Controllers. If you don’t load balance your Domain Controllers, then when users enter an incorrect password, the user account will be prematurely locked out because it makes a failed login attempt against each Domain Controller.

If you have multiple domains, create different Load Balancing Virtual Servers for each domain. These multiple Load Balancing Virtual Servers can share the same VIP if their port numbers are different. Or you can use a different VIP for each domain.

Verify LDAPS

Use the tool ldp.exe to verify that the Domain Controllers have valid certificates installed, and the LDAP service account is able to bind to the LDAP tree.

  1. ldp.exe is included with the Remote Server Administration Tools (AD DS Snap-Ins and Command-Line Tools). On Windows Servers, install it from Server Manager > Add Roles and Features > Features > Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools > AD DS Tools.
  2. Run ldp.exe.
  3. Open the Connection menu, and click Connect.
  4. In the Connect box:
    1. Enter the FQDN of a Domain Controller.
    2. Check the box next to SSL.
    3. Change the port to 636.
  5. Click OK.
  6. If it connected successfully, you can then attempt a bind. If the connection was unsuccessful, then there’s probably an issue with the certificate installed on the Domain Controller.
  7. Open the Connection menu, and click Bind.
  8. In the Bind box:
    1. Change the Bind type to Simple bind.
    2. Enter the service account credentials. You can enter DOMAIN\Username, or you can enter Username@Domain.com.
  9. Click OK.
  10. Look in the right pane to verify a successful bind. If not, fix the credentials and try again.
  11. Once you have successfully binded, you can view the directory tree by opening the View menu, and click Tree.
  12. Click the drop-down to view the directory partitions.
  13. Repeat these steps to verify each Domain Controller, and any load balanced LDAPS.

LDAP Authentication Server

You can configure StoreFrontAuth as an alternative to LDAP. StoreFrontAuth delegates authentication to StoreFront servers instead of performing authentication on Citrix ADC.

To create the LDAP Authentication Server, do the following:

  1. On the left, expand Authentication, and click Dashboard.
  2. On the right, click Add.
  3. Change the Choose Server Type drop-down to LDAP.
  4. In the Name field, enter LDAP-Corp or similar as the name. If you have multiple domains, you’ll need a separate LDAP Server per domain. so make sure you include the domain name.
  5. Change the selection to Server IP. Enter the VIP of the load balancing vServer for LDAP.
  6. Change the Security Type drop-down to SSL.
  7. Enter 636 as the Port. Scroll down.

  8. In the Connection Settings section, do the following:
    1. In the Base DN field, enter your Active Directory DNS domain name in LDAP format.
    2. In the Administrator Bind DN field, enter the credentials of the LDAP bind account in userPrincipalName format. Domain\Username also works.
    3. Enter the Administrator Password.
    4. Click Test Connection. Citrix ADC will attempt to login to the LDAP IP.
  9. Scroll down.
  10. In the Other Settings section, use the drop-downs next to Server Logon Name Attribute, Group Attribute, and Sub Attribute Name to select the default fields for Active Directory.
  11. On the right side of the Other Settings section, check the box next to Allow Password Change.

  12. If you want to restrict Citrix Gateway access to only members of a specific AD group, in the Search Filter field, enter memberOf=<GroupDN>. See the example below:
    memberOf=CN=CitrixRemote,OU=Citrix,DC=corp,DC=local
    You can add :1.2.840.113556.1.4.1941: to the Search Filter so it searches through nested groups. Without this, users will need to be direct members of the filtered group.
    memberOf:1.2.840.113556.1.4.1941:=CN=CitrixRemote,OU=Citrix,DC=corp,DC=local

    Citrix CTX132802 How to Use the ldapsearch Utility on the NetScaler Gateway Enterprise Edition Appliance to Validate a Search Filter
    1. An easy way to get the full distinguished name of the group is through Active Directory Users and Computers.
    2. Open the View menu, and enable Advanced Features. The Attribute Editor is only present if this feature is enabled.
    3. Browse to the group object, right-click it, and click Properties. Note: you cannot use Find. Instead, you must navigate through the tree to find the object.
    4. Switch to the Extensions page. On the right, switch to the Attribute Editor tab. This tab is only visible if Advanced Features are enabled, and you didn’t use the Find feature.
    5. Scroll down to distinguishedName, double-click it, and then copy it to the clipboard.
    6. Back on the Citrix ADC, in the Search Filter field, type in memberOf= and then paste the Distinguished Name right after the equals sign. Don’t worry about spaces.
  13. For another LDAP Search Filter expression, see CTX226808 Expression to exclude multiple domains by using search filter in LDAP on NetScaler 
    !(|(userprincipalname=*@aa.lab.com)(userprincipalname=*@ns.lab.com)
  14. Scroll down, and click More.
  15. For Nested Group Extraction, if desired, change the selection to Enabled. Configuring Nested Group Extraction allows the Nested Groups to be used for AAA Groups.
    1. Set Group Name Identifier to samAccountName.
    2. Set Group Search Attribute to memberOf. Select << New >> first.
    3. Set Group Search Sub-Attribute to CN. Select << New >> first.
    4. For the Group Search Filter field, see CTX123795 Example of LDAP Nested Group Search Filter Syntax.
  16. Scroll down, and click Create.

    add authentication ldapAction Corp-Gateway -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword Passw0rd -ldapLoginName samaccountname -searchFilter "memberOf:1.2.840.113556.1.4.1941:=CN=Citrix Remote,CN=Users,DC=corp,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
  17. The status of the LDAP Server should be Up.

LDAP Policy Expression

The Authentication Dashboard doesn’t allow you to create the LDAP Policy, so you must create it elsewhere.

You can create the LDAP policy now. Or you can wait and create it later when you bind the LDAP Server to the Citrix Gateway vServer.

To create it now:

  1. Enter LDAP in the menu Search box to find one of the nodes that lets you create Basic Authentication Policies.

    • Or, navigate to Citrix Gateway > Policies > Authentication > LDAP.
  2. On the right, in the Policies tab, click Add.
  3. Change the Server drop-down to the LDAP Server you created earlier.
  4. Give the LDAP Policy a name (one for each domain).
  5. In the Expression box, enter ns_true.
    • Citrix Gateway does not support Advanced Authentication policies bound directly to the Gateway Virtual Server. If you prefer Advanced Authentication Policies, then you’ll instead need to configure nFactor.
  6. Click Create.

     add authentication ldapPolicy LDAP-Corp ns_true LDAP-Corp
  7. If you see a message about classic authentication policies deprecation, click OK and ignore it.

Gateway Authentication Feedback

  1. On the left, under Citrix Gateway, click Global Settings.
  2. On the right, in the right column, click Change authentication AAA settings.
  3. Optionally, near the middle of the page, check the box for Enable Enhanced Authentication Feedback. This feature provides a message to users if authentication fails. The messages users receive include password errors, account disabled or locked, or the user is not found, to name a few. This setting might not be advisable in a secure environment.
  4. Click OK.

    set aaa parameter -enableEnhancedAuthFeedback YES

Next Step

Multiple Domains – UPN Method

Cascade – To support multiple Active Directory domains on a Citrix Gateway, you create multiple LDAP authentication policies, one for each Active Directory domain, and bind all of the LDAP policies to the Citrix Gateway Virtual Server. When the user logs into Citrix Gateway, only the username and password are entered. The Citrix ADC will then loop through each of the LDAP policies in priority order until it finds one that contains the entered username/password.

Same user/password in multiple domains – What if the same username is present in multiple domains? As Citrix ADC loops through the LDAP policies, as soon as it finds one with the specified username, it will try to authenticate with that particular LDAP policy. If the password doesn’t match the user account for the attempted domain, then a failed logon attempt will be logged in that domain and Citrix ADC will try the next domain.

Unfortunately, the only way to enter a realm/domain name during user authentication is to require users to login using userPrincipalNames. To use userPrincipalName, configure the LDAP Policy/Server with the Server Logon Name Attribute set to userPrincipalName.

You can even do a combination of policies: some with samAccountName, and some with userPrincipalName. Bind the userPrincipalName policies with higher priority (lower priority number) than the samAccountName policies so the UPN policies are tried first.

Citrix ADC supports adding a domain name drop-down list to the logon page. Then use Cookie expressions in the auth policies and session policies. However, this probably doesn’t work when authenticating through Workspace app or Receiver. See CTX203873 How to Add Drop-Down Menu with Domain Names on Logon Page for NetScaler Gateway 11.0 64.x and later releases for details.

Another option for a domain drop-down is nFactor Authentication for Citrix Gateway. The newest versions of Citrix ADC 12.1 are supposed to support nFactor authentication in the newest versions of Workspace app.

After authentication is complete, a Session Policy will be applied that has the StoreFront URL. The Citrix Gateway will attempt to Single Sign-on to StoreFront so the user doesn’t have to login again. When logging into Citrix Gateway, only two fields are required: username and password. However, when logging in to StoreFront, a third field is required: domain name. So how does Citrix ADC specify the domain name while logging in to StoreFront?

In a single domain configuration, you simply edit your Session Policy/Profile and on the Published Applications tab configure the Single Sign-on field with your domain name. However, this method won’t work if users are authenticating to multiple domains.

For authentication to multiple domains, Citrix Gateway has two methods of identifying the domain name based on which LDAP Policy/Server authenticated the user:

  • userPrincipalName – the easiest method is to configure the LDAP policy/server to extract the user’s UPN, and then Single Sign-on to StoreFront using UPN. This is the easiest method, but some domains don’t have userPrincipalNames configured correctly. StoreFront needs to accept the userPrincipalName suffixes.
  • AAA Group – as the Citrix ADC loops through the LDAP policies during authentication, once a successful LDAP policy is found, the LDAP Server can put the user in a domain-specific AAA Group. Then you can bind a Session Policy with domain name to the domain-specific AAA Group.
    • LDAP Servers have a field called Default Authentication Group. If the user successfully authenticates with this LDAP Server, then the user is placed in the AAA Group name specified here. Specify a unique Default Authentication Group per LDAP Server. Then create AAA Groups with the same names you specified in the LDAP Servers. Bind domain-specific Session Policies with domain name to each of the AAA Groups. See Multiple Domains – AAA Group Method for details.
    • Another option is to create a unique domain-specific group in each Active Directory domain and add users to these domain-specific groups. Each domain has a different name for this AD group. Citrix ADC will extract this group during the user’s login. Create AAA Groups on Citrix ADC that match these Active Directory group names and bind domain-specific Session Policies with domain name to each of the AAA Groups.

The userPrincipalName method is detailed below:

  1. In each of your Citrix ADC LDAP policies/servers, in the Other Settings section, in the SSO Name Attribute field, enter userPrincipalName (select –<< New >>– first). Make sure there are no spaces after this attribute name. Citrix ADC will pull this attribute from AD, and use it to Single Sign-on the user to StoreFront. Notice that Server Logon Name Attribute is still sAMAccountName.
  2. In StoreFront Console, in the middle, right-click your Store, and click Manage Authentication Methods.
  3. On the right, click the gear icon, and then click Configure Trusted Domains.
  4. In the Trusted domains box, select Any domain.
  5. Or add your UPN domain suffixes in DNS format. The advantage of entering domain names is that you can select a default domain. The DNS format is required for UPN logins (e.g. SSO from Citrix Gateway).
  6. On the Citrix Gateway Virtual Server, bind LDAP authentication polices in priority order. It will search them in order until it finds a match.
  7. In your Session Policies/Profiles, in the tab named Published Applications, make sure Single Sign-on Domain is not configured. Since Citrix ADC is using the userPrincipalName, which inherently contains a domain name, there’s no need for a Session Policy to specify a domain name. If the Single Sign-on Domain field is configured, then Single Sign-on authentication will fail.

Multiple Domains – AAA Groups Method

Another method of specifying the domain name when performing Single Sign-on to StoreFront is to use a unique session policy/profile for each domain. Use AAA Groups to distinguish one domain from another.

  1. Go to Citrix Gateway > Policies > Authentication > LDAP. The easiest way to get there is to enter LDAP in the search box at to the top of the menu.
  2. On the right, switch to the tab named Servers.
  3. Make sure all domains are in the list. Edit the LDAP Server for one of the domains.
  4. Scroll down to the Other Settings section,
  5. On the right, in the Default Authentication Group field, enter a new, unique group name. Each domain must a different group name. This group is only locally significant and does not need to be added to AD. Click OK.
  6. Edit the LDAP Server for another domain.
  7. Specify a new unique group name for this domain. Each domain has a different group name.
  8. In the menu, go to Citrix Gateway > User Administration > AAA Groups.
  9. On the right, click Add.
  10. Name the group so it exactly matches the group name you specified in the LDAP Server. Click OK.
  11. On the right, in the Advanced Settings section, click Policies to move it to the left.
  12. On the left, in the Policies section, click the Plus icon.

    1. In the Choose Type page, select Session, and click Continue.
    2. Click the Add button or plus icon to create a new Session policy.
    3. Give the Session Policy a name that indicates the domain. You will have a separate Session Policy for each domain.
    4. Click the Add button or plus icon to create a new Session Profile.
    5. Give the Session Profile a name that indicates the domain. You will have a separate profile for each domain.
    6. Switch to the tab named Published Applications.
    7. Scroll down and next to Single Sign-on Domain check the Override Global box .
    8. Enter the domain name that StoreFront is expecting for this LDAP Server. Click Create.
    9. If your other Session Policies are created using Advanced syntax, then leave this Session Policy as Advanced Policy and enter true as the Expression.
      • If your other Session Policies are created using Classic syntax, then change this Session Policy to Classic Policy and enter ns_true as the Expression.
    10. Click Create.
    11. In the Priority field, give it a number that is lower than any other Session Policy that has Single Sign-on Domain configured so that this Session Policy will override those other Session Policies. Then click Bind.
    12. Click Done.
  13. Create another AAA Group.
  14. Give it the AAA Group a name that matches the Default Authorization Group configured for the next domain.
  15. On the right, click Policies to move it to the left.
  16. On the left, click the Plus icon to add a policy binding.
  17. For Choose Type, select Session and click Continue.
  18. In the Policy Binding field, click Add to create another Session Policy.
  19. In the Profile drop-down, click Add to create another Session Profile.
  20. On the Published Applications tab, specify the domain name of the next domain.
  21. Set the Session Policy Expression to either true (Advanced) or ns_true (Classic).
  22. Bind the new policy with a low Priority number.
  23. When a user logs in, Citrix ADC loops through LDAP policies until one of them works. Citrix ADC adds the user to the Default Authentication Group specified in the LDAP Server. Citrix Gateway finds a matching AAA Group and applies the Session Policy that has SSON Domain configured. Since the policy is bound with a low priority number, it overrides any other Session Policy that also has SSON Domain configured.

Domain Controller (LDAPS) Load Balancing – Citrix ADC

Last Modified: Apr 12, 2023 @ 4:29 am

84 Comments

Navigation

💡 = Recently Updated

Changelog

  • 2017 Dec 25 – updated entire article for 12.0 build 56. Monitor section has new build 56 instructions.

Overview

If you plan to use LDAP (Active Directory) for Citrix Gateway, or Citrix ADC management authentication, then load balance the Domain Controllers that are used for authentication. A single LDAP Policy/Server points to the load balanced VIP.

Premature lockout – An alternative to load balancing is to bind multiple LDAP Policies, with each Policy pointing to a single Domain Controller in the same domain. However, Citrix ADC will try each authentication policy until it finds one that works. If the user enters a wrong password, and if you have three authentication policies pointing to different Domain Controllers in the same domain, then three different failure attempts will be recorded, thus causing premature account lockout. Use Load Balancing to avoid this behavior.

LDAPS and certificates – This page details LDAPS, aka Secure LDAP. This protocol requires certificates to be installed on the Domain Controllers. When a user’s password expires, Active Directory does not allow password changes over clear text LDAP, so LDAPS must be used instead. Make sure you have certificates installed on your Domain Controllers. The easiest way to accomplish that is to deploy a Microsoft Certificate Authority in Enterprise Mode, which allows the Domain Controllers to request certificates automatically.

Monitor -An ldaps monitor can be used to verify that the Domain Controller is functional.

  • The ldaps monitor will login as an account, perform an LDAP query, and look for a successful response. The ldaps monitor uses a service account to login. Make sure the service account’s password does not expire. Domain User permissions are sufficient.
  • Since this monitor is a Perl script, it uses NSIP as the source IP. You can use RNAT to override this as described in Configure to source Citrix ADC FreeBSD data traffic from a SNIP address at Citrix Docs.

Multiple datacenters – If you have Domain Controllers in multiple datacenters, you can create multiple load balancing Virtual Servers, and cascade them so that the local Domain Controllers are used first, and if they’re not available, then the Virtual Server fails over to Domain Controllers in remote datacenters.

Load Balancing Protocol – The Load Balancing Virtual Server for LDAPS can be TCP protocol or SSL_TCP protocol:

  • TCP – If the protocol is TCP, then SSL-encrypted LDAP traffic is not terminated on the Citrix ADC, and is simply forwarded to the LDAP servers. If your LDAP client (e.g. Linux machine) needs to verify the LDAP server certificate, then this Load Balancing configuration will not work, since each back-end LDAP server will have a different certificate.
  • SSL_TCP – If your Load Balancing Virtual Server is protocol SSL_TCP, then a certificate must be installed on the Citrix ADC and bound to the Load Balancing Virtual Server. SSL is terminated at the Citrix ADC and re-encrypted before sending it to the destination Domain Controller. The primary benefit of Citrix ADC SSL termination is that your LDAP clients can verify the Virtual Server SSL certificate.

Source IP – When Citrix ADC uses a local (same appliance) load balanced Virtual Server for LDAPS authentication, the traffic is sourced from the Citrix ADC SNIP (Subnet IP). When Citrix ADC uses a direct connection to a Domain Controller without going through a local Load Balancing Virtual Server, or if Citrix ADC uses a remote (different appliance) Load Balancing VIP, then the traffic is sourced from the Citrix ADC NSIP (NetScaler IP). Adjust firewall rules accordingly.

LDAPS Monitor

Note: Perl (scriptable) monitor uses NSIP as the source IP. You can use RNAT to override this as described in Configure to source Citrix ADC FreeBSD data traffic from a SNIP address at Citrix Docs.

12.0 build 56 and newer

Instructions for creating the monitor changed in 12.0 build 56 and newer. If your build is older, skip to the older instructions.

  1. In the Citrix ADC Configuration Utility, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name the monitor ldaps-Corp or similar. The ldaps monitor logs into Active Directory, performs an LDAP query, and looks for a successful response. The monitor configuration has domain-specific information, so if you have multiple Active Directory domains, then you will need a separate ldaps monitor for each domain. Include the domain name in the monitor name.
  4. In the Type field, click where it says Click to select.
  5. Scroll down and click the circle next to LDAP.
  6. At the top of the window, click the blue Select button.
  7. Scroll down the Basic  Parameters section, and check the box next to Secure. This checkbox instructs the monitor to connect to the Domain Controllers using LDAPS instead of LDAP.
  8. Scroll back up, and configure the following:
    • In the Base DN field, enter your domain name in LDAP format (e.g. dc=company,dc=com).
    • In the Bind DN field, enter the UPN login (e.g. ctxsvc@company.com) of a service account in the domain that can browse all objects. Any normal Domain User should be sufficient. Just make sure the password doesn’t expire.
    • In the Filter field, enter cn=builtin. This limits the search results so it’s not returning the entire domain.
    • In the Password field (higher in the list), enter the password for the service account. Make sure there is no semicolon in the password or the Perl script will be unable to parse the parameters.
  9. Scroll down and click Create.

    add lb monitor LDAP-Corp LDAP -scriptName nsldap.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -password Passw0rd -secure YES -baseDN "dc=corp,dc=local" -bindDN "corp\\ctxsvc" -filter cn=builtin
  10. If you have multiple domains, then create additional monitors: one for each domain.
  11. Jump to the Servers section.

12.0 older than build 56

  1. In the Citrix ADC Configuration Utility, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name the monitor ldaps-Corp or similar. The ldaps monitor logs into Active Directory, performs an LDAP query, and looks for a successful response. The monitor configuration has domain-specific information, so if you have multiple Active Directory domains, then you will need a separate ldaps monitor for each domain. Include the domain name in the monitor name.
  4. Change the Type drop-down to LDAP.
  5. Scroll down the Standard Parameters tab, and check the box next to Secure. This checkbox instructs the monitor to connect to the Domain Controllers using LDAPS instead of LDAP.
  6. Scroll back up, and switch to the Special Parameters tab.
  7. Configure the following on the Special Parameters tab:
    • Use the Script Name drop-down list to select the nsldap.pl file.
    • In the Base DN field, enter your domain name in LDAP format (e.g. dc=company,dc=com).
    • In the Bind DN field, enter the UPN login (e.g. ctxsvc@company.com) of a service account in the domain that can browse all objects. Any normal Domain User should be sufficient. Just make sure the password doesn’t expire.
    • In the Filter field, enter cn=builtin. This limits the search results so it’s not returning the entire domain.
    • In the Password field, enter the password for the service account. Make sure there is no semicolon in the password or the script will be unable to parse the parameters.
  8. Click Create.

    add lb monitor LDAP-Corp LDAP -scriptName nsldap.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -password Passw0rd -secure YES -baseDN "dc=corp,dc=local" -bindDN "corp\\ctxsvc" -filter cn=builtin
  9. If you have multiple domains, then create additional monitors: one for each domain.

Servers

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter the following in the Create Server section.
    • In the Name field, enter a descriptive server name. Usually it matches the actual server name.
    • In the IPAddress field, enter the IP address of the server. Note: you can alternatively change the selection to Domain Name and enter a FQDN. This requires the Citrix ADC the be able to resolve the FQDN.
    • Enter comments to describe the server.
  4. Click Create.

    add server AD01 10.2.2.11
add server AD02 10.2.2.12
  5. Continue adding Domain Controllers. You usually want at least two per domain.

Service Groups

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, click Add
    .
  3. In the Basic Settings section, do the following:
    • In the Name field: You will create one Service Group per datacenter. Enter a name reflecting the name of the data center. Also, you will create a set of service groups per Active Directory domain, so include the domain name.
    • Change the Protocol drop-down to SSL_TCP.
  4. Scroll down, and click OK to close the Basic Settings section.

  5. On the left, in the Service Group Members section, click where it says No Service Group Member.

    1. If you did not create server objects, then leave the selection set to IP Based, and enter the IP address of a Domain Controller in this datacenter.
    2. If you previously created server objects, then change the selection to Server Based, and select the server objects.
    3. In the Port field, enter 636 (LDAPS). This assumes the Domain Controllers have certificates installed.
    4. Click Create.
  6. Click OK to close the Service Group Members section.
  7. On the right, in the Advanced Settings column, click Monitors.
  8. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.

    1. In the Select Monitor field, click where it says Click to select.
    2. Click the circle next to the LDAPS monitor you created earlier. The monitor might be on Page 2.
      1. The circle must be clicked exactly (no room for error). If you click outside the circle, then the monitor will open for editing. If this happens, click Close to return to the selection screen.
    3. At the top of the window, click the blue Select button.
    4. Click Bind.
  9. To verify the members are up, click in the Service Group Members section.

    1. Right-click a member, and click Monitor Details.
    2. The Last Response field should say Success – Probe succeeded. Click Close. It’s too bad you can’t edit the monitor from here.

      • If the monitor doesn’t work, use ldp.exe to verify the Domain Controller certificate.
  10. Click Close and Done to finish creating the Service Group.

    add serviceGroup svcgrp-LDAP-Corp SSL_TCP
bind serviceGroup svcgrp-LDAP-Corp AD01 636
bind serviceGroup svcgrp-LDAP-Corp AD02 636
bind serviceGroup svcgrp-LDAP-Corp -monitorName LDAP-Corp
  11. Add additional service groups for Domain Controllers for each domain in each data center.

Load Balancing Virtual Server

  1. Create or import a certificate that matches the FQDN that resolves to the new Load Balancing VIP for LDAPS.
  2. On the left, expand Traffic Management, expand Load Balancing, and click Virtual Servers.
  3. On the right, click Add.
  4. In the Basic Settings section, do the following:
    • Name it LDAPS-Corp-HQ-LB or similar. You will create one Virtual Server per datacenter, so include the datacenter name. Also, each domain has a separate set of Virtual Servers, so include the domain name.
    • Change the Protocol drop-down to SSL_TCP.
    • Enter a Virtual IP. This VIP cannot conflict with any other IP + Port already being used. You can use an existing VIP that is not already listening on TCP 636.
    • Enter 636 as the Port.
  5. Click OK to close the Basic Settings section.
  6. On the left, in the Service Group section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.

    1. Click where it says Click to select.
    2. Click the circle next to a previously created Service Group. It might be on page 2.
      1. The circle must be clicked exactly (no room for error). If you click outside the circle, then the Service Group will open for editing. If this happens, click the x on the top right, or the Done button on the bottom, to return to the selection screen.
    3. At top of the screen, click the blue Select button.
    4. Click Bind.
  7. Click Continue to close the Services and Service Groups section.
  8. On the left, in the Certificates section, click where it says No Server Certificate.

    1. Click where it says Click to select.
    2. Click the circle next to a certificate that matches the FQDN that resolves to this VIP. It might be on page 2.
    3. At the top of the window, click the blue Select button.
    4. Click Bind.
  9. Click Continue to close the Certificates section.

    add lb vserver lbvip-LDAP-Corp SSL_TCP 10.2.2.210 636 -persistenceType NONE -cltTimeout 9000

bind lb vserver lbvip-LDAP-Corp svcgrp-LDAP-Corp
  10. There’s no need to configure Persistence for LDAP.
  11. If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, and bind an A+ Cipher Group.
  12. Click Done to finish creating the Virtual Server.
  13. The new Virtual Server should show as UP.

Backup Virtual Server

You can optionally configure this Load Balancing Virtual Server to failover to a different Load Balancing Virtual Server. This allows you to load balance Domain Controllers in this datacenter, and if down, failover to the other datacenter.

  1. Create additional Load Balancing Virtual Servers for each datacenter.
    • These additional Virtual Servers do not need a VIP, so change the IP Address Type to Non Addressable. Only the first Virtual Server will be directly accessible.

      add lb vserver lbvip-LDAP-Corp-Backup SSL_TCP 0.0.0.0 0
    • Notice that the additional datacenter Virtual Servers show up with an IP Address of 0.0.0.0 and port of 0.
  2. After you are done creating a Virtual Server for each datacenter, right-click the primary datacenter’s Virtual Server, and click Edit.
  3. On the right, in the Advanced Settings column, click Protection.
  4. On the left, in the Protection section, change the Backup Virtual Server to one of the other datacenter Virtual Servers. If all of the services in this datacenter are DOWN, the backup Virtual Server will be used instead. You can cascade multiple Virtual Servers using this method. Click OK and Done.

    set lb vserver lbvip-LDAP-Corp -backupVServer lbvip-LDAP-Corp-Backup

CLI Commands

Here is a list of CLI Commands for Domain Controller Load Balancing.

# SSL Global Parameters
# ---------------------
set ssl parameter -denySSLReneg NONSECURE

# Certs
# -----
add ssl certKey WildcardCorpCom -cert WildcardCorpCom.pfx -key WildcardCorpCom.pfx -inform PFX -passcrypt "Passw0rd"


# Load Balancing Global Parameters
# --------------------------------
enable ns mode FR L3 Edge USNIP PMTUD ULFD
set lb parameter -sessionsThreshold 150000
set ns param -cookieversion 1 -timezone "GMT-06:00-CST-America/Chicago"
set dns parameter -dns64Timeout 1000
set ns tcpParam -WS ENABLED -SACK ENABLED
set ns httpParam -dropInvalReqs ON
set ns tcpbufParam -memLimit 390

# Monitors
# --------
add lb monitor ldaps-Corp LDAP -scriptName nsldap.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -password Passw0rd -encrypted -encryptmethod ENCMTHD_3 -LRTM DISABLED -secure YES -baseDN "dc=corp,dc=local" -bindDN admin@corp.local -filter cn=builtin


# Servers
# -------
add server AD01 10.2.2.11

add server AD03 10.2.2.115


# Service Groups
# --------------
add serviceGroup svcgrp-LDAPS-Corp-HQ SSL_TCP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO
bind serviceGroup svcgrp-LDAPS-Corp-HQ AD01 636
bind serviceGroup svcgrp-LDAPS-Corp-HQ AD03 636
bind serviceGroup svcgrp-LDAPS-Corp-HQ -monitorName ldaps-Corp
set ssl serviceGroup svcgrp-LDAPS-Corp-HQ -sslProfile ns_default_ssl_profile_backend


# Load Balancing Virtual Servers
# ------------------------------
add lb vserver LDAPS-Corp-DR-LB SSL_TCP 0.0.0.0 0 -persistenceType NONE -cltTimeout 9000
bind lb vserver LDAPS-Corp-DR-LB svcgrp-LDAPS-Corp-HQ

add lb vserver LDAPS-Corp-HQ-LB SSL_TCP 10.2.5.220 636 -persistenceType NONE -cltTimeout 9000 -backupVServer LDAPS-Corp-DR-LB
bind lb vserver LDAPS-Corp-HQ-LB svcgrp-LDAPS-Corp-HQ


# SSL Virtual Servers
# -------------------
set ssl vserver LDAPS-Corp-DR-LB -sslProfile ns_default_ssl_profile_frontend
bind ssl vserver LDAPS-Corp-DR-LB -certkeyName WildcardCorpCom
bind ssl vserver LDAPS-Corp-DR-LB -eccCurveName P_256
bind ssl vserver LDAPS-Corp-DR-LB -eccCurveName P_384
bind ssl vserver LDAPS-Corp-DR-LB -eccCurveName P_224
bind ssl vserver LDAPS-Corp-DR-LB -eccCurveName P_521

set ssl vserver LDAPS-Corp-HQ-LB -sslProfile ns_default_ssl_profile_frontend
bind ssl vserver LDAPS-Corp-HQ-LB -certkeyName WildcardCorpCom
bind ssl vserver LDAPS-Corp-HQ-LB -eccCurveName P_256
bind ssl vserver LDAPS-Corp-HQ-LB -eccCurveName P_384
bind ssl vserver LDAPS-Corp-HQ-LB -eccCurveName P_224
bind ssl vserver LDAPS-Corp-HQ-LB -eccCurveName P_521

Next Steps

You may now use this Virtual IP in your Citrix Gateway LDAP authentication policies, or Citrix ADC management login.

ICA Proxy (StoreFront) – Citrix Gateway

Last Modified: Feb 27, 2025 @ 8:02 am

133 Comments

This article applies to Citrix Gateway 12.0 and newer. Citrix Gateway is the new name for NetScaler Gateway.

Navigation

💡 = Recently Updated

Change Log

Overview

Here’s a high-level overview of internal connectivity from client devices to Citrix Virtual Apps and Desktops (CVAD):

  1. HTTP connection to Citrix StoreFront:
    • Authentication to StoreFront
    • User interface that displays a list Citrix published icons
  2. ICA connection directly to a Citrix Virtual Delivery Agent (VDA)
    • ICA is a display protocol similar to RDP protocol

Citrix Gateway has an ICA Proxy feature that authenticates the user, proxies HTTP traffic to StoreFront, and then proxies ICA traffic to VDAs.

  • ICA Proxy is just one of the features that Citrix Gateway supports. Other Gateway features include: SSL VPN, Unified Gateway, RDP Proxy, PCoIP Proxy, etc.
  • ICA Proxy only exposes a single IP address to the user. All communication from all external Citrix clients to all internal StoreFront servers and all internal VDAs is proxied through the one IP address.
    • The “single IP address” feature is also sometimes useful internally, especially if there’s any Network Address Translation between internal subnets, or if the Citrix VDAs are protected behind an internal firewall.
  • Citrix Gateway supports many different authentication methods, including: LDAP, RADIUS, SAML, OpenID Connect, nFactor, Client Certificates (Smart Cards), etc.
    • Citrix Gateway has more authentication options than StoreFront. Sometimes Citrix Gateway is deployed in front of StoreFront just for the additional authentication options that Citrix Gateway provides.
  • Both HTTP and ICA are proxied through a single TLS-encrypted port 443. ICA Proxy decrypts the traffic and inspects it.
    • If the traffic is HTTP protocol, then ICA Proxy forwards it to Citrix StoreFront. The address of the StoreFront server is defined in a Session Policy/Profile on the Published Applications tab.
    • If the traffic is ICA protocol, then ICA Proxy uses a Secure Ticket Authority (STA) server to authenticate the connection, and then forwards the unencrypted ICA traffic to the VDA.
    • DTLS-encrypted (UDP) port 443 is also an option – UDP protocol for ICA traffic performs better than TCP on high latency links

There are two user interface options for connecting to Citrix Virtual Apps and Desktops (CVAD). Both user interface options rely on a connection to StoreFront. ICA Proxy is configured differently for each user interface.

  • Web Browser – Chrome, Safari, etc. connecting to the Receiver for Web website hosted on Citrix StoreFront.
  • Receiver Self-Service – native user interface built into Workspace app that connects to an XML-based API hosted on Citrix StoreFront.
    • In all operating systems, Receiver Self-Service is the user interface that opens when you launch Receiver or Workspace app from the app launcher.
    • In Windows, Receiver Self-Service is the user interface that you can open from the Receiver / Workspace app systray icon.
    • In Windows, Receiver Self-Service can download icons from StoreFront and put the icons on the client device’s app launcher (Start Menu and/or Desktop) without needing to actually open the Receiver Self-Service window.

Links:

Session Profiles

Partly based on Citrix Docs Integrate NetScaler Gateway with StoreFront.

To create Session Profiles/Policies for ICA Proxy (StoreFront):

  1. On the left, expand Citrix Gateway, expand Policies, and click Session.
  2. On the right, switch to the Session Profiles tab, and click Add.

    1. Name the first one Receiver Self Service or similar. This is for the Receiver Self-Service interface (not from a web browser).
    2. Switch to the Client Experience tab.
    3. On the Client Experience tab, check the Override Global box next to Clientless Access, and set it to Off. Scroll down.
    4. Check the Override Global box next to Plug-in Type, and set it to Java.
    5. Check the Override Global box next to Single Sign-on to Web Applications and enable it. Scroll up.

      • If you need two-factor authentication (RADIUS) using classic Authentication Policies (not nFactor, not AAA vServer), the Session Policy for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab is Credential Index. This needs to be changed to SECONDARY. Only change this in the Receiver Self-Service profile; leave the session profile for Web Browsers set to PRIMARY.
    6. Scroll up and switch to the Security tab.
    7. Check the Override Global box next to Default Authorization Action, and set it to Allow.
    8. Switch to the Published Applications tab.
    9. Check the Override Global box next to ICA Proxy, and set it to ON.
    10. Check the Override Global box next to Web Interface Address, and enter the load balanced URL (FQDN) to the StoreFront servers. You can use an IP address instead of FQDN. Don’t add any path to the end of the URL.
    11. If you only have one domain, then check the Override Global box next to Single Sign-on Domain, and enter the name of your Active Directory domain. Enter the same domain name that’s configured in StoreFront’s Configure Trusted Domains.

    12. For Account Services Address, enter the Base URL for StoreFront. Citrix Gateway needs to be able to resolve this FQDN’s DNS name.
    13. Click Create.
  3. Right-click the just-added session profile, and click Add. This copies the settings from the existing profile into the new one.

    1. Change the name of the second Session Profile to Receiver For Web or similar.
    2. Switch to the Client Experience tab.
    3. On the Client Experience tab, Clientless Access should be set to Off. Scroll down.
    4. Plug-in Type should still be set to Java.
    5. Single Sign-on to Web Applications should be enabled.

      • If you need two-factor authentication using Classic authentication policies (not nFactor, not AAA vServer), the session profile for Receiver for Web needs Credential Index set to PRIMARY. Only the Receiver Self-Service policy needs SECONDARY as detailed earlier.
    6. Scroll up and switch to the Security tab.
    7. The Default Authorization Action should still be Allow.
    8. Switch to the Published Applications tab.
    9. For the Web Interface Address field, add the path to your Receiver for Web site (e.g. /Citrix/StoreWeb).
    10. Everything else should be the same. If you only have one domain, then check the Override Global box next to Single Sign-on Domain and enter the name of your Active Directory domain. If you have multiple domains, then leave this field blank and ensure the LDAP authentication servers have userPrincipalName in the SSO Name Attribute field.
    11. Account Services Address is not needed in this profile but there’s no harm in leaving it.
    12. Click Create.
  4. On the right, switch to the Session Policies tab, and click Add.

    1. Name the Policy Receiver Self Service or similar.
    2. Change the Profile to Receiver Self Service.
    3. In the Expression box, type in the following expression: 
      HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver")
    4. Then click Create.
  5. Right-click on the just-added Session Policy, and click Add.

    1. Change the name to Receiver For Web or similar.
    2. Change the Profile to Receiver For Web.
    3. In the Expression box, either type in the following, or use the Expression Editor. It’s the same as the Receiver Self-Service expression, except it has .NOT on the end. 
      HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver").NOT
    4. Click Create.

The CLI commands for these Session Policies/Profiles are shown below:

add vpn sessionAction "Receiver Self-Service" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.corp.com" -ntDomain Corp.local -clientlessVpnMode OFF -storefronturl "https://storefront.corp.com"

add vpn sessionAction "Receiver for Web" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.corp.com/Citrix/StoreWeb" -ntDomain Corp.local -clientlessVpnMode OFF

add vpn sessionPolicy "Receiver Self-Service" "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\")" "Receiver Self-Service"

add vpn sessionPolicy "Receiver for Web" "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" "Receiver for Web"

Traffic Policy

In Citrix ADC 13.0 build 64.35, the SSO option in Session Policy/Profile no longer sends credentials to StoreFront. To work around this issue, add a Traffic Policy that enables SSO. See Enable SSO for Basic, Digest, and NTLM authentication at Citrix Docs. Citrix says that this won’t be necessary for StoreFront on newer builds of ADC 13.0.

  1. On the left, expand Citrix Gateway, expand Policies and click Traffic.
  2. On the right, switch to the tab named Traffic Profiles.
  3. Click Add.
  4. Name it something similar to StoreFrontSSO.
  5. Change the setting for Single Sign-on to ON. This is the only setting we need.
  6. At the bottom, click Create.
  7. On the right, switch to the tab named Traffic Policies.
  8. Click Add.
  9. Name it something similar to StoreFrontSSO.
  10. Select the Request Profile (aka Traffic Profile) you created earlier.
  11. In the Expression box, enter true. This assumes you are doing Advanced (Default) syntax policies.
  12. Click Create.

  13. See the next section to bind the Traffic Policy to the Gateway Virtual Server.

The CLI commands to create the Traffic Policy for StoreFront Single Sign-on are shown below:

add vpn trafficAction StoreFrontSSO http -SSO ON
add vpn trafficPolicy StoreFrontSSO true StoreFrontSSO
# or for full VPN:
add vpn trafficPolicy StoreFrontSSO "HTTP.REQ.METHOD.EQ(post) || HTTP.REQ.METHOD.EQ(get) && false" StoreFrontSSO

Citrix Gateway Virtual Server

This section assumes LDAP authentication, with optional RADIUS for two-factor. Create the Authentication Policies before beginning this section.

  • You can configure StoreFrontAuth as an alternative to LDAP. StoreFrontAuth delegates authentication to StoreFront servers, instead of performing authentication on Citrix Gateway.
  • For other forms of authentication, see the Authentication section in the Citrix ADC menu page.

To create the Citrix Gateway Virtual Server for ICA Proxy and StoreFront:

  1. At Traffic Management > SSL > Certificates > Server Certificates, Create a Server Certificate for the Citrix Gateway Virtual Server. The certificate must match the DNS name users will enter to access the Citrix Gateway.

    • For email discovery in Citrix Receiver / Workspace app, the certificate must have subject alternative names (SAN) for discoverReceiver.email.suffix (use your email suffix domain name). If you have multiple email domains then you’ll need a Subject Alternative Name for each suffix.
  2. Link the certificate to the Intermediate CA certificate. Do not link the Intermediate CA certificate to the Root CA certificate.
  3. On the left, right-click the Citrix Gateway node, and click Enable Feature.
  4. On the left, expand Citrix Gateway, and click Virtual Servers.
  5. On the right, click Add.
  6. Name it gateway.corp.com or similar.
  7. Enter a new VIP that will be exposed to the Internet (typically through NAT).
  8. Click More.

    1. If you don’t have enough Citrix Gateway Universal licenses installed for all of your Gateway users, then check the box next to ICA Only. This option disables SmartAccess and VPN features but does not require any additional licenses.  Note: most Citrix ADC Editions come with built-in Gateway Universal Licenses.
    2. Note: it’s also possible to disable authentication on Gateway and make StoreFront do it instead as described in Configure StoreFront Log On when authentication is disabled on Citrix Gateway VIP at Citrix Docs. However, it’s more secure to require Gateway to authenticate the users before the user can communicate with StoreFront.
    3. On the right, check the box next to DTLS.
      • DTLS enables EDT protocol, and UDP Audio.
      • EDT requires UDP 443 on client side, and UDP 1494/2598 on the server side.
      • VDAs support MTU Discovery for EDT traffic since UDP cannot be fragmented. ADC 13.1 build 17 and newer can enforce the Don’t Fragment bit when VDAs perform EDT MTU Discovery. See PMTUD discovery and DF bit propagation for EDT over Citrix Gateway at Citrix Docs for details. The setting can be enabled on the ADC at System > Settings > Change ICA Parameters.

    4. Click OK to close the Basic Settings section.
  9. In the Certificate section, click where it says No Server Certificate.

    1. In the Server Certificate Binding section, click where it says Click to select.
    2. Click the radio button next to a previously created certificate that matches the Citrix Gateway DNS name, and then click the blue Select button at the top of the window.
    3. Click Bind.
  10. Click Continue to close the Certificate section.
  11. In the Basic Authentication section, click the plus icon in the top right. Note: Citrix Gateway only seem to only support Basic Authentication policies, and not Advanced Authentication policies. For Advanced Authentication Policies, you’ll instead need to configure nFactor.

    1. Change the Choose Policy drop-down to LDAP,
    2. Leave the Choose Type drop-down set to  Primary, and click Continue.
    3. If you’ve already created an LDAP Policy, then click where it says Click to select, and select the policy.

    4. If you used the Authentication Dashboard to create an LDAP Server, then you probably haven’t created the corresponding LDAP Policy yet. Click the plus icon (Add button) to create a new policy.

      1. Use the Server drop-down to select the previously created LDAP Server.
      2. Give the policy a name. The Policy name can match the Server name.
      3. In the Expression box, enter ns_true (a Basic or Classic expression), or select it from the Saved Policy Expressions drop-down. Click Create.
    5. Click Bind.
    6. Or for two-factor authentication, bind two Basic authentication policies to Primary and two Basic authentication polices to Secondary. Note: if you instead do nFactor authentication, then you don’t need to swap the fields for Workspace app.
      • Primary = LDAP for Browsers (User-Agent does not contain CitrixReceiver)
      • Primary = RADIUS for Receiver Self-Service (User-Agent contains CitrixReceiver)
      • Secondary = RADIUS for Browsers (User-Agent does not contain CitrixReceiver)
      • Secondary = LDAP for Receiver Self-Service (User-Agent contains CitrixReceiver)
  12. Click Continue to close the Basic Authentication section.
  13. In the Advanced Authentication section, click Continue.
  14. Scroll down to the Profiles section, and click the pencil icon.
  15. In the TCP Profile drop-down, do one of the following:
    1. Follow the instructions at Citrix CTX232321 Recommended TCP Profile Settings for Full Tunnel VPN/ICAProxy from NetScaler Gateway 11.1 Onwards. In this case, there’s no need to change the TCP Profile.
    2. Or, select nstcp_default_XA_XD_profile, and click OK to close the Profiles section.
  16. To bind the Session Policies, scroll down to the Policies section, and click the plus icon near the top right.

    1. Select Session, select Request, and click Continue.
    2. Click where it says Click to select.
    3. Click the radio button next to one of the Receiver Session Policies, and click the blue Select at the top of the window. It doesn’t matter in which order you bind them.
    4. There’s no need to change the priority number. Click Bind.
  17. Repeat these steps to bind the second policy. In the Policies section, click the plus icon near the top right.

    1. Select Session, select Request, and click Continue.
    2. Click Add Binding.
    3. Click where it says Click to select.
    4. Click the radio button next to the other Receiver session policy, and click Select.
    5. There’s no need to change the priority number. Click Bind.
    6. The two policies are mutually exclusive so there’s no need to adjust priority. Click Close.
  18. In ADC 13.0 build 64.35, bind a Traffic Policy that enables Single Sign-on. Citrix says that this won’t be necessary on newer builds of ADC 13.0.
    1. Click the plus icon near the top right.
    2. Select Traffic, select Request, and click Continue.
    3. Click where it says Click to select.
    4. Click the radio button next to the Traffic Policy you created earlier and click Select at the top of the window.
    5. There’s no need to change the priority number. Click Bind.
  19. To bind Secure Ticket Authorities (STAs), on the right, in the Advanced Settings section, click Published Applications.
  20. On the left, in the Published Applications section, click where it says No STA Server.

    1. Enter a Delivery Controller in the https://<Controller_FQDN> or http://<Controller_FQDN> format, depending on if SSL is enabled on the Delivery Controller or not. This must be a FQDN or IP address. Short names don’t work.
    2. Click Bind.
  21. To bind another Secure Ticket Authority server, on the left, in the Published Applications section, click where it says 1 STA Server.

    1. In the VPN Virtual Server STA Server Binding section, click Add Binding.
    2. Enter the URL for the second Controller, and click Bind.
    3. This view shows if the STAs are reachable or not. To refresh the view, close the STA Server Bindings list, and reopen it.
    4. The list of Citrix Gateway Virtual Servers also shows you if the STAs (STA Status) are up or not.
    5. By default, STA server reachability is only checked every 2 minutes. You can change this at Traffic Management > Load Balancing > Monitors, and edit the sta and stasecure built-in monitors (source = CTX231916 NetScaler Takes 3-4 Minutes to Mark STA as DOWN)

  22. On the right, in the Advanced Settings column, click Portal Themes.
  23. On the left, in the Portal Theme section, change the drop-down to WStheme or RfWebUI. You can also click the plus icon to create a theme. Note: WStheme is available in NetScaler 14.1 build 43.50 and newer.
  24. Click OK to close the Portal Theme section.
  25. If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind an A+ Cipher Group, and enable Strict Transport Security.
  26. Click Done when done.
  27. Configure SSL Redirect for the Citrix Gateway DNS name and VIP.
  28. Configure StoreFront to use Citrix Gateway.

The CLI commands to create a Citrix Gateway vServer for ICA Proxy are shown below:

add vpn vserver gateway.corp.com SSL 10.2.2.200 443 -icaOnly ON -dtls ON -tcpProfileName nstcp_default_XA_XD_profile
bind vpn vserver gateway.corp.com -policy "Receiver Self-Service" -priority 100
bind vpn vserver gateway.corp.com -policy "Receiver for Web" -priority 110
bind vpn vserver gateway.corp.com -policy StoreFrontSSO -priority 100
bind vpn vserver gateway.corp.com -policy Corp-Gateway -priority 100
bind vpn vserver gateway.corp.com -staServer "http://xdc01.corp.local"
bind vpn vserver gateway.corp.com -staServer "http://xdc02.corp.local"
bind vpn vserver gateway.corp.com -portaltheme RfWebUI
set aaa parameter -wafProtection AUTH VPN -securityInsights ENABLED

Verify SSL Settings

After you’ve created the Citrix Gateway Virtual Server, run the following tests to verify SSL:

  1. Go to https://www.ssllabs.com/ssltest/ and check the security settings of the website. Citrix Blogs – Scoring an A+ at SSLlabs.com with Citrix NetScaler – Q2 2018 update.
  2. Citrix CTX200890 – Error: “Failed with status 1110” When Launching Desktops or Apps Through NetScaler Gateway: You can use OpenSSL to verify the certificate. Run the command: openssl s_client -connect gateway.corp.com:443. Replace the FQDN with your FQDN. OpenSSL is installed on the Citrix ADC, or you can download and install it on any machine.

WAF for Citrix Gateway

In NetScaler 14.1 build 21 and newer, you can enable Web App Firewall (WAF) on NetScaler Gateway. This feature is available in all editions of NetScaler.

  1. In the left menu, expand NetScaler Gateway and click Global Settings.
  2. On the right, in the right column, click Change authentication AAA settings.
  3. For WAF Protection, change it to Custom and select AUTH and VPN. This enables the built-in WAF profiles globally.
  4. Change the Security Insights drop-down to ENABLED.

    set aaa parameter -wafProtection AUTH VPN -securityInsights ENABLED
  5. Scroll down and click OK.
  6. In NetScaler Console build 21 and newer, you can enable WAF Security Violations when enabling or editing Analytics on the Virtual Server.

  7. If you have NetScaler Premium Edition, then you can go to Security > NetScaler Web App Firewall > Profiles to see the WAF configuration.

    1. There are four built-in WAF profiles with names starting with ns-.
    2. If you edit one and click Security Checks, notice that only REST API Schema Validation is enabled. You can optionally enable the other security checks, but you will need a process to train/learn the config and correct issues. NetScaler Docs details some modifications you can make to the WAF profiles.

View ICA Connections

To view active ICA proxy sessions, click the Citrix Gateway node on the left, and then click ICA Connections on the right.

show vpn icaconnection

To view historical ICA sessions, search your Syslog server for ICASTART and/or LOGIN.

Or, if you don’t have Syslog server configured, then search /var/log/ns.log on the local appliance. Source = CTX232581 How to View Active Users Sessions Connected to Specific NetScaler Gateway vServers.

Logoff is Successful

With newer versions of StoreFront and Citrix Gateway, when you logoff StoreFront 3.15+ that is proxied through Citrix Gateway, all you see is a white page with the text “Logoff is successful”.

Alternatively, you can redirect to the Gateway logon page by creating and binding a Responder policy: (source = Storefront 3.15 “Logoff Is Successful” at Reddit)

  1. In the menu, go to AppExpert > Responder > Actions.
  2. Enable the Responder feature if it isn’t already enabled.
  3. On the right, click Add.
  4. In the Create Responder Action window:
    1. Give the Responder Action a name. The purpose of this Responder is to redirect to the Gateway logon page after StoreFront is logged off.
    2. Change the Type drop-down to Redirect. Note: it’s easy to miss this step.
    3. In the Expression box, you can enter "https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE or you can enter the actual https:// URL to the Gateway Virtual Server. The first option uses the Gateway FQDN originally entered by the user.
  5. Click Create.
  6. On the left, in the menu, click the Policies node under Responder.
  7. On the right, click Add.
  8. In the Create Responder Policy window:
    1. Give the Responder Policy a name.
    2. Change the Action drop-down to the name of the Responder Action you just created.
    3. If and higher, in the Expression box enter HTTP.REQ.URL.CONTAINS("/vpn/logout") || HTTP.REQ.URL.CONTAINS("/cgi/logout"). ADC 13.0 build 13.0 76.x  changed the URL from /cgi/logout to /vpn/logout.
  9. Click Create.
  10. In the menu, go to Citrix Gateway > Virtual Servers.
  11. Edit your Citrix Gateway Virtual Server.
  12. Scroll down to the Policies section and click the plus icon.
  13. Change the Choose Policy drop-down to Responder and click Continue.
  14. In the Policy Binding section, click where it says Click to select.
  15. Click the radio button (circle) next to the Responder Policy you just created and then click the blue Select button at the top of the page.
  16. Click Bind.

Related Pages

EUC Weekly Digest – August 19, 2017

Last Modified: Nov 7, 2020 @ 6:34 am

Leave a comment

Here are some EUC items I found interesting last week. For more immediate updates, follow me at http://twitter.com/cstalhood.

 

For a list of updates at carlstalhood.com, see the Detailed Change Log.

XenApp/XenDesktop

VDA

App Layering (Unidesk)

Receiver

NetScaler

XenMobile

XenServer