Quantcast
Channel: ADC / NetScaler – Carl Stalhood
Viewing all 69 articles
Browse latest View live
↧

NetScaler 12 System Configuration

August 3, 2017, 5:48 pm
$
0
0

Navigation

💡 = Recently Updated

VPX Hardware

VMware Compatibility:

  • NetScaler VPX 12 is not supported on ESXi 5.5.
  • NetScaler VPX 12 is the first version to support ESXi 6.5.

NetScaler VPX supports changing the NIC type to VMXNET3 or SR-IOV. The imported appliance comes with E1000 NICs, so you’ll have to remove all of the existing virtual NICs, and add new VMXNET3 NICs.

Auto-Provision IP Address

When importing VPX into a hypervisor, you can use VM advanced configuration parameters to set the NSIP. See CTX128250 How to Auto-Provision NetScaler VPX Appliance on a VMware ESX or ESXi Host, and CTX128236 How To Auto-Provision NetScaler VPX on XenServer.

Power On VPX and configure NSIP

  1. After swapping out the NICs to VMXNET3, power on the NetScaler VPX appliance.
  2. Configure the management IP from the VM’s console.
  3. Then point your browser to the management IP using either http or https and login as nsroot with password nsroot.

Customer User Experience Improvement Program

  1. You might be prompted to enable the Customer User Experience Improvement Program. Either click Enable, or click Skip.

  2. You can also enable or disable the Customer Experience Improvement Program by going to System > Settings.
  3. On the right is Change CUXIP Settings.
  4. Make your selection and click OK.
  5. See http://www.carlstalhood.com/delivery-controller-7-13-and-licensing/#ceip for additional places where CEIP is enabled.
set system parameter -doppler ENABLED

Welcome Wizard

NetScaler has a Welcome! Wizard that lets you set the NSIP, hostname, DNS, licensing, etc. It appears automatically the first time you login.

  1. Click the Subnet IP Address box.
  2. You can either enter a SNIP for one of your production interfaces, or you can click Do it later and add SNIPs later after you configure Port Channels and VLANs. Note: If you have a dedicated management network, to prevent it from being used for outgoing traffic, don’t put a SNIP on it.
    add ns ip 10.2.2.60 255.255.255.0 -type SNIP
  3. Click the Host Name, DNS IP Address, and Time Zone box.
  4. Enter a hostname. In a High Availability pair each node can have a different hostname. You typically create a DNS record that resolves the hostname to the NSIP (management IP).
  5. Enter one or more DNS Server IP addresses. Use the plus icon on the right to add more servers.
  6. Change the time zone to GMT-06:00-CST-America/Chicago or similar.
  7. Click Done.
    set ns hostname ns02

add dns nameServer 10.2.2.11

set ns param -timezone "GMT-05:00-CDT-America/Chicago"
  8. Click Yes to save and reboot.
  9. Click the Licenses box.
  10. You can click Add New License to license the appliance now.
  11. On the far right side of the screen, you’ll see the Host ID. You’ll need this to allocate your licenses at citrix.com. See below for detailed instructions on how to allocate the license to this Host ID.
  12. On the left, select Upload license files, and click Browse.
  13. Browse to the license file, open it, and click Reboot when prompted.
  14. After the reboot and logging in, a box will pop up showing you the installed license.
  15. Also look in the top left corner to make sure it doesn’t say NetScaler VPX (1). The number in the parentheses should match the MPX or VPX model number.
    License files are stored in /nsconfig/license.

Licensing – VPX Mac Address

To license a NetScaler VPX appliance, you will need its MAC address.

  1. Go to the Configuration tab.
  2. In the right pane, look down for the Host Id field. This is the MAC address you need for license allocation.
  3. Another option is to SSH to the appliance and run shell.
  4. Then run lmutil lmhostid. The MAC address is returned.

Licensing – Citrix.com

  1. Login to http://mycitrix.com.
  2. On the left, click All Licensing Tools.
  3. On the top right, in the horizontal menu, click Activate and Allocate Licenses.
  4. If you are activating an eval license, click Don’t see your product near the top, and enter the eval license key.

  5. Otherwise, check the box next to a Citrix NetScaler VPX or MPX license, and click Continue.
  6. If this is a NetScaler MPX license then there is no need to enter a host ID for this license. so just click Continue.
  7. If this is a NetScaler VPX license, enter the VPX MAC address into the Host ID field. It’s not obvious, but you can enter text in this drop-down field.
  8. If you have more than one VPX license, change the Quantity field to 1, and then click Continue.
    1. For a VPX appliance, you can get the Host ID by looking at the System Information page. Click the System node to see this page.
  9. Click Confirm.
  10. Click OK when asked to download the license file.
  11. Click Download.
  12. Click Save and put it somewhere where you can get to it later.
  13. For NetScaler Standard Edition or higher, at least 500 NetScaler Gateway Universal Licenses are already included in your NetScaler platform license. NetScaler Standard comes with 500 Gateway Universal, NetScaler Enterprise comes with 1,000 Gateway Universal, and NetScaler Platinum comes with unlimited Gateway Universal.
    1. Note: NetScaler Gateway Enterprise Edition VPX does not come with any Gateway Universal Licenses.
  14. If you need more Gateway Universal licenses on your NetScaler, you can allocate them now. These licenses can come from XenMobile Enterprise, XenApp/XenDesktop Platinum Edition, NetScaler Platinum Edition, or a la carte.
  15. Enter your appliance hostname as the Host ID for all licenses. If you have two appliances in a HA pair, allocate these licenses to the first appliance hostname, then reallocate them to the second appliance hostname.
  16. Click Confirm.
  17. Click OK when prompted to download your license file.
  18. Click Download.
  19. Click Save.
  20. If you have two appliances in a High Availability pair with different hostnames then you will need to return the NetScaler Gateway Universal licenses, and reallocate them to the other hostname. The top right horizontal menu bar has a Reallocate option.

Install Licenses on Appliance

If you haven’t already installed licenses on your appliance, then do the following:

  1. In the NetScaler Configuration GUI, on the left, expand System, and click Licenses.
  2. On the top right, click Manage Licenses.
  3. Click Add New License.
  4. If you have a license file, select Upload license files, and then click Browse. Select the license file, and click Open.
    License files are stored in /nsconfig/license.
  5. Click Reboot when prompted. Login after the reboot.
  6. After rebooting, the Licenses node should look something like this.
  7. Notice that Maximum ICA Users Allowed is set to Unlimited.
  8. Maximum NetScaler Gateway Users Allowed will vary depending on your NetScaler Edition.
  9. Note: the NetScaler SNMP counter allnic_tot_rx_mbits must remain less than the licensed bandwidth or packets will drop.

VPX 100% CPU

NetScaler 12 packet engine consumes 100% of the hypervisor CPU. VPX 200 and lower only have one packet engine, so it’s probably consuming around 50% CPU.

You can change this behavior by doing the following:

  1. On the left, go to System > Settings.
  2. On the right, in the bottom of the second column, click Change VPX Configuration Settings.
  3. Change the CPU Yield drop-down to YES, and click OK.
  4. After making this change, you can see an immediate drop-off in CPU consumption.

Upgrade Firmware

Citrix CTX220371 Must Read Articles Before and After Upgrading NetScaler

Citrix CTX127455 How to Upgrade Software of the NetScaler Appliances in a High Availability Setup

  1. Download firmware. Ask your Citrix Partner or Citrix Support TRM for recommended versions and builds.
    1. At the very least, watch the Security Bulletins to determine which versions and builds resolve security issues. You can subscribe to the Security Bulletins at http://support.citrix.com by clicking the Alerts (bell) link on the top right after logging in.
  2. Make sure you Save the config before beginning the upgrade.
  3. Transferring the firmware upgrade file to the appliance will be slow unless you license the appliance first. An unlicensed appliance will reduce the maximum speed to 1 Mbps.
  4. When upgrading from 10.5 or older, make sure the NetScaler Gateway Theme is set to Default or Green Bubbles. After the upgrade, you’ll have to create a new Portal Theme and bind it to the Gateway vServers.
  5. Start with the Secondary appliance.
  6. Before upgrading the appliance, consider using WinSCP or similar to back up the /flash/nsconfig directory.
  7. In the NetScaler GUI, with the top left node (System) selected, on the right, click System Upgrade.
  8. Click Choose File, and browse to the build…tgz file. If you haven’t downloaded firmware yet, then you can click the Download Firmware link.
  9. Click Upgrade.
  10. The firmware will upload.
  11. You should eventually see a System Upgrade window with text in it. Click Close when you see the line indicating that a reboot is required.
  12. Go back to the System node. On the right, click the Reboot button.
  13. Click OK to reboot.
  14. Once the Secondary is done, login and failover the pair.
  15. Then upgrade the firmware on the former Primary.

To install firmware by using the command-line interface

  1. To upload the software to the NetScaler Gateway, use a secure FTP client (e.g. WinSCP) to connect to the appliance.
  2. Create a version directory under /var/nsinstall (e.g. /var/nsinstall/12.0.51.24).
  3. Copy the software from your computer to the /var/nsinstall/<version> (e.g. /var/nsinstall/12.0.51.24) directory on the appliance.
  4. Open a Secure Shell (SSH) client (e.g. Putty) to open an SSH connection to the appliance.
  5. At a command prompt, type shell.
  6. At a command prompt, type cd /var/nsinstall/<version> to change to the nsinstall directory.
  7. To view the contents of the directory, type ls.
  8. To unpack the software, type tar -xvzf build_X_XX.tgz, where build_X_XX.tgz is the name of the build to which you want to upgrade.
  9. To start the installation, at a command prompt, type ./installns.
  10. When the installation is complete, restart NetScaler.
  11. When the NetScaler restarts, at a command prompt type what or show version to verify successful installation.

High Availability

Configure High Availability as soon as possible so almost all configurations are synchronized across the two appliances. The synchronization exceptions are mainly network interface configurations (e.g. LACP).

High Availability will also sync files between the two appliances. See CTX138748 File Synchronization in NetScaler High Availability Setup for more information.

  1. Prepare the secondary appliance:
    1. Configure a NSIP.
    2. Don’t configure a SNIP. In Step 2, Subnet IP Address, you can click Do It Later to skip the wizard. You’ll get the SNIP later when you pair it.
    3. Configure Hostname and Time Zone.
    4. Don’t configure DNS since you’ll get those addresses when you pair it.

    5. License the secondary appliance.
    6. Upgrade firmware on the secondary appliance. The firmware of both nodes must be identical.
  2. On the secondary appliance, go to System > High Availability.
    1. On the right, double-click the local node.
    2. Change High Availability Status to STAY SECONDARY. If you don’t do this then you run the risk of losing your config when you pair the appliances.
      set ha node -hastatus STAYSECONDARY
  3. On the primary appliance, on the left, expand System, expand Network, and click Interfaces.
    1. On the right, look for any interface that is currently DOWN.
    2. You need to disable those disconnected interfaces before enabling High Availability. Right-click the disconnected interface, and click Disable. Repeat for the remaining disconnected interfaces.
      show interface
disable interface 1/1
  4. On the left, expand System, and click High Availability.
  5. On the right, double-click node 0 to edit it.
    1. Change the High Availability Status to STAY PRIMARY, and click OK.
  6. On the right, click Add.
    1. Enter the other NetScaler’s IP address.
    2. Enter the other NetScaler’s login credentials, and click Create.
      add ha node 1 192.168.123.14
      Note: this CLI command must be run separately on each appliance.
  7. If you click the refresh icon near the top right, Synchronization State will probably say IN PROGRESS.
    1. Eventually it will say SUCCESS.
  8. To enable Fail-safe mode, edit Node ID 0 (the local appliance).
    1. Change High Availability State back to ENABLED.
    2. Under Fail-safe Mode, check the box next to Maintain one primary node even when both nodes are unhealthy. Scroll down, and click OK.
      set ha node -failSafe ON
  9. If you login to the Secondary appliance, you might see a message warning you against making changes. Always apply changes to the Primary appliance.
  10. On the secondary appliance, go to System > High Availability, edit the local node, and change it from STAY SECONDARY to ENABLED.

  11. Go to System > Network > Routes, and make sure you don’t have two 0.0.0.0 routes. Joining an appliance to an HA pair cause the default route on the primary appliance to sync to the secondary appliance. But, it doesn’t delete the default gateway that was formerly configured on the secondary appliance.
  12. From the NetScaler CLI (SSH), run “sh ha node” to see the status. You should see heartbeats on all interfaces. If not, configure VLANs as detailed later..
  13. You can also disable HA heartbeats on specific network interfaces (System > Network > Interfaces).
    1. Note: Make sure HA heartbeats are enabled on at least one interface/channel.
    2. Note: this is an interface configuration, so this configuration change is not propagated to the other node.
  14. You can force failover of the primary appliance by going to System > High Availability, opening the Actions menu, and clicking Force Failover.
    force ha failover
  15. If your firewall (e.g. Cisco ASA) doesn’t like Gratuitous ARP, see CTX112701 – The Firewall Does not Update the Address Resolution Protocol Table

Port Channels on Physical NetScaler MPX

If you are configuring a NetScaler MPX (physical appliance), and if you plugged in multiple cables, and if more than one of those cables is configured on the switch for the same VLAN(s), then you must bond the interfaces together by configuring a Port Channel.

  • On the switch, create a Port Channel, preferably with LACP enabled.
  • The Port Channel can be an Access Port (one VLAN), or a Trunk Port (multiple VLANs).
  • On the NetScaler, configure LACP on the network interfaces, or create a Channel manually. Both are detailed below.

Also see Webinar: Troubleshooting Common Network Related Issues with NetScaler.

LACP Port Channel

To configure Port Channels on a NetScaler, you can either enable LACP, or you can configure a Channel manually. If your switch is configured for LACP, do the following on NetScaler to enable LACP on the member interfaces.

  1. Go to System > Network > Interfaces.
  2. On the right, edit one of the Port Channel member interfaces.
  3. Scroll down.
  4. Check the box next to Enable LACP.
  5. In the LACP Key field, enter a number. The number you enter here becomes the channel number. For example, if you enter 1, NetScaler creates a Channel named LA/1. All member interfaces of the same Port Channel must have the same LACP Key. Click OK when done.
  6. Continue enabling LACP on member interfaces and specifying the key (channel number). If you are connected to two port channels, one set of member interfaces should have LACP Key 1, while the other set of member interfaces should have LACP Key 2.
  7. Note: in an HA pair, you must perform this interface configuration on both nodes. The LACP commands are not propagated across the HA pair.
  8. If you go to System > Network > Channels.
  9. You’ll see the LACP Channels on the right. These were created automatically.
  10. If you edit a Channel, there’s a LACP Details tab that shows you the member interfaces.

Manual Channel

If your switch is not configured for LACP, then you can instead create a Channel manually.

  1. Go to System > Network > Channels.
  2. On the right, click Add.
  3. At the top, choose an unused Channel ID (e.g. LA/1).
  4. On the bottom, click Add.
  5. Click the plus icon next to each member interface to move it to the right. Then click Create.

Redundant Interface Set

You can also configure the NetScaler for switch-independent teaming. Create a Channel manually, but select a Channel ID starts with LR instead of LA. This is called Link Redundancy or Redundant Interface Set.

Channel Minimum Throughput

Channels can be configured so that a High Availability failover occurs when the Channel throughput drops below a configured value. For example, if you have four members in a Channel, you might want a High Availability failover to occur when two of the member interfaces fail.

  1. Go to System > Network > Channels, and edit a Channel.
  2. Near the top, enter a minimum threshold value in the Throughput field. If the total bonded throughput drops below this level, a High Availability failover will occur.

Trunk Port and High Availability

If you are trunking multiple VLANs across the channel, and if every VLAN is tagged (no native VLAN), then a special configuration is needed to allow High Availability heartbeats across the channel.

  1. Go to System > Network > VLAN.
  2. Add VLAN objects, and bind to the channel (e.g. LA/1).
  3. To bind multiple VLANs to a single interface/channel, the VLANs must be tagged.
  4. Configure one of the VLANs as untagged. Only untag one of them. Which one you untag doesn’t matter, except that the same VLAN should be untagged on the other HA node. If your switch doesn’t allow untagged packets, don’t worry, we’ll fix that soon.
  5. If your switch doesn’t allow untagged packets, go to System > Network > Channels, and edit the channel.
  6. Scroll down. On the Settings tab, set Tag all VLANs to ON. This causes NetScaler to tag all packets, including the VLAN you formerly marked as untagged. This special configuration is necessary to also tag High Availability heartbeat packets.
  7. Note: in an HA pair, you must perform this Tagall configuration on both nodes. The Tagall command is not propagated across the HA pair.

Common physical interface configuration

Here is a common NetScaler networking configuration for a physical NetScaler MPX that is connected to both internal and DMZ.

Note: If the appliance is connected to both DMZ and internal, then be aware that this configuration essentially bypasses (straddles) the DMZ-to-internal firewall. That’s because if a user connects to a public/DMZ VIP, then NetScaler could use an internal SNIP to connect to the internal server: in other words, traffic comes into a DMZ VLAN, but goes out an internal VLAN. A more secure approach is to have different appliances for internal and DMZ. Or use NetScaler SDX, partitioning, or traffic domains.

  • 0/1 connected to a dedicated management network. NSIP is on this network.
    • 0/1 is not optimized for high throughput so don’t put data traffic on this interface. If you don’t have a dedicated management network, then put your NSIP on one of the other interfaces (1/1, 10/1, LA/1, etc.) and don’t connect any cables to 0/1.
    • To prevent NetScaler from using this dedicated management interface for outbound data traffic, don’t put a SNIP on this management network, and configure the default gateway (route 0.0.0.0) to use a router on a different data network (typically the DMZ VLAN). However, if there’s no SNIP on this VLAN, and if the default gateway is on a different network, then there will be asymmetric routing for management traffic, since inbound management traffic goes in 0/1, but reply traffic goes out LA/1 or LA/2. To work around this problem, enable Mac Based Forwarding, or configure Policy Based Routing. Both of these options are detailed in the next section.
    • It’s easiest if the switch port for this dedicated management interface is an Access Port (untagged). If VLAN tagging is required, then NSVLAN must be configured on the NetScaler.
  • 10/1 and 10/2 in a LACP port channel (LA/1) connected to internal VLAN(s). Static routes to internal networks through a router on one of these internal VLANs.
    • If only one internal VLAN, configure the switch ports/channel as an Access Port.
    • If multiple internal VLANs, configure the switch ports/channel as a Trunk Port. Set one of the VLANs as the channel’s Native VLAN so it doesn’t have to be tagged.
    • If the networking team is unwilling to configure a Native VLAN on the Trunk Port, then NetScaler needs special configuration (tagall) to ensure HA heartbeat packets are tagged.
  • 1/1 and 1/2 in a LACP port channel (LA/2) connected to DMZ VLAN(s). The default gateway (route 0.0.0.0) points to a router on a DMZ VLAN so replies can be sent to Internet clients.
    • If only one DMZ VLAN, configure the switch ports/channel as an Access Port.
    • If multiple DMZ VLANs, configure the switch ports/channel as a Trunk Port. Set one of the VLANs as the channel’s Native VLAN so it doesn’t have to be tagged.
    • If the networking team is unwilling to configure a Native VLAN on the Trunk Port, then NetScaler needs special configuration (tagall) to ensure HA heartbeat packets are tagged.

Dedicated Management Subnet

Dedicated Management Subnet implies that your NetScaler is connected to multiple VLANs. If you have a subnet that is for NSIP only, and don’t want to use the SNIP subnet for data traffic, then you’ll want to move the default route to a different subnet, which breaks the NSIP. To work around this problem, create a PBR for the NSIP to handle replies from NSIP, and to handle traffic sourced by the NSIP.

  1. Go to System > Network > PBRs.
  2. On the right, click Add.
  3. Give the PBR a name (e.g. NSIP)
  4. Set the Next Hop Type drop-down to New.
  5. In the Next Hop field, enter the router IP address that is on the same network as the NSIP.
  6. In the Configure IP section, set the first Operation drop-down to =.
  7. In the Source IP Low field, enter the NSIP. This causes the PBR to match all traffic with NSIP as the Source IP address.
  8. You don’t need anything else.
  9. Scroll down, and click Create.
  10. To handle DNS traffic sourced by the NSIP, create another PBR by right-clicking the existing one, and clicking Add.
  11. Change the name to NSIP-DNS or similar.
  12. Change the Action drop-down to DENY. This prevents the PBR from overriding normal DNS behavior.
  13. Change the Priority to a lower number than the original PBR. Scroll down.
  14. In the Configure Protocol section, click the Protocol drop-down, and select UDP (17).
  15. In the Destination section, change the Operation to =.
  16. In the Destination port Low field, enter 53.
  17. Scroll down, and click Create.
  18. Make sure the DENY PBR is higher in the list (lower priority number) than the ALLOW PBR.
  19. Then open the Action menu, and click Apply.
    add ns pbr NSIP-DNS DENY -srcIP = 10.2.2.126 -destPort = 53 -nextHop 10.2.2.1 -protocol UDP -priority 5
add ns pbr NSIP ALLOW -srcIP = 10.2.2.59 -nextHop 10.2.2.1
apply ns pbrs

Multiple Subnets / Multiple VLANs

Citrix CTX214033 Networking and VLAN Best Practices for NetScaler discusses many of the same topics detailed in this section.

If this is a physical MPX appliance, see the previous Port Channel section first.

If you only connected NetScaler to one subnet (one VLAN) then skip ahead to DNS servers.

Configuration Overview

The general configuration process for multiple subnets is this:

  1. Create a SNIP for each subnet/VLAN.
  2. Create a VLAN object for each subnet/VLAN.
    1. Bind the VLAN object to the SNIP for the subnet.
    2. Bind the VLAN object to the Port Channel or single interface that is configured for the VLAN/subnet.

SNIPs for each VLAN

You will need one SNIP for each connected subnet/VLAN. VLAN objects (tagged or untagged) bind the SNIPs to particular interfaces. NetScaler uses the SNIP’s subnet mask to assign IP addresses to particular interfaces.

NSIP Subnet

The NSIP subnet is special, so you won’t be able to bind it to a VLAN. Use the following SNIP/VLAN method for any network that does not have the NSIP. The remaining interfaces will be in VLAN 1, which is the VLAN that the NSIP is in. VLAN 1 is only locally significant so it doesn’t matter if the switch is configured with it or not. Just make sure the switch has a native VLAN configured, or configure the interface as an access port. If you require trunking of every VLAN, including the NSIP VLAN, then additional configuration is required (NSVLAN or Tagall).

Configure Subnets/VLANs

To configure NetScaler with multiple connected subnets:

  1. Add a subnet IP for every network the NetScaler is connected to, except the dedicated management network. Expand System, expand Network, and click IPs.
  2. On the right, click Add.
    1. Enter the Subnet IP Address for this network/subnet. The SNIP will be the source IP address the NetScaler will use when communicating with any other service/server on this network. The Subnet IP is also known as the Interface IP for the network. You will need a separate SNIP for each connected network (VLAN).
    2. Enter the netmask for this network.
    3. Ensure the IP Type is set to Subnet IP. Scroll down.
      add ns ip 172.16.1.11 255.255.255.0 -type SNIP
    4. Under Application Access Controls, decide if you want to enable GUI management on this SNIP. This feature can be particularly useful for High Availability pairs, because when you point your browser to the SNIP, only the primary appliance will respond. However, enabling management access on the SNIP can be a security risk, especially if this is a SNIP for a DMZ network.
    5. Click Create when done. Continue adding SNIPs for each connected network (VLAN).
      set ns ip 172.16.1.11 -mgmtAccess ENABLED -telnet DISABLED -ftp DISABLED
  3. On the left, expand System, expand Network, and click VLANs.
  4. On the right, click Add.
    1. Enter a descriptive VLAN ID. The actual VLAN ID only matters if you intend to tag the traffic. If not tagged, then any ID (except 1) will work.
    2. Check the box next to one physical interface or channel (e.g. LA/1) that is connected to the network.
    3. If this is a trunk port, select Tagged if the switch port/channel is expecting the VLAN to be tagged.
    4. If your switches do not allow untagged packets, then you will need to use the tagall interface option to tag NetScaler High Availability heartbeat packets. See CTX122921 Citrix NetScaler Interface Tagging and Flow of High Availability Packets
    5. If you don’t tag the VLAN, then the NetScaler interface/channel is removed from VLAN 1, and instead put in this VLAN ID.
    6. Switch to the IP Bindings tab.
    7. Check the box next to the Subnet IP for this network. This lets NetScaler know which interface is used for which IP subnet. Click Create when done.
      add vlan 50
bind vlan 50 -ifnum LA/1 -IPAddress 172.16.1.11 255.255.255.0
  5. On the left, expand System, expand Network, and click Routes.
  6. On the right, click Add.
    1. Internal networks are usually only accessible through an internal router. Add a static routes to the internal networks
    2. Make sure NULL Route is set to No.
    3. Set the Gateway (next hop) to an internal router.
    4. Then click Create.
      add route 10.2.0.0 255.255.0.0 10.2.2.1
  7. The default route should be changed to use a router on the DMZ network (towards the Internet). Before deleting the existing default route, either enable Mac Based Forwarding, or create a Policy Based Route, so that the replies from NSIP can reach your machine. You usually only need to do this for dedicated management networks.
    1. Note: PBR is recommended over MBF, because PBR can handle traffic sourced by NSIP (e.g Syslog traffic), while MBF cannot.
    2. Mac Based Forwarding sends replies out the same interface they came in on. However, MBF ignores the routing table, and doesn’t handle traffic sourced by the NSIP (e.g. LDAP traffic). To enable MBF:
      1. On the left, expand System, and click Settings.
      2. On the right, in the left column, click Configure modes.
      3. Check the box next to MAC Based Forwarding (MBF), and click OK. More info on MAC Based Forwarding can be found at Citrix CTX1329532 FAQ: Citrix NetScaler MAC Based Forwarding (MBF).
        enable mode mbf
  8. Go back to System > Network > Routes.
    1. On the right, delete the 0.0.0.0 route. Don’t do this unless the NetScaler has a route, PBR, or MBF to the IP address of the machine you are running the browser on.

      rm route 0.0.0.0 0.0.0.0 10.2.2.1
    2. Then click Add.
    3. Set the Network to 0.0.0.0, and the Netmask to 0.0.0.0.
    4. Make sure NULL Route is set to No.
    5. Enter the IP address of the DMZ (or data) router, and click Create.
      add route 0.0.0.0 0.0.0.0 172.16.1.1

DNS Servers

  1. To configure DNS servers, expand Traffic Management, expand DNS, and click Name Servers.
  2. On the right, click Add.
    1. Enter the IP address of a DNS server, and click Create.
    2. Note: The NetScaler must be able ping each of the DNS servers, or they will not be marked as UP. The ping originates from the SNIP.
      add dns nameServer 10.2.2.11
  3. NetScaler 12 includes DNS Security Options, which are useful if you use this NetScaler to provide DNS services to clients (e.g. DNS Proxy/Load Balancing, GSLB, etc.). You can configure them at Security > DNS Security.

  4. Additional DNS Security Options are detailed at Mitigating DNS DDoS attacks at Citrix Docs.

NTP Servers

  1. On the left, expand System, and click NTP Servers.
  2. On the right, click Add.
  3. Enter the IP Address of your NTP Server (or pool.ntp.org), and click Create.
    add ntp server pool.ntp.org
  4. On the right, open the Action menu, and click NTP Synchronization.
  5. Select ENABLED, and click OK.
    enable ntp sync
  6. You can click the System node to view the System Time.
  7. If you need to manually set the time, SSH (Putty) to the NetScaler appliances. Run date to set the time. Run date –help to see the syntax.
  8. Ntpdate –u pool.ntp.org will cause an immediate NTP time update.

SYSLOG Server

Citrix CTX120609 NetScaler Log Rotation and Configuration Using Newsyslog

The NetScaler will, by default, store a few syslogs on the local appliance. You can create a syslog policy to also send the syslog entries to an external server, like NetScaler Management and Analytics System.

  1. On the left, expand System, expand Auditing, and click Syslog.
  2. On the right, switch to the Servers tab, and click Add.
    1. Enter a name for the Syslog server.
    2. You can change Server Type to Server Domain Name, and enter a FQDN.
    3. Enter the IP Address or FQDN of the SYSLOG server, and 514 as the port.
    4. Configure the Log Levels you’d like to send to it by clicking CUSTOM – typically select everything except DEBUG.
    5. Select your desired Time Zone.
    6. You can optionally enable other logging features.
    7. Then click Create.
      add audit syslogAction MySyslogServer 10.2.2.12 -logLevel ALL -timeZone LOCAL_TIME
add audit syslogAction MySyslogServer syslog.corp.local -logLevel ALL -timeZone LOCAL_TIME
  3. On the right, switch to the Policies tab, and then click Add.
    1. Give the policy a descriptive name,
    2. Change the Expression Type selection to Advanced Policy.
    3. Select the previously created Syslog server.
    4. And then click Create.
      add audit syslogPolicy MySyslogServer ns_true MySyslogServer
  4. While still on the Policies tab, open the Actions menu, and click Classic Policy Global Bindings or Advanced Policy Global Bindings, depending on which one you chose when creating the Syslog policy.
    1. Click Add Binding.
    2. Click where it says Click to select.
    3. Click the radio button next to the Syslog policy you want to bind, and click Select.
    4. If you don’t select anything in Global Bind Type, then it defaults to SYSTEM_GLOBAL.
    5. Click Bind.
    6. Click Close.
    7. If you see a blank screen, click the back button.
      bind audit syslogGlobal -policyName MySyslogServer -priority 100
bind system global MySyslogServer -priority 100

SNMP – MIB, Traps, and Alarms

  1. On the left, expand System, and click SNMP.
  2. On the right, click Change SNMP MIB.
    1. Change the fields as desired. Your SNMP tool (e.g. NetScaler Management and Analytics System) will read this information. Click OK.
    2. This configuration needs to be repeated on the other node.
      set snmp mib -contact NSAdmins@corp.com -name ns02 -location Corp
  3. Expand System, expand SNMP, and click Community.
    1. On the right, click Add.
    2. Specify a community string, and the Permission, and click Create.
      add snmp community public GET
  4. On the left, under SNMP, click Traps.
    1. On the right, click Add.
    2. Specify a trap destination. The fields will vary for V2 vs V3. Click Create.
      add snmp trap generic 10.2.2.12 -communityName public
add snmp trap specific 10.2.2.12 -communityName public
  5. On the left, under SNMP, click Managers.
    1. On the right, click Add. Note: if you do not add a manager then the NetScaler will accept SNMP queries from all SNMP Managers on the network.
    2. Change the selection to Management Network.
    3. Specify the IP of the Management Host, and click Create.
      add snmp manager 10.2.2.12
  6. The Alarms node allows you to enable SNMP Alarms and configure thresholds.
    1. You can open an alarm to set thresholds. For example, CPU-USAGE can be set to 90% alarm, and 50% normal, with a Critical severity.

      set snmp alarm CPU-USAGE -thresholdValue 90 -normalValue 50 -severity Critical
    2. You can also configure the MEMORY alarm.
      set snmp alarm MEMORY -thresholdValue 90 -normalValue 50 -severity Critical

From http://www.slideshare.net/masonke/net-scaler-tcpperformancetuningintheaolnetwork: In addition to the usual OIDs, we have found these very useful to warn of potential problems.

  • ifTotXoffSent – .1.3.6.1.4.1.5951.4.1.1.54.1.43
  • ifnicTxStalls – .1.3.6.1.4.1.5951.4.1.1.54.1.45
  • ifErrRxNoBuffs – .1.3.6.1.4.1.5951.4.1.1.54.1.30
  • ifErrTxNoNSB – .1.3.6.1.4.1.5951.4.1.1.54.1.31

Call Home

Citrix Blog Post – Protect Your NetScaler From Disaster With Call Home!: If you have a physical NetScaler (MPX or SDX) with an active support contract, you many optionally enable Call Home to automatically notify Citrix Technical Support of hardware and software failures.

  1. On the left, expand System, and click Diagnostics.
  2. On the right, in the left column, in the Technical Support Tools section, click Call Home.
  3. Check the box next to Enable Call Home.
  4. Optionally enter an email address to receive notifications from Citrix Technical Support. Click OK.
  5. If you go back into Call Home, it should indicate if registration succeeded or failed. Successful registration requires an active support contract.

Change nsroot Password

  1. If you want to force strong passwords for local accounts, go to System > Settings, and on the right, click Change Global System Settings
    1. Scroll down to the Password section.
    2. You can change Strong Password to Enable Local, and also specify a Min Password Length. Click OK.
  2. Expand System, expand User Administration, and click Users.
  3. On the right, right-click nsroot, and click Change Password.
  4. Specify a new password, and click OK.
    set system user nsroot Passw0rd

TCP, HTTP, SSL, and Security Settings

Citrix Whitepaper Secure Deployment Guide for NetScaler MPX, VPX, and SDX Appliances

Citrix Knowledgebase articles:

  1. On the left, expand System, and click Settings.
  2. On the right, in the right column, click Change TCP parameters.
    1. Check the box for Window scaling (near the top).
    2. Scroll down, and check the box for Selective Acknowledgement. Click OK.
      set ns tcpParam -WS ENABLED -SACK ENABLED
  3. On the right, click Change HTTP parameters.
    1. Under Cookie, change the selection to Version1. This causes NetScaler to set Cookie expiration to a relative time instead of an absolute time.
      set ns param -cookieversion 1
    2. Check the box next to Drop invalid HTTP requests.
    3. Scroll down, and click OK.
      set ns httpParam -dropInvalReqs ON
  4. You can run the following command to see statistics on the dropped packets: 
    nsconmsg -g http_err_noreuse_ -d stats
  5. See CTX209398 Addressing false positives from CBC and MAC vulnerability scans of SSHD to harden SSHD by editing /nsconfig/sshd_config with the following. Then run kill -HUP `cat /var/run/sshd.pid` to restart SSHD. 
    Ciphers aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-ripemd160

The following security configurations are detailed by Jason Samuel at Mitigating DDoS and brute force attacks against a Citrix Netscaler Access Gateway:

  • Maximum logon attempts on NetScaler Gateway Virtual Server
  • Rate Limiting for IP.SRC and HTTP.REQ.URL.
  • nstcp_default_XA_XD_profile TCP profile on the NetScaler Gateway Virtual Server.
  • Syslog logging
  • External website monitoring
  • Obfuscate the Server header in the HTTP response
  • Disable management access on SNIPs
  • Change nsroot strong password, use LDAP authentication, audit local accounts
  • Don’t enable Enhanced Authentication Feedback
  • SSL – disable SSLv3, deny SSL renegotiation, enable ECDHE ciphers, disable RC4 ciphers.
  • 2-factor authentication
  • NetScaler Management & Analytics System
  • Review IPS/IDS & Firewall logs

Management Authentication

Load balancing of LDAP servers is strongly recommended. If you bound multiple LDAP servers instead of load balancing them, NetScaler would try each of the LDAP servers, and for incorrect passwords, will lock out the user sooner than expected. But if you instead load balance your LDAP servers, the authentication attempt will only be sent to one of them.

  1. Expand System, expand Authentication, expand Basic Policies, and then click LDAP.
  2. On the right, switch to the Servers tab. Then click Add.
    1. Enter LDAPS-Corp-Mgmt 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. Also, the LDAP policy used for management authentication will be different than the LDAP policy used for NetScaler Gateway.
    2. Change the selection to Server IP. Enter the VIP of the NetScaler load balancing vServer for LDAP.
    3. Change the Security Type to SSL.
    4. Enter 636 as the Port. Scroll down.
    5. In the Connection Settings section, enter your Active Directory DNS domain name in LDAP format as the Base DN.
    6. Enter the credentials of the LDAP bind account in userPrincipalName format.
    7. Check the box next to BindDN Password and enter the password. Click Test Connection. Scroll down.
    8. In the Other Settings section, use the drop-down next to Server Logon Name Attribute, Group Attribute, and Sub Attribute Name to select the default fields for Active Directory.
    9. On the right, check the box next to Allow Password Change.
    10. It is best to restrict access to only members of a specific group. In the Search Filter field, enter memberOf=<GroupDN>. See the example below:
      memberOf=CN=NetScaler Administrators,OU=Citrix,DC=corp,DC=local
      You can add :1.2.840.113556.1.4.1941: to the query 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=NetScaler Administrators,OU=Citrix,DC=corp,DC=local

      Citrix 132802 How to Use the ldapsearch Utility on the NetScaler Gateway Enterprise Edition Appliance to Validate a Search Filter
      An easy way to get the full distinguished name of the group is through Active Directory Administrative Center. Double-click the group object, and switch to the Extensions page. On the right, switch to the Attribute Editor tab.
      Scroll down to distinguishedName, double-click it, and then copy it to the clipboard.

      Back on the NetScaler, in the Search Filter field, type in memberOf=, and then paste the Distinguished Name right after the equals sign. Don’t worry about spaces.
    11. Scroll down and click More to expand it.
    12. For Nested Group Extraction, if desired, change the selection to Enabled.
    13. Set the Group Name Identifier to samAccountName.
    14. Set Group Search Attribute to –<< New >>–, and enter memberOf.
    15. Set Group Search Sub-Attribute to –<< New >>–, and enter CN.
    16. Example of LDAP Nested Group Search Filter Syntax

    17. Scroll down, and click Create.
      add authentication ldapAction Corp-Mgmt -serverIP 10.2.2.210 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword Passw0rd -ldapLoginName samaccountname -searchFilter "memberOf=CN=NetScaler Admins,CN=Users,DC=corp,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
  3. On the left, go to System > Authentication > Advanced Policies > Policy.
  4. On the right, click Add.
    1. Enter the name LDAPS-Corp-Mgmt or similar.
    2. Change the Action Type drop-down to LDAP.
    3. Select the previously created LDAPS-Corp-Mgmt server.
    4. On the bottom, in the Expression area, type in true.
    5. Click Create.
      add authentication Policy LDAPS-Corp-Mgmt -rule true -action LDAPS-Corp-Mgmt
  5. Click Global Bindings in the right pane.
    1. Click where it says Click to select.
    2. Click the radio button next to the newly created LDAP policy, and click Select.
    3. Click Bind.
    4. Click Done.
      bind system global LDAPS-Corp-Mgmt -priority 100 -gotoPriorityExpression NEXT
  6. Under System, expand User Administration, and click Groups.
    1. On the right, click Add.
    2. In the Group Name field, enter the case sensitive name of the Active Directory group containing the NetScaler administrators.
    3. In the Command Policies section, click Bind.
    4. Select the superuser policy, and click Insert.
    5. Scroll down, and click Create.
      add system group "NetScaler Admins" -timeout 900
bind system group "NetScaler Admins" -policyName superuser 100
  7. If you logout:
  8. You should be able to login to NetScaler using an Active Directory account.

CLI Prompt

  1. When you connect to the NetScaler CLI prompt, by default, the prompt is just a >.
  2. You can run set cli prompt %u@%h to make it the same as a UNIX prompt. See Citrix Docs for the cli prompt syntax.

Backup and Restore

  1. On the left, expand System, and click Backup and Restore.
  2. On the right, click the Backup button.
  3. Give the backup file a name.
  4. For Level, select Full, and click Backup.
  5. Once the backup is complete, you can download the file.

For a PowerShell script, see John Billekens Create offline backups of the NetScaler config

To restore:

  1. If you want to restore the system, and if the backup file is not currently on the appliance, you click the Backup button. Yes, this seems backwards.
  2. Change the selection to Add.
  3. Browse Local to the previously downloaded backup file.
  4. Then click Backup. This uploads the file to the appliance and adds it to the list of backup files.
  5. Now you can select the backup, and click Restore.

Next Steps

↧
Search

StoreFront Load Balancing – NetScaler 12

August 4, 2017, 7:18 am
$
0
0

Navigation

Monitor

Note: This is a Perl monitor, which uses the NSIP as the source IP. You can use RNAT to override this as described in CTX217712 How to Force scriptable monitor to use SNIP in Netscaler in 10.5.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it StoreFront or similar.
  4. Change the Type drop-down to STORERONT.
  5. If you will use SSL/https to communicate with the StoreFront servers, then scroll down, and check the box next to Secure.
  6. Scroll up, and switch to the Special Parameters tab.
  7. In the Store Name field, enter the name of your store (e.g. MyStore) without spaces.
  8. Click Create.
    add lb monitor StoreFront STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -secure YES -storename Store

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 server.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding StoreFront servers.
    add server SF01 10.2.2.57
add server SF02 10.2.2.58

Service Group

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SSL).
  4. Change the Protocol to HTTP or SSL. If the protocol is SSL, ensure that the StoreFront Monitor has Secure checked.
  5. Scroll down, and click OK.
  6. Click where it says No Service Group Member.
    1. If you did not create server objects, then enter the IP address of a StoreFront Server. If you previously created a server object, then change the selection to Server Based, and select the server objects.
    2. Enter 80 or 443 as the port. Then click Create.
    3. In the Service Group Members section, click OK.
  7. On the right, under Advanced Settings, click Monitors.
  8. On the left, scroll down to the Monitors section, and click where it says says No Service Group to Monitor Binding.
    1. Click where it says Click to select.
    2. Click the radio button next to your StoreFront monitor, and click Select.
    3. Then click Bind.
  9. To verify that the monitor is working, on the left, in the Service Group Members section, click the Service Group Members line.
    1. Right-click a member, and click Monitor Details.
    2. The Last Response should be Success – Probe succeeded. Click Close twice.
  10. On the left, if you see a Settings section, then click the pencil icon.
    1. If you don’t see the Settings section, then on the right, under Advanced Settings, click Settings.
  11. On the left, in the Settings section, check the box for Client IP, and enter X-Forwarded-For as the Header. Then click OK.
  12. Scroll down, and click Done.
    add serviceGroup svcgrp-StoreFront-SSL SSL -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For

bind serviceGroup svcgrp-StoreFront-SSL SF01 443
bind serviceGroup svcgrp-StoreFront-SSL SF02 443
bind serviceGroup svcgrp-StoreFront-SSL -monitorName StoreFront
  13. If the Service Group is http, and if you don’t have certificates installed on your StoreFront servers (aka SSL Offload), then you’ll need to enable loopback in StoreFront.
    1. In StoreFront 3.5 and newer, you enable it in the GUI console.
    2. In StoreFront 3.0, run the following commands on the StoreFront 3.0 servers as detailed at Citrix Blog Post What’s New in StoreFront 3.0. 
      & "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"

Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb -Loopback OnUsingHttp

Load Balancing Virtual Server

  1. Create or install a certificate that will be used by the SSL Load Balancing Virtual Server. This certificate must match the DNS name for the load balanced StoreFront servers.

    1. For email discovery in Citrix Receiver, the certificate must match discoverReceiver.email.suffix for each email suffix. This is typically done using Subject Alternative Names.
  2. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  3. On the right, click Add.
  4. Name it lbvip-StoreFront-SSL or similar.
  5. Change the Protocol to SSL.
  6. Specify a new internal VIP.
  7. Enter 443 as the Port.
  8. Click OK.
    add lb vserver lbvip-StoreFront-SSL SSL 10.2.2.221 443 -persistenceType SOURCEIP -timeout 60
  9. On the left, 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 radio button next to your StoreFront Service Group, and click Select.
    3. Click Bind.
      bind lb vserver lbvip-StoreFront-SSL svcgrp-StoreFront-SSL
  10. In the Services and Service Groups section, click Continue.
  11. Click where it says No Server Certificate.
    1. Click where it says Click to select.
    2. Click the radio button next to the certificate for this StoreFront Load Balancing Virtual Server, and click Select.
    3. Click Bind.
      bind ssl vserver lbvip-StoreFront-SSL -certkeyName WildCorpCom
  12. In the Certificates section, click Continue.
  13. On the right, in the Advanced Settings column, click Persistence.
  14. On the left, in the Persistence section, select SOURCEIP. Do NOT use COOKIEINSERT persistence or Android devices will not function correctly.
  15. Set the timeout to match the timeout of Receiver for Web.
  16. The IPv4 Netmask should default to 32 bits.
  17. Click OK.
  18. If the NetScaler communicates with the StoreFront servers using HTTP (aka SSL Offload, which means SSL 443 on the client-side, and HTTP 80 on the server-side):
    1. If the default SSL Profile is not enabled, then you’ll need to edit the SSL Parameters section on the vServer, and at the top right, check the box next to SSL Redirect. Otherwise the Receiver for Web page will never display.
      set ssl vserver lbvip-StoreFront-SSL -sslRedirect ENABLED -ssl3 DISABLED
    2. If you have enabled the Default SSL Profile, then you’ll either need to edit the Default SSL Profile to include the SSL Redirect option, or create a new custom SSL Profile with the SSL Redirect option enabled, and then bind the custom SSL Profile to this vServer.
  19. If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind a Modern Cipher Group, and enable Strict Transport Security. 
    bind ssl vserver lbvip-StoreFront-SSL -certkeyName MyCert

set ssl vserver lbvip-StoreFront-SSL -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED

unbind ssl vserver lbvip-StoreFront-SSL -cipherName ALL

bind ssl vserver lbvip-StoreFront-SSL -cipherName custom-ssl-labs

bind ssl vserver lbvip-StoreFront-SSL -eccCurveName ALL

bind lb vserver lbvip-StoreFront-SSL -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE

When connecting to StoreFront through load balancing, if you want to put the server name on the StoreFront webpage so you can identify the server, see Nicolas Ignoto Display server name with Citrix StoreFront 3.
Server name is displayed

SSL Redirect – SSL Load Balancing vServer Method

Users must enter https:// when navigating to the StoreFront website. To make it easier for the users, enable SSL Redirection.

This procedure details the SSL Load Balancing vServer method of performing an SSL redirect. An alternative is to use the Responder method.

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  2. On the right, find the SSL Virtual Server you’ve already created, right-click it, and click Edit.
  3. In the Basic Settings section, click the pencil icon.
  4. Click the More link.
  5. In the Redirect from Port field, enter 80.
  6. In the HTTPS Redirect URL field, enter your StoreFront Load Balancing URL (e.g. https://storefront.corp.com).
  7. Scroll down, and click Continue twice.
    set lb vserver lbvip-StoreFront-SSL -redirectFromPort 80 -httpsRedirectUrl https://storefront.corp.com
  8. Note: this method does not show you that it’s listening on port 80.

StoreFront Base URL

  1. Create a DNS Host record that resolves to the new VIP.
  2. The DNS name for StoreFront load balancing must be different than the DNS name for NetScaler Gateway. Unless you are following the Single FQDN procedure.

  3. In the Citrix StoreFront console, right-click Server Group, and click Change Base URL.
  4. Enter the new Base URL in https://storefront.corp.com format. This must match the certificate that is installed on the load balancer. Click OK.
  5. Right-click your store, and click Manage Receiver for Web Sites.
  6. Click Configure.
  7. On the Advanced Settings page, change Enable loopback communication to OnUsingHttp. This tells StoreFront to not use the load balancer for inter-server communication.

Subscription Replication Load Balancing

If you have multiple StoreFront Server Groups (usually in separate datacenters), you might want to replicate subscriptions (favorites) between them. StoreFront subscription replication uses TCP port 808. To provide High Availability for this port number, load balance TCP port 808 on the StoreFront servers. See Configure subscription synchronization at Citrix Docs for more information.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, right-click your existing StoreFront service group, and click Add.
    1. Give the Service Group a descriptive name (e.g. svcgrp-StoreFront-SubRepl).
    2. Change the Protocol to TCP.
    3. Scroll down, and click OK.
    4. In the Service Group Members section, click where it says No Service Group Member.
    5. Change the selection to Server Based, and select the StoreFront servers.
    6. Enter 808 as the port. Then click Create.
    7. Click OK to close the Service Group Members section.
    8. On the right, under Advanced Settings, click Monitors.
    9. On the left, scroll down, and in the Monitors section, click where it says No Service Group to Monitor Binding.
    10. Click where it says Click to select.
    11. Click the radio button next to the tcp monitor, and click Select.
    12. Click Bind.
    13. Click Done to close the Service Group.
      add serviceGroup svcgrp-StoreFront-FavRepl TCP
bind serviceGroup svcgrp-StoreFront-FavRepl SF01 808
bind serviceGroup svcgrp-StoreFront-FavRepl SF02 808
  3. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  4. On the right, right-click the existing StoreFront Load Balancing vServer, and click Add.
    1. Name it lbvip-StoreFront-SubRepl or similar.
    2. Change the Protocol to TCP.
    3. Specify the same VIP that you used for SSL Load Balancing of StoreFront.
    4. Enter 808 as the Port.
    5. Click OK.
    6. In the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.

    7. Click where it says Click to select.
    8. Click the radio button next to your StoreFront Subscription Replication Service Group, and click Select.
    9. Click Bind.
    10. In the Services and Service Groups section, click Continue.
    11. Scroll down, and click Done to close the Virtual Server. There’s no need for persistence or redirects.
      add lb vserver lbvip-StoreFront-FavRepl TCP 10.2.2.201 808 -persistenceType NONE

bind lb vserver lbvip-StoreFront-FavRepl svcgrp-SF-FavRepl

Related Posts

↧
↧

SSL Virtual Servers – NetScaler 12

August 5, 2017, 10:17 am
$
0
0

This page contains generic SSL instructions for all SSL-based Virtual Servers, including: Load Balancing, NetScaler Gateway, Content Switching, and AAA.

Navigation

💡 = Recently Updated

Cipher Group

References:

To get an A+ at SSL Labs, create a custom secure cipher group:

  1. The easiest way to create a cipher group is from the CLI. See Citrix Blogs Scoring an A+ at SSLlabs.com with Citrix NetScaler – 2016 update for cipher group CLI commands. Putty (SSH) to the NetScaler and paste the following commands. 
    add ssl cipher custom-ssllabs-cipher
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-AES-256-CBC-SHA
bind ssl cipher custom-ssllabs-cipher -cipherName TLS1-AES-128-CBC-SHA
  2. Or you can create the cipher group using the GUI.
    1. Go to Traffic Management > SSL > Cipher Groups.
      1. On the right, click Add.
      2. Name it SSL Labs or similar.
      3. In the middle, click Add.
      4. Use the search box to find a particular cipher.
      5. Check the box next to one of the results, and click the arrow to move it to the right. See Citrix Blog Post Scoring an A+ at SSLlabs.com with Citrix NetScaler – 2016 update for recommended ciphers.
      6. Use the up and down arrows to order the ciphers. NetScaler prefers the ciphers on top of the list, so the ciphers at the top of the list should be the most secure ciphers.
    2. Click Create when done.

Strict Transport Security – Rewrite Policy Method

To get an A+ at SSLLabs.com, you need to insert the Strict-Transport-Security HTTP header in the responses. NetScaler Rewrite Policy is one method of doing this. Another method is to enable HSTS in an SSL Profile, or enable it in SSL Parameters on a SSL vServer.

To create a Rewrite Policy that inserts the Strict-Transport-Security HTTP header:

  1. On the left, expand AppExpert, right-click Rewrite, and click Enable Feature.
  2. Create the Rewrite Action:
    1. Go to AppExpert > Rewrite > Actions.
    2. On the right, click Add.
    3. Name the action insert_STS_header or similar.
    4. The Type should be INSERT_HTTP_HEADER.
    5. The Header Name should be Strict-Transport-Security.
    6. The Expression should be the following: 
      "max-age=157680000"

    7. Click Create.
  3. Create the Rewrite Policy:
    1. On the left, go to AppExpert > Rewrite > Policies.
    2. On the right, click Add.
    3. Name it insert_STS_header or similar.
    4. Select the previously created Action.
    5. In the Expression box, enter HTTP.REQ.IS_VALID.
    6. Click Create.
  4. Now you can bind this Rewrite Response policy to HTTP-based SSL vServers.
    1. When editing an SSL vServer (Gateway vServer, Load Balancing vServer, etc.), if the Policies section doesn’t exist on the left, then add it from the Advanced Settings column on the right.
    2. On the left, in the Policies section, click the plus icon.
    3. Change the Choose Policy drop-down to Rewrite.
    4. Change the Choose Type drop-down to Response, and click Continue.
    5. Click where it says Click to select.
    6. Click the radio button next to insert_STS_header, and click Select.
    7. Click Bind.
enable ns feature rewrite

add rewrite action insert_STS_header insert_http_header Strict-Transport-Security "\"max-age=157680000\""

add rewrite policy insert_STS_header true insert_STS_header

bind lb vserver MyvServer -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE

SSL Profiles – Custom and Default

You can use SSL Profiles to package several SSL settings together, and apply the settings package (Profile) to SSL-based Virtual Servers and SSL-based Services. These SSL settings include:

  • Disable SSLv3
  • Bind secure ciphers
  • Bind ECC curves
  • Enable HSTS (Strict Transport Security), etc.

There are default SSL Profiles, and there are custom SSL Profiles. The default SSL Profiles are disabled by default, because they would impact every SSL-based Virtual Server and Service on the appliance. Once default SSL Profiles are enabled, you cannot disable the default SSL Profiles.

  • Some features of custom SSL Profiles require default SSL Profiles to be enabled. For example, you cannot configure ciphers in a custom SSL Profile unless the default SSL Profiles are enabled.

Default SSL Profiles are intended to provide a baseline SSL configuration for all newly created SSL Virtual Servers and SSL Services. You can still create Custom SSL Profiles to override the Default SSL Profiles.

To enable Default SSL profiles

Enabling Default SSL Profiles is irreversible.

  1. Make sure you are connected to the appliance NSIP using http, and not https.
  2. Go to Traffic Management > SSL.
  3. On the right, in the right column, click Change advanced SSL settings.
  4. Near the bottom, check the box next to Enable Default Profile. Note: this will change SSL settings on all SSL Virtual Servers to match the default SSL profile. You might want to do this during a maintenance window.

  5. Click OK to close Change Advanced SSL Settings.
  6. If you go back into Change Advanced SSL Settings, notice that the Default Profile is enabled, and there’s no way to disable it.

To create a custom SSL Profile

  1. On the left, expand System, and click Profiles.
  2. On the right, switch to the SSL Profile tab.
    1. Click Add.
    2. Enter a name.
    3. Change the SSL Profile Type to FrontEnd or BackEnd.
    4. Configure SSL Profile settings as desired (see below for some recommendations).
  3. After the SSL Profile is created, edit any SSL-based Virtual Server.
    1. On the right, in the Advanced Settings column, click SSL Profile to add the section.
    2. On the left, scroll down to the SSL Profile section, and select an SSL Profile. Click OK to close the SSL Profile section.

Recommended SSL Profile Settings

  1. On the left, expand System, and click Profiles.
  2. On the right, switch to the SSL Profile tab.
  3. Either create a new SSL Profile, or edit the default frontend or backend profile. This section focuses on a FrontEnd profile.
    1. Frontend = client-side connections to SSL Virtual Servers.
    2. Backend = server-side connections (SSL Services and Service Groups).
  4. Click the pencil icon in the Basic Settings section.
    1. Scroll all the way down to the Protocol section.
    2. Notice that SSLv3 is already unchecked.
    3. You can optionally uncheck TLSv1 and TLSv11.
    4. To enable Strict Transport Security (HSTS), scroll up a little, and check the box next to HSTS.
    5. Enter 157680000 in the Max Age box.
    6. Note: enabling HSTS in the Default SSL Profile seems to break Native OTP. Enabling HSTS in a Rewrite policy works fine.
    7. If you do any SSL Offload (SSL on the client side, HTTP on the server side), then you’ll need to enable SSL Redirect. It’s above HSTS. With this option enabled, any 301/302 redirects from the server with HTTP Location headers are rewritten to HTTPS Location headers. You might need this option for StoreFront load balancing if doing SSL Offload (port 80 to the StoreFront servers). Note: this setting might be more appropriate in a custom SSL Profile instead of the default SSL Profile.
    8. Click OK when done modifying the Basic Settings section.
  5. Scroll down to the SSL Ciphers section, and click the pencil icon.
    1. Click Remove All, and click OK. You must click OK before binding the custom cipher group.

    2. Click the pencil icon again.
    3. Click Add.
    4. Scroll down, and select your custom cipher group (e.g. SSL Labs). Click the arrow to move it to the right.
    5. Click OK to close the Custom Ciphers section.

SSL vServers – Bind Certificate, Bind Cipher Group, Disable SSLv3, Enable STS

If you enabled the Default SSL Profiles feature, you can either leave the vServer configured with the Default SSL Profile; or you can change the vServer to use a Custom SSL Profile.

If you don’t use the SSL Profiles feature, then you’ll need to manually configure ciphers and SSL settings on every SSL vServer.

Do the following on every SSL vServer:

  1. When creating an SSL Virtual Server (e.g. SSL Load Balancing vServer), 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 radio button next to a certificate ,and click Select.
    3. Click Bind.
      bind ssl vserver MyvServer -certkeyName MyCert
  2. You can bind a Custom SSL Profile:
    1. Find the SSL Profile section on the left, and click the pencil icon.
      1. If you don’t see the SSL Profile section on the left, then add the SSL Profile section from the Advanced Settings column on the right.
    2. Select a Custom SSL Profile, and click OK.
  3. If default SSL Profiles are not enabled:
    1. On the left, in the SSL Parameters section, click the pencil icon.
    2. Uncheck the box next to SSLv3. You can optionally uncheck TLSv1 and TLSv11. Click OK.
      set ssl vserver MyvServer -ssl3 DISABLED -tls12 ENABLED
    3. If you didn’t bind an SSL Profile, scroll down to the SSL Ciphers section, and click the pencil icon.
    4. Click Remove All, and click OK. You must click OK before binding the custom cipher group.
    5. Click the pencil icon again.
    6. Change the selection to Cipher Groups.
    7. Select your custom cipher group. It’s probably at the bottom of the list. Then click OK.
      unbind ssl vserver MyvServer -cipherName ALL
bind ssl vserver MyvServer -cipherName custom-ssllabs-cipher
  4. SSL Virtual Servers created on newer versions of NetScaler will automatically have ECC Curves bound to them. However, if this appliance was upgraded from an older version, then the ECC Curves might not be bound. If you are not using SSL Profile, then on the right, in the Advanced Settings column, click ECC Curve.
    1. On the left, in the ECC Curve section, click where it says No ECC Curve.
    2. Click where it says Click to select.
    3. Click the radio button next to ALL, and click Select.
    4. Click Bind.
      bind ssl vserver MyvServer -eccCurveName ALL
  5. If HSTS is not enabled in a bound SSL Profile, you can enable it in SSL Parameters, or you can enable it by binding a Rewrite policy.
  6. To enable HSTS by configuring SSL Parameters:
    1. On the left, find the SSL Parameters section, and click the pencil icon. This section is only present if Default SSL Profiles are not enabled. Don’t configure this if you bound a Custom SSL Profile.
    2. In the right column, check the box next to HSTS.
    3. Enter 157680000 in the Max Age box.
    4. Note: enabling HSTS in the Default SSL Profile seems to break Native OTP. Enabling HSTS in a Rewrite policy works fine.
    5. Click OK to close SSL Parameters.
  7. If enabling HSTS in an SSL Profile or SSL Parameters causes technical issues, then bind a Rewrite policy instead:
    1. If the Policies section doesn’t exist on the left, then add it from the Advanced Settings column on the right.
    2. On the left, find the Policies section, and click the plus icon.
    3. Change the Choose Policy drop-down to Rewrite.
    4. Change the Choose Type drop-down to Response, and click Continue.
    5. Click where it says Click to select.
    6. Click the radio button next to the insert_STS_header policy, and click Select.
    7. Click Bind.
      bind lb vserver MyvServer -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE

If you experience SSL performance problems on a NetScaler MPX, Citrix CTX207005 Performance Issues with NetScaler MPX SSL recommends creating and binding the following TCP Profile:

add ns tcpProfile tcp_test -WS ENABLED -SACK ENABLED -maxBurst 20 -initialCwnd 8 -bufferSize 4096000 -flavor BIC -dynamicReceiveBuffering DISABLED -sendBuffsize 4096000

SSL Tests

After you’ve created an SSL Virtual Server and configured SSL settings, run the following test:

SSL Redirect – Methods

There are typically three methods of performing SSL Redirect (http to https) in NetScaler:

  • Load Balancing Virtual Server Method – enable SSL Redirect directly on the Load Balancing Virtual Server. This is the easiest method.
    • This option is not available for Gateway Virtual Servers and Content Switching Virtual Servers.
    • There’s nothing in the GUI to indicate that the SSL Virtual Server is also listening on port 80.
  • Down vServer Method – create a new Load Balancing Virtual Server on Port 80, and configure the Redirect URL for when it is down.
    • The Virtual Server must be DOWN for the Redirect to occur. These Virtual Servers are shown as Red instead of Green.
  • Responder Method – create a new Load Balancing Virtual Server on Port 80, and bind a Responder policy that redirects to https.
    • The Responder policy only works if the Virtual Server is UP, which means it is shown as Green.
    • Some setup tasks are required – create the AlwaysUP service, and create the Responder Policy. But once setup is complete, it only requires slightly more steps than the Down vServer method.

SSL Redirect – SSL Load Balancing vServer Method

You can configure SSL Redirect directly in an SSL Load Balancing vServer (port 443) instead of creating a separate HTTP (port 80) Load Balancing vServer.

Limitations:

  • This is only an option for SSL Load Balancing vServers; it’s not configurable in Gateway vServers or Content Switching vServers.
  • Only one Redirect URL can be specified. Alternatively, the Responder method can handle multiple FQDNs to one VIP (e.g. wildcard certificate) and/or IP address URLs.

To configure an SSL Load Balancing vServer to redirect from HTTP to HTTPS:

  1. Edit the SSL Load Balancing vServer (port 443).
  2. In the Basic Settings section, click the pencil icon.
  3. Click More.
  4. In the Redirect from Port field, enter 80.
  5. In the HTTPS Redirect URL field, enter https://MyFQDN.
  6. Click Continue twice.
  7. When you view the list of Load Balancing Virtual Servers, there’s no indication that it’s listening on port 80.

SSL Redirect – Down vServer Method

If you created an SSL Virtual Server that only listens on SSL 443, then users must enter https:// when navigating to the website. To make it easier for the users, create another load balancing Virtual Server on the same VIP, but listens on HTTP 80, and then redirects the user’s browser to reconnect on SSL 443.

The Down Virtual Server Method is easy, but the Redirect Virtual Server must be down in order for the redirect to take effect. Another option is to use Responder policies to perform the redirect.

To create the down Redirect Virtual Server:

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  2. On the right, right-click an SSL Virtual Server you’ve already created, and click Add. Doing it this way copies some of the data from the already created Virtual Server.
  3. Or, if you are redirecting NetScaler Gateway, create a new Load Balancing vServer with the same VIP as the Gateway.
  4. Change the name of the Virtual Server to indicate that this new Virtual Server is an SSL Redirect.
  5. Change the Protocol to HTTP on Port 80.
  6. The IP Address should already be filled in. It must match the original SSL Virtual Server (or Gateway vServer). Click OK.
  7. Don’t bind any services. This vServer must intentionally be marked down so the redirect will take effect. Click Continue.
  8. On the right, in the Advanced Settings column, click Protection.
  9. On the left, in the Protection section, in the Redirect URL field, enter the full URL including https://. For example: https://storefront.corp.com/Citrix/StoreWeb.
  10. Click OK to close the Protection section.
  11. Click Done.
  12. When you view the SSL redirect Virtual Server in the list, it will have a state of DOWN. That’s expected. The Port 80 Virtual Server must be DOWN for this redirect method to work.

SSL Redirect – Responder Method

The Down Virtual Server Method is easy, but the Redirect Virtual Server must be down in order for the redirect to take effect. Another option is to use Responder policies to perform the redirect. This method requires the Redirect Virtual Server to be UP.

Responder Method Setup Tasks

  1. Create a dummy Load Balancing service. This dummy service can be bound to multiple Redirect Virtual Servers.
    1. Go to Traffic Management > Load Balancing > Services.
    2. On the right, click Add.
    3. Name the service AlwaysUp or similar.
    4. Enter a loopback IP address (e.g. 127.0.0.1). After the service is created, the service IP changes to a NetScaler-owned IP.
    5. Click the More link.
    6. This dummy service must always be UP, so uncheck the box next to Health Monitoring.
    7. Click OK, and then click Done to close the Load Balancing Service.

      add server 127.0.0.1 127.0.0.1
add service AlwaysUp 127.0.0.1 HTTP 80 -healthMonitor NO
  2. Create the Responder Action:
    1. On the left, expand AppExpert, and click Responder.
    2. If Responder feature is not enabled, right-click Responder, and click Enable Feature.
      enable ns feature RESPONDER
    3. Under Responder, click Actions.
    4. On the right, click Add.
    5. Give the action a name.
    6. Change the Type to Redirect. If you leave this set to Respond With then it won’t work.
    7. Enter an expression. The following expression redirects to https on the same URL the user entered in the browser. Or you can create a Responder Action with a more specific Target. Click Create. 
      "https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE

      add responder action http_to_ssl_redirect_responderact redirect "\"https://\" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE" -responseStatusCode 302
  3. Create the Responder Policy:
    1. On the left, under Responder, click Policies.
    2. On the right, click Add.
    3. Give the policy a name.
    4. Select the previously created Responder action.
    5. For the expression, enter the following. Then click Create. 
      HTTP.REQ.IS_VALID

      add responder policy http_to_ssl_redirect_responderpol HTTP.REQ.IS_VALID http_to_ssl_redirect_responderact

Enable Redirect using Responder Policy

  1. Create a Load Balancing Virtual Server with Protocol HTTP, and Port 80. The VIP should match an existing SSL Virtual Server or NetScaler Gateway Virtual Server.

  2. Bind the AlwaysUp service.
    1. In the Services and Service Groups section, click where it says No Load Balancing Virtual Server Service Binding.
    2. Click where it says Click to select.
    3. Check the box next to AlwaysUp, and click Select.
    4. Click Bind.
    5. Click Continue to close Services and Service Groups.
  3. Bind the Responder Policy:
    1. On the right, in the Advanced Settings column, click Policies.
    2. On the left, scroll down to the Policies section, and click the plus icon in the top right of the Policies box.
    3. Change the Choose Policy drop-down to Responder. Click Continue.
    4. Click where it says Click to select.
    5. Click the radio button next to the redirect Responder policy, and click Select.
    6. Click Bind.
    7. Then click Done to close the Load Balancing Virtual Server.
      add lb vserver MyvServer-HTTP-SSLRedirect HTTP 10.2.2.201 80

bind lb vserver storefront.corp.com-HTTP-SSLRedirect AlwaysUp

bind lb vserver storefront.corp.com-HTTP-SSLRedirect -policyName http_to_ssl_redirect_responderpol -priority 100 -gotoPriorityExpression END -type REQUEST
  4. The primary advantage of this method is that the Redirect Virtual Server is UP.

Related Pages

↧

NetScaler 12 Certificates

August 6, 2017, 5:55 am
$
0
0

Navigation

💡 = Recently Updated

Convert .PFX Certificate to PEM Format

You can export a certificate (with private key) from Windows, and import it to NetScaler.

To export a Windows certificate in .pfx format

  1. If Windows 2012 or newer, on the Windows server that has the certificate, you can run certlm.msc to open the Certificates console pointing at Local Computer.
    1. Or, run mmc.exe, manually add the Certificates snap-in, and point it to Local Computer.
  2. Go to Personal > Certificates.
  3. Right-click the certificate, expand All Tasks, and click Export.
  4. On the Welcome to the Certificate Export Wizard page, click Next.
  5. On the Export Private Key page, select Yes, export the private key, and click Next.
  6. On the Export File Format page, click Next.
  7. On the Security page, check the box next to Password, and enter a new temporary password. Click Next.
  8. On the File to Export page, specify a save location and name the .pfx file. Don’t put any spaces in the filename. Click Next.
  9. In the Completing the Certificate Export Wizard page, click Finish.
  10. Click OK when prompted that the export was successful.

To auto-convert a .pfx file (without private key encryption)

NetScaler can auto-convert a .pfx file to PEM format. However, the converted file it creates is not encrypted.

To import the .pfx file:

  1. On the NetScaler, expand Traffic Management, and click SSL.
  2. If the SSL feature is disabled, right-click the SSL node, and click Enable Feature.
  3. Go to Traffic Management > SSL > Certificates > Server Certificates.
  4. There are three different certificate nodes:
    1. Server Certificates have private keys. These certificates are intended to be bound to SSL vServers.
    2. Client Certificates also have private keys, but they are intended to be bound to Services so NetScaler can perform client-certificate authentication against back-end web servers.
    3. CA Certificates don’t have private keys. The CA certificates node contains intermediate certificates that are linked to Server Certificates. CA certificates can also be used for SAML authentication, and to verify client certificates.
  5. On the left, click the Server Certificates node.
  6. On the right, click Install.
  7. Give the certificate a name.
  8. Click the drop-down next to Choose File, select Local, and browse to the .pfx file that you exported earlier.
  9. After browsing to the .pfx file, NetScaler will prompt you to enter the password for the .pfx file.
  10. Then click Install.
  11. You can now link an intermediate certificate to this SSL certificate, and then bind this SSL certificate to SSL and/or NetScaler Gateway Virtual Servers.
  12. To automatically backup SSL certificates and receive notification when the certificates are about the expire, deploy NetScaler Management and Analytics System. Also see Citrix CTX213342 How to handle certificate expiry on NetScaler.
  13. You can also export the certificate files and use them on a different NetScaler.
  14. If you click the information icon next to the new certificate…
  15. You’ll see that NetScaler created a new file with a .ns extension.
  16. You can look inside this file by going to Traffic Management > SSL > Manage Certificates / Keys / CSRs.
  17. Right-click the new file, and click View.
  18. Notice that the RSA Private Key is not encrypted, encoded, or password protected.

To convert PFX to PEM (with Private Key encryption)

If you want to encrypt your key file (recommended), use the older method of converting from PFX to PEM.

  1. In the NetScaler Configuration GUI, on the left, expand Traffic Management, and click SSL.
  2. In the right column of the right pane, in the Tools section, click Import PKCS#12.
  3. In the Import PKCS12 File dialog box:
    1. In the Output File Name field, enter a name (e.g. Wildcard.cer) for a new file where the converted PEM certificate and private key will be placed. This new file is created under /nsconfig/ssl on the NetScaler appliance.
    2. In the PKCS12 File field, click Choose File, and select the previously exported .pfx file.
    3. In the Import Password field, enter the password you specified when you previously exported the .pfx file.
    4. Change the Encoding Format selection to DES3. This causes the new PEM file to be password protected, and encrypted.
    5. Enter a permanent password for the new PEM file, and click OK.
  4. You can use the Manage Certificates / Keys / CSRs link to view the new PEM file.
    1. Right-click the new file, and click View.
    2. Notice that the Private Key is encrypted.
    3. If you scroll down, notice that the file contains both the certificate, and the RSA Private key.
  5. Now that the PFX file has been converted to a PEM file, the PEM certificate file must be installed before it can be used.
    1. On the left side of the NetScaler Configuration GUI, go to Traffic Management > SSL > Certificates > Server Certificates.
    2. On the right, click Install.
    3. In the Certificate-Key Pair Name field, enter a friendly name for this certificate.
    4. In the Certificate File Name field, click the drop-down next to Choose File, and select Appliance.
    5. Click the radio button next to the .cer file you just created, and click Open. The new file is probably at the bottom of the list.
    6. NetScaler will ask you to enter the password for the encrypted private key.
    7. Click Install.
  6. You can now link an intermediate certificate to this SSL certificate, and then bind this SSL certificate to SSL and/or NetScaler Gateway Virtual Servers.
  7. To automatically backup SSL certificates and receive notification when the certificates are about the expire, deploy NetScaler Management and Analytics System. Also see Citrix CTX213342 How to handle certificate expiry on NetScaler.
  8. You can also export the certificate files and use them on a different NetScaler.

Create Key and Certificate Request

If you want to create free Let’s Encrypt certificates, see John Billekens’ PowerShell script detailed at Let’s Encrypt Certificates on a NetScaler.

You can create a key pair and Certificate Signing Request (CSR) directly on the NetScaler appliance. The CSR can then be signed by an internal, or public, Certificate Authority.

Most Certificate Authorities let you add Subject Alternative Names when creating (or purchasing) a signed certificate, and thus there’s no reason to include Subject Alternative Names in the CSR created on NetScaler. You typically create a CSR with a single DNS name. Then when submitting the CSR to the Certificate Authority, you type in additional DNS names.

  • For a Microsoft Certificate Authority, you can enter Subject Alternative Names in the Attributes box of the Web Enrollment wizard.
  • For public Certificate Authorities, you purchase a UCC certificate or purchase a certificate option, that lets you type in additional names.

To create a key pair on NetScaler

  1. On the left, expand Traffic Management, expand SSL, and click SSL Files.
  2. On the right, switch to the Keys tab.
  3. Click Create RSA Key.
  4. In the Key Filename box, enter a new filename (e.g. wildcard.key). Key pair files typically have a .key extension.
  5. In the Key Size field, enter 2048 bits.
  6. Set the PEM Encoding Algorithm drop-down to DES3
  7. Enter a password to encrypt the private key.
  8. Click Create.

To create CSR file

  1. On the right, switch to the CSRs tab.
  2. Click Create Certificate Signing Request (CSR).
  3. In the Request File Name field, enter the name of a new file. CSR files typically have .csr or .txt extension.
  4. In the Key Filename field, click Choose File and select the previously created .key file. It’s probably at the bottom of the list.

  5. If the key file is encrypted, enter the password.
  6. You can optionally change the Digest Method to SHA256.
  7. In the Common Name field, enter the FQDN of the SSL enabled-website. If this is a wildcard certificate, enter * for the left part of the FQDN. This is the field that normally must match what users enter into their browser address bars.
  8. In the Organization Name field, enter your official Organization Name.
  9. Enter IT, or similar, as the Organization Unit.
  10. Enter the City name.
  11. In the State field, enter your state name without abbreviating.
  12. Scroll down and click Create.
  13. Right-click the new .csr file, and click Download.

Get CSR signed by CA, and install certificate on NetScaler

  1. Open the downloaded .csr file with Notepad, and send the contents to your Certificate Authority.
    1. Chrome requires every certificate to have at least one Subject Alternative Name that matches the FQDN entered in Chrome’s address bar. Public CAs will handle this automatically. But for Internal CAs, you typically must specify the Subject Alternative Names manually when signing the certificate.

    2. If the CA asks you for the type of web server, select Apache, or save the CA response as a Base 64 file.
  2. After you get the signed certificate, on the left side of the NetScaler Configuration GUI, expand Traffic Management > SSL > Certificates, and click Server Certificates.
  3. On the right, click Install.
  4. In the Certificate-Key Pair Name field, enter a friendly name for this certificate.
  5. In the Certificate File Name field, click the drop-down next to Choose File, and select Local.
  6. Browse to the Base64 (Apache) .cer file you received from the Certificate Authority.
  7. In the Key File Name field, click the drop-down next to Choose File, and select Appliance.
  8. Select the key file you created earlier, and click Open. It’s probably at the bottom of the list.
  9. If the key file is encrypted, enter the password.
  10. Click Install.
  11. The certificate is now added to the list.
  12. You can now link an intermediate certificate to this SSL certificate, and then bind this SSL certificate to SSL and/or NetScaler Gateway Virtual Servers.
  13. To automatically backup SSL certificates and receive notification when the certificates are about the expire, deploy Citrix NetScaler Management and Analytics. Also see Citrix CTX213342 How to handle certificate expiry on NetScaler.
  14. You can also export the certificate files and use them on a different NetScaler.

Intermediate Certificate

If your Server Certificate is signed by an intermediate Certificate Authority, then you must install the intermediate Certificate Authority’s certificate on the NetScaler. This Intermediate Certificate then must be linked to the Server Certificate.

To get the correct intermediate certificate

  1. Log into Windows, and double-click the signed certificate file.
  2. On the Certification Path tab, double-click the intermediate certificate (e.g. Go Daddy Secure Certificate Authority. It’s the one in the middle).
  3. On the Details tab, click Copy to File.
  4. In the Welcome to the Certificate Export Wizard page, click Next.
  5. In the Export File Format page, select Base-64 encoded, and click Next.
  6. Give it a file name, and click Next.
  7. In the Completing the Certificate Export Wizard page, click Finish.

To import the intermediate certificate

  1. In the NetScaler configuration GUI, expand Traffic Management, expand SSL, expand Certificates, and click CA Certificates.
  2. On the right, click Install.
  3. Name it Intermediate or similar.
  4. Click the arrow next to Choose File, select Local, and browse the Intermediate certificate file.
  5. Click Install.

Link Intermediate Certificate to Server Certificate

  1. Go back to Traffic Management > SSL > Certificates >Server Certificates.
  2. Right-click the server certificate, and click Link.
  3. The previously imported Intermediate certificate should already be selected. Click OK.
  4. You might be tempted to link the Intermediate certificate to a Root certificate. Don’t do this. Root certificates are installed on client machines, not on NetScaler. NetScaler must never send the root certificate to the client device.

Export Certificate Files from NetScaler

You can easily export certificate files from the NetScaler, and import them to a different NetScaler.

  1. Go to Traffic Management > SSL > Certificates > Server Certificates.
  2. Move your mouse over the certificate you want to export, and then click the information icon on the far left.
  3. Note the file names. There could be one or two file names.
  4. On the left, go to Traffic Management > SSL.
  5. On the right, in the right column, click Manage Certificates / Keys / CSRs.
  6. Find the file(s) in the list, right-click it, and click Download.
    1. While it seems like you can download multiple files, actually, it only downloads one at a time.
    2. You might have to increase the number of files shown per page, or go to a different page.
  7. Also download the files for any linked intermediate certificate.
  8. You can now use the downloaded files to install certificates on a different NetScaler.

Default Management Certificate Key Length

To see the key size for the management certificate, right-click the ns-server-certificate (Server Certificate), and then click Details.

If the management certificate key size is less than 2048 bits, simply delete the existing ns-server-certificate certificate files, and reboot. NetScaler will create a new management certificate with 2048-bit keys.

  1. Go to Traffic Management > SSL.
  2. On the right, in the right column, click Manage Certificates / Keys / CSRs.
  3. Highlight any file named ns-* and delete them. This takes several seconds.
  4. Then go to the System node, and reboot.
  5. After a reboot, if you view the Details on the ns-server-certificate, it will be recreated as self-signed, with 2048-bit key size.

Replace Management Certificate

You can replace the default management certificate with a new trusted management certificate.

High Availability – When a management certificate is installed on one node of a High Availability pair, the certificate is synchronized to the other node, and used for the other node’s NSIP. So make sure the management certificate matches the DNS names of both nodes. This is easily doable using a Subject Alternative Name certificate. Here are some names the management certificate should match (note: a wildcard certificate won’t match all of these names):

  • The FQDN for each node’s NSIP. Example: ns01.corp.local and ns02.corp.local
  • The shortnames (left label) for each node’s NSIP. Example: ns01 and ns02
  • The NSIP IP address of each node. Example: 192.168.123.14 and 192.168.123.29
  • If you enabled management access on your SNIPs, add names for the SNIPs:
    • FQDN for the SNIP. Example: ns.corp.local
    • Shortname for the SNIP. Example: ns
    • SNIP IP address. Example: 192.168.123.30

Request Management Certificate

If you are creating a Subject Alternative Name certificate, it’s probably easiest to request a SAN certificate from an internal CA using the MMC Certificates snap-in on a Windows box.:

  1. Open the MMC certificates snap-in by running certlm.msc on a Windows 2012 or newer machine.
  2. Go to Personal, right-click Certificate, expand All Tasks, and click Request New Certificate.
  3. A web server certificate template should let you specify subject information.
  4. In the top half, change the Subject name > Type drop-down to Common Name. Enter a DNS name, and click Add to move it to the right.
  5. In the bottom half, change the Alternative Name > Type drop-down to either DNS or IP address (v4). Type in different names or IPs as detailed earlier, and click Add to move them to the right.

  6. On the Private Key tab, expand Key Options, and make sure Mark private key as exportable is checked.
  7. Then finish Enrolling the certificate.
  8. Export the certificate and Private Key to a .pfx file.

  9. On the NetScaler, if you want to encrypt the private key, then use the Traffic Management > SSL > Import PKCS#12 tool to convert the .pfx to PEM format.

  10. Then follow one of the procedures below to replace the management certificate.

Methods of replacing the Management Certificate

There are two methods of replacing the management certificate:

  • In the NetScaler GUI, right-click ns-server-certificate, and click Update. This automatically updates all of the Internal Services bindings too. This method is intended for dedicated management certificates, not wildcard certificates. Notes:
    • You cannot rename the ns-server-certificate in the NetScaler GUI. It remains as ns-server-certificate.
    • ns-server-certificate cannot be bound to Virtual Servers. So make sure you are replacing it with a dedicated management certificate.
  • Or manually Bind a new management certificate to each of the Internal Services.

Update Certificate Method

The Update Certificate button method is detailed below:

  1. You can’t update the certificate while connected to the NetScaler using https, so make sure you connect using http.
  2. On the left, expand Traffic Management, expand SSL, expand Certificates, and click Server Certificates.
  3. On the right, right-click ns-server-certificate, and click Update.
  4. Check the box next to Click to update the certificate and key.
  5. Click Choose File, and browse to the new management certificate. It could be on the appliance, or it could be on your local machine.
  6. If the PEM private key is encrypted, enter the password.
  7. Check the box next to No Domain Check. Click OK.
  8. Click Yes to update the certificate.
  9. You can now connect to the NetScaler using https protocol. The certificate should be valid, and it should have a 2048 bit key.

Manual Binding Method

The manual Binding to Internal Services method is detailed below:

  1. You can’t update the certificate while connected to the NetScaler using https, so make sure you connect using http.
  2. On the left, expand Traffic Management, expand SSL, expand Certificates, and click Server Certificates.
  3. On the right, use the Install button to install the new management certificate.

  4. Go to Traffic Management > Load Balancing > Services.
  5. On the right, switch to the Internal Services tab.
  6. Right-click one of the services, and click Edit.
  7. Scroll down, and click where it says 1 Server Certificate.
  8. Click Add Binding.
  9. Click where it says Click to select.
  10. Click the radio button next to the new management certificate, and click Select.
  11. Click Bind, and click Close.
  12. Click Close.
  13. If Default SSL Profile is not enabled, then you can modify the SSL Parameters and/or Ciphers on each of these Internal Services.
  14. Repeat for the rest of the internal services. There should be at least 6 services. Additional Internal Services are created for SNIPs with management access enabled, and High Availability.

Force Management SSL

By default, administrators can connect to the NSIP using HTTP or SSL. This section details how to disable HTTP.

  1. Connect to the NSIP using https.
  2. On the left, expand System, expand Network, and click IPs.
  3. On the right, right-click your NetScaler IP, and click Edit.
  4. Near the bottom, check the box next to Secure access only, and then click OK.
  5. If you are connected using http, the page will reload using https.
    set ns ip 10.2.2.126 -gui SECUREONLY
  6. Repeat this procedure on the secondary appliance.
  7. Repeat for any SNIPs that have management access enabled.

Also see:

SSL Certificate – Update

There are two options for updating a certificate:

  • Create or Import a new certificate to NetScaler > Traffic Management > SSL > Certificates > Server Certificates. Then find all of the places the original certificate is bound, and manually replace the original certificate binding with the new certificate. This method is obviously prone to errors.
  • On NetScaler, simply right-click the existing certificate, and click Update. This automatically updates all of the bindings. Much faster and easier.

To update a certificate using the Update method:

  1. Create an updated certificate, and export it as .pfx file (with private key). Don’t install the certificate onto NetScaler yet, but instead, simply have access to the .pfx file.
  2. In NetScaler, navigate to Traffic Management > SSL > Certificates > Server Certificates.
  3. On the right, right-click the certificate you intend to update, and click Update.
  4. Check the box next to Update the certificate and key.
  5. Click Choose File > Local, and browse to the updated .pfx file.
  6. NetScaler will prompt you to specify the .pfx file password.
  7. Click OK. This will automatically update every Virtual Server on which this certificate is bound.
  8. Intermediate certificate – After replacing the certificate, you might have to update the cert link to a new Intermediate certificate.
    1. Right-click the updated certificate, and click Cert Links, to see if it is currently linked to an intermediate certificate.
    2. If not, right-click the updated certificate, and click Link, to link it to an intermediate certificate. If it doesn’t give you an option to link it to, then you’ll first have to install the new intermediate certificate on the NetScaler.

Certificates can also be updated in NetScaler Management and Analytics System.

Certificates can be updated from the CLI by running update ssl certKey MyCert. However, the certificate files must be stored somewhere on the appliance, and already be in PEM format.

↧

NetScaler Gateway 12 – ICA Proxy (StoreFront)

August 19, 2017, 1:25 pm
$
0
0

Navigation

💡 = Recently Updated

Session Profiles

Partly based on Citrix Knowledgebase Article CTX139963 – How to Configure NetScaler Gateway Session Policies for StoreFront

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

  1. On the left, expand NetScaler 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 Receiver Self-Service (not in 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), 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. On the Security tab, check the Override Global box next to Default Authorization Action, and set it to Allow.
    7. On the Published Applications tab, check the Override Global box next to ICA Proxy, and set it to ON.
    8. 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.
    9. 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 Configure Trusted Domains.
    10. For Account Services Address, enter the Base URL for StoreFront. NetScaler needs to be able to resolve this FQDN DNS name.
    11. 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. On the Client Experience tab, Clientless Access should be set to Off. Scroll down.
    3. Plug-in Type should still be set to Java.
    4. Single Sign-on to Web Applications should be enabled.
      • If you need two-factor authentication, the session profile for Receiver for Web needs Credential Index set to PRIMARY. Only the Receiver Self-Service policy needs SECONDARY as detailed earlier.
    5. On the Security tab, the Default Authorization Action should still be Allow.
    6. On the Published Applications page, for the Web Interface Address field, add the path to your Receiver for Web site (e.g. /Citrix/StoreWeb).
    7. 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.
    8. Account Services Address is not needed in this profile but there’s no harm in leaving it.
    9. 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. Click the blue link to Switch to Default Syntax.
    4. In the Expression box, type in the following expression: 
      HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver")
    5. 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 Action 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"

NetScaler Gateway Virtual Server

This section assumes LDAP authentication, with optional RADIUS for two-factor.

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

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

  1. Create a Server Certificate for the NetScaler Gateway Virtual Server. The certificate must match the name users will enter to access the NetScaler Gateway.
    • For email discovery in Citrix Receiver, 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. On the left, right-click NetScaler Gateway, and click Enable Feature.
  3. On the left, expand NetScaler Gateway, and click Virtual Servers.
  4. On the right, click Add.
  5. Name it gateway.corp.com or similar.
  6. Enter a new VIP that will be exposed to the Internet (typically through NAT).
  7. Click More.
    1. If you don’t have enough NetScaler 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 NetScaler Editions come with built-in Universal Licenses.
    2. Note: it’s also possible to disable authentication on Gateway and make StoreFront do it instead as described in Citrix CTX200066 How to Log On to StoreFront When Authentication is Disabled on NetScaler Gateway VIP. However, it’s more secure to require Gateway to authenticate the users before the user can communicate with StoreFront.
    3. Check the box next to DTLS.
      • DTLS enables EDT protocol, UDP Audio, and Framehawk.
      • EDT requires UDP 443 on client side, and UDP 1494/2598 on the server side.
    4. Click OK to close the Basic Settings section.
  8. In the Certificates section, click where it says No Server Certificate.
    1. Click where it says Click to select.
    2. Click the radio button next to a previously created certificate that matches the NetScaler Gateway DNS name, and click Select.
    3. Click Bind.
  9. Click Continue to close the Certificates section.
  10. In the Basic Authentication section, click the plus icon in the top right. Note: NetScaler Gateway 12 seems 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 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, you will need to bind two Basic authentication policies to Primary and two Basic authentication polices to Secondary:
      • 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)
  11. Click Continue to close the Basic Authentication section.
  12. In the Advanced Authentication section, click Continue.
  13. Scroll down to the Profiles section, and click the pencil icon.
  14. In the TCP Profile drop-down, select nstcp_default_XA_XD_profile, and click OK to close the Profiles section.
  15. 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 Select. It doesn’t matter in which order you bind them.
    4. There’s no need to change the priority number. Click Bind.
  16. 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.
  17. To bind STAs, on the right, in the Advanced Settings section, click Published Applications.
  18. 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.
  19. 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.
  20. On the right, in the Advanced Settings column, click Portal Themes.
  21. On the left, in the Portal Theme section, change the drop-down to RfWebUI. You can also click the plus icon to create a theme.
  22. Click OK to close the Portal Theme section.
  23. 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.
  24. Click Done when done.
  25. Configure SSL Redirect for the NetScaler Gateway DNS name and VIP.
  26. Configure StoreFront to use NetScaler Gateway.

The CLI commands to create a NetScaler 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 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

Verify SSL Settings

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

  1. 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 NetScaler, or you can download and install it on any machine.
  2. 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 – 2016 update.

View ICA Connections

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

show vpn icaconnection

Related Pages

↧
↧

Domain Controller (LDAPS) Load Balancing – NetScaler 12

August 20, 2017, 7:44 am
$
0
0

Navigation

💡 = Recently Updated

Overview

If you plan to use LDAP (Active Directory) for NetScaler Gateway, or NetScaler 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, NetScaler 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 CTX217712 How to Force scriptable monitor to use SNIP in Netscaler in 10.5.

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 NetScaler, 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 NetScaler and bound to the Load Balancing Virtual Server. SSL is terminated at the NetScaler and re-encrypted before sending it to the destination Domain Controller. The primary benefit of NetScaler SSL termination is that your LDAP clients can verify the Virtual Server SSL certificate.

Source IP – When NetScaler uses a local (same appliance) load balanced Virtual Server for LDAPS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a Domain Controller without going through a local Load Balancing Virtual Server, or if NetScaler uses a remote (different appliance) Load Balancing VIP, then the traffic is sourced from the NetScaler 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 CTX217712 How to Force scriptable monitor to use SNIP in Netscaler in 10.5.

  1. In the NetScaler 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 NetScaler 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 AD01 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. Click where it says Click to select.
    2. Click the radio button next to the LDAPS monitor you created earlier, and click Select.
    3. 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.
      • 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 radio button next to a previously created Service Group, and click Select.
    3. 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 radio button next to a certificate that matches the FQDN that resolves to this VIP. Click Select.
    3. 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

Next Steps

You may now use this Virtual IP in your LDAP authentication policies for NetScaler Gateway or NetScaler management login.

↧

NetScaler Gateway 12 – LDAP Authentication

August 20, 2017, 10:23 am
$
0
0

Navigation

💡 = Recently Updated

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.

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.

LDAP Authentication Server

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

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, in the Base DN field, enter your Active Directory DNS domain name in LDAP format.
  9. In the Administrator Bind DN field, enter the credentials of the LDAP bind account in userPrincipalName format. Domain\Username also works.
  10. Enter the Administrator Password.
  11. Click Test Connection. NetScaler will attempt to login to the LDAP IP. Scroll down.
  12. In the Other Settings section, use the drop-down next to Server Logon Name Attribute, Group Attribute, and Sub Attribute Name to select the default fields for Active Directory.
  13. On the right side of the Other Settings section, check the box next to Allow Password Change.
    • Note: there is a checkbox for Validate LDAP Server Certificate. If you want to do this, see Citrix Discussions for instructions for loading the root certificate to /nsconfig/truststore.
  14. If you want to restrict NetScaler 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 NetScaler, in the Search Filter field, type in memberOf= and then paste the Distinguished Name right after the equals sign. Don’t worry about spaces.
  15. Scroll down, and click More.
  16. 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.
  17. 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
  18. 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 NetScaler Gateway vServer.

To create it now:

  1. You can use the menu Search box to find one of the nodes that lets you create Basic Authentication Policies.
    1. Or, navigate to NetScaler 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.
    • NetScaler Gateway 12 does not support Advanced Authentication policies directly on the Gateway vServer. 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 deprecation, click OK and ignore it.

Gateway Authentication Feedback

  1. On the left, under NetScaler Gateway, click Global Settings.
  2. On the right, in the right column, click Change authentication AAA settings.
  3. If desired, check the box for Enable Enhanced Authentication Feedback. This feature provides a message to users if authentication fails. The message 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 NetScaler Gateway, you create multiple LDAP authentication policies, one for each Active Directory domain, and bind all of the LDAP policies to the NetScaler Gateway Virtual Server. When the user logs into NetScaler Gateway, only the username and password are entered. The NetScaler 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 NetScaler 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 NetScaler 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, set 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. The samAccountName policies would be searched in priority order, and the userPrincipalName policies can be used to override the search order. Bind the userPrincipalName policies higher (lower priority number) than the samAccountName policies.

NetScaler 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 for Receivers. 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.
User-added image

Another option for a domain drop-down is nFactor Authentication for Gateway. This also doesn’t fully work with Receiver Self-service.

After authentication is complete, a Session Policy will be applied that has the StoreFront URL. The NetScaler Gateway will attempt to log into StoreFront using Single Sign-on so the user doesn’t have to login again. When logging into NetScaler 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 NetScaler specify the domain name while logging in to StoreFront?

There are two methods of specifying the domain:

  • AAA Group – Configure multiple session policies with unique Single Sign-on Domains.  Inside the Session Policy is a field called Single Sign-on Domain for specifying the domain name. If there is only one Active Directory domain, then you can use the same Session Policy for all users. However, if there are multiple domains, then you would need multiple Session Policies, one for each Active Directory domain. But as the NetScaler loops through the LDAP policies during authentication, once a successful LDAP policy is found, you need a method of linking an LDAP policy with a Session Policy that has the corresponding SSO Domain. This is typically done using AAA groups. To use this method, see Multiple Domains – AAA Group Method.
  • userPrincipalName – Alternatively, configure the LDAP policy/server to extract the user’s UPN, and then authenticate to StoreFront using UPN. This is the easiest method, but some domains don’t have userPrincipalNames configured correctly.

The userPrincipalName method is detailed below:

  1. In each of your NetScaler 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. NetScaler will pull this attribute from AD, and use it to Single Sign-on the user to StoreFront.
  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 NetScaler Gateway).
  6. On the NetScaler 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 Published Applications tab, make sure Single Sign-on Domain is not configured. Since NetScaler is using the userPrincipalName, there’s no need to specify a domain. 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 NetScaler Gateway > Policies > Authentication > LDAP.
  2. On the right, switch to the Servers tab.
  3. Make sure all domains are in the list. Edit one of the domains.
  4. Scroll down to the Other Settings section,
  5. 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 another domain, and specify a new unique group name. Each domain has a different group name.
  7. Go to NetScaler Gateway > User Administration > AAA Groups.
  8. On the right, click Add.
  9. Name the group so it exactly matches the group name you specified in the LDAP server. Click OK.
  10. On the right, in the Advanced Settings section, add the Policies section.
  11. On the left, in the Policies section, click the Plus icon.
    1. Select Session, and click Continue.
    2. Click the plus icon to create a new policy.
    3. Give the Policy a name that indicates the domain. You will have a separate policy for each domain.
    4. Click the plus icon to create a new profile.
    5. Give the Profile a name that indicates the domain. You will have a separate profile for each domain.
    6. Switch to the Published Applications tab.
    7. Check the Override Global box next to Single Sign-on Domain. Enter the domain name that StoreFront is expecting. Click Create.
    8. Give the policy a ns_true expression, and click Create.
    9. In the Priority field, give it a number that is lower than any other Session Policy that has Single Sign-on Domain configured. Click OK.
    10. Click Done.
  12. Create another AAA Group.
  13. Give it a name that matches the Default Authorization Group configured for the next domain.
  14. Create another Session Policy for the next domain.
  15. Create another profile for the next domain. On the Published Applications tab, specify the domain name of the next domain.
  16. Bind the new policy with a low Priority number.
  17. When a user logs in, NetScaler loops through LDAP policies until one of them works. NetScaler adds the user to the Default Authentication Group specified in the LDAP Server. NetScaler 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 policy that also has SSON Domain configured.
↧

NetScaler Gateway 12 Tweaks

August 22, 2017, 5:19 pm
$
0
0

Navigation

💡 = Recently Updated

NetScaler Gateway Feature Licensing

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

Feature NetScaler 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
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 = NetScaler Gateway Enterprise VPX, NetScaler Standard, NetScaler Enterprise, and NetScaler Platinum.

  • NetScaler Gateway Enterprise VPX is the cheap VPX appliance that only does NetScaler Gateway. It doesn’t even do Load Balancing.
  • NetScaler Enterprise Edition is the minimum edition for many Gateway features, and thus is recommended for all Gateway purchases.

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

When you create a NetScaler Gateway Virtual Server, in the Basic Settings section, the ICA Only setting determines if you need NetScaler 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 NetScaler Gateway Universal license for every user that connects to this NetScaler Gateway Virtual Server.

Most editions of NetScaler include Universal licenses:

  • NetScaler Gateway Enterprise VPX does not come with any Gateway Universal Licenses
  • NetScaler Standard Edition comes with 500 Gateway Universal Licenses
  • NetScaler Enterprise Edition comes with 1,000 Gateway Universal Licenses
  • NetScaler Platinum 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:

  • XenApp/XenDesktop Platinum Edition includes Gateway Universal licenses for each licensed user
  • XenMobile App Edition and XenMobile Enterprise Edition include Gateway Universal licenses for each licensed user
  • “a la carte” NetScaler 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.
  2. Then click the third section.

Go to mycitrix.com, 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 NetScaler Gateway Users Allowed field is the number of licensed users for NetScaler 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 NetScaler Gateway Portal Themes, how to edit the Portal Theme CSS, and warns about GUI changes overwriting CSS file changes.

If you want the logon page for NetScaler 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 NetScaler Gateway > Virtual Servers, and edit an existing Virtual Server.
  2. If you see the Portal Themes section on the left:
    • Then click the pencil icon.
  3. If you don’t see Portal Themes 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.
    bind vpn vserver gateway.corp.com -portaltheme RfWebUI
  6. When you access the NetScaler Gateway login page you’ll see the theme.

Custom Portal Theme

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

  1. Go to NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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:
    Logon screen with footer.jpg

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.

Citrix CTX215817 NetScaler : How to Customize Footer of NetScaler Gateway Login Page. This article does not work with the RfWebUI theme, but it works with the X1 theme.

Mike Roselli at Netscaler 11 Theme Customization – How to Add Links and Verbiage at Citrix Discussions has sample rewrite policies to customize the NetScaler 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.

 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 NetScaler Gateway Virtual Server
  • UDP 16500-16509 allowed from NetScaler SNIP to the VDAs

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

  1. Edit a NetScaler 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 Receiver | 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 NetScaler Gateway node.
  2. On the right, click DTLS ICA Connections.
  3. This will show you all users that have UDP Audio connections through NetScaler Gateway. Note: this is different than EDT. To see EDT (UDP) HDX connections, click ICA Connections instead.

Block Citrix VPN for iOS

From Citrix CTX201129 Configuration for Controlled Access to Different VPN Plugin Through NetScaler Gateway for XenMobile Deployments: do one or both of the following to block the Citrix VPN client connection from iOS devices:

  • Create an AppExpert > Responder > Policy with Action = DROP and Expression = HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver/NSGiOSplugin"). 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 iOS is allowed.

StoreFront – Rewrite X-Citrix-Via

When NetScaler 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 NetScaler 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
↧
Search

RADIUS Load Balancing – NetScaler 12

August 23, 2017, 7:46 am
$
0
0

Navigation

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:

  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. Click where it says Click to select.
    3. Click the radio button next to your new RADIUS monitor, and click Select.
    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. 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 radio button next to a previously created Service Group, and click Select.
    3. 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.
    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.

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.
↧
↧

NetScaler Gateway 12 RADIUS Authentication

August 23, 2017, 9:34 am
$
0
0

Navigation

RADIUS 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.

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

NetScaler has two methods of multi-factor:

  • NetScaler Gateway Virtual Server has bind points for Primary and Secondary authentication. This functionality is available in all NetScaler Editions and is detailed in this post.
  • nFactor Authentication supports unlimited factors, but requires NetScaler Enterprise Edition or NetScaler Platinum Edition.

See the NetScaler 12 page for additional authentication mechanisms supported by NetScaler 12. Some require nFactor.

When configuring the NetScaler 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 NetScaler 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 Receiver Self-service (native Receiver on mobile, Windows, and Mac), the authentication policies are swapped:

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

If you need to support two-factor authentication from both web browsers and Receiver Self-Service, 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

Create Two-factor Policies

Create an LDAP Server/Action

See the LDAP post for instructions. Only the server/action is needed. The Policies will be created later.

Create a RADIUS Sever/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 NetScalers as RADIUS clients on the RADIUS server. Click Test Connection.
  7. Scroll down, and click Create.
    add authentication radiusAction RSA -serverIP 10.2.2.210 -serverPort 1812 -radKey Passw0rd

Create Authentication Policies for LDAP and RADIUS

  1. Since you can’t create authentication policies from the authentication dashboard, go to NetScaler Gateway > Policies > Authentication > RADIUS.
  2. On the right, in the Policies tab, click Add.
  3. Name it RSA-ReceiverSelfService or similar.
  4. Select the RADIUS server created earlier.
  5. 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: NetScaler 12 does not natively support Advanced Authentication Policies so you’ll have to create them as Basic Policies (classic expressions).
  6. Click Create.
  7. If you see a warning about deprecation, click OK, and ignore it.
  8. 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

  9. Go to the NetScaler Gateway\Policies\Authentication\LDAP node.
  10. 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 NetScaler 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 NetScaler Gateway object, on the Authentication Settings page, change the Logon type to Domain and security token. This instructs Receiver to properly handle two-factor authentication. If you change this setting after Receiver has already performed discovery, then users might have to remove the Account from Receiver and re-add it.
↧

Global Server Load Balancing (GSLB) – NetScaler 12

August 25, 2017, 9:35 am
$
0
0

Navigation

💡 = Recently Updated

GSLB Planning

GSLB is nothing more than DNS. GSLB is not in the data path. GSLB receives a DNS query, and 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.

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)
  • 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?”. For XenApp/XenDesktop, DFS multi-master replication of user profiles is not supported, so configure “home” sites for users. More information at 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 NetScaler 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 NetScaler’s proprietary Metric Exchange Protocol (MEP), which is used by GSLB to transmit proximity, persistence, and monitoring information.
  3. Import Static Proximity Database – NetScaler 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 NetScaler 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.
  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 NetScaler pairs participating in GSLB should have the same Per-DNS name configuration.

One NetScaler 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 NetScaler appliances, and expose the DNS listener to the Internet. For internal GSLB, configure it on separate internal NetScaler appliances/instances, and create an internal DNS listener.

Each NetScaler appliance only has one DNS table, so if you try to use the same NetScaler 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 NetScaler 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 NetScaler GSLB for citrix.company.com.
    • On public DNS, delegate citrix.company.com to the NetScaler DMZ ADNS services.
  • Internal citrix.company.com:
    • Configure NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler pair:

  • ADNS Listener IP: A NetScaler 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, so Internet-based DNS servers can access it.
    • A single NetScaler appliance can have multiple ADNS listeners – typically one ADNS listener for public, and another ADNS listener for internal.
  • GSLB Site IP / MEP listener IP: A NetScaler IP that will be used for NetScaler-to-NetScaler GSLB communication. This communication is called MEP or Metric Exchange Protocol. MEP transmits the following between GSLB-enabled NetScaler pairs: load balancing metrics, proximity, persistence, and monitoring.
    • GSLB Sites – On NetScaler, you create GSLB Sites. GSLB Sites are the endpoints for the MEP communication. Each NetScaler 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 NetScaler 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 NetScaler 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 NetScaler. 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 has a GSLB Wizard at Traffic Management > GSLB.

However, the wizard is quite finicky (buggy?), and doesn’t really save any time or steps, so it won’t be documented here.

ADNS Listener

  1. At System > Network > IPs, identify a NetScaler-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.
  3. On the left, expand Traffic Management > Load Balancing, and click Services.
  4. On the right, click Add.
  5. 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.
  6. Click OK.
  7. Scroll down, and click Done to close the Load Balancing Service properties.
  8. On the left of the console, expand System, expand Network, and then click IPs.
  9. On the right, you’ll see the SNIP is now marked as the ADNS svc IP.
  10. Repeat the ADNS configuration on the other appliance pair in the other datacenter.
  11. Your NetScaler appliances are now DNS servers.

DNS Security

  1. NetScaler 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. Or you can use the same SNIP, and same public IP, used for ADNS.
  2. Open the firewall rules for Metric Exchange Protocol.
  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 DMZ SNIP.
    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 verify 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.
    • 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.

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.

NetScaler 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.

Import the Built-in Geo database:

  1. In the NetScaler 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/, and open Citrix_NetScaler_InBuilt_GeoIP_DB.csv. To browse to the directory, select var, and then click Open. Repeat for each directory until you reach /var/netscaler/inbuilt_db.
  6. In the Location Format field, if using the built-in database, select netscaler, and click Create.
  7. When you open a GSLB Service, the public IP will be translated to a location.

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. Click Create.
  6. 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, or Responders:

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 on a NetScaler, but NetScaler-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 define active/active or active/passive, not GSLB Services.

GSLB should be configured identically on all NetScaler pairs that are responding to DNS queries. Since you have no control over which NetScaler will receive the DNS query, you must ensure that both NetScaler 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 NetScaler, 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 NetScaler, 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 NetScaler will monitor for reachability.
    3. If the remote IP is owned by a different NetScaler that is reachable by MEP, then enter the actual VIP configured on that remote NetScaler. 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler – If the GSLB Service IP is not hosted on a NetScaler, then only GSLB Service monitors 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.
  10. Active/Active Site Persistence – If you intend to do GSLB active/active, and if you need site persistence, then you can configure your GSLB Services to use 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 NetScaler 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.

Manually Synchronize GSLB Configuration

Copy the GSLB Service Configuration to the remote NetScaler 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 NetScaler pairs that are participating in GSLB.

GSLB Virtual Server

The GSLB Virtual Server is the entity that the DNS name is bound to. GSLB Virtual Server then gives out the IP address of one of the GSLB Services that is bound to it.

For Active/Passive GSLB:

  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 NetScaler pairs participating in GSLB.
  4. Delegate the DNS name to NetScaler ADNS.

For Active/Active GSLB:

  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 NetScaler pairs participating in GSLB.
  3. Delegate the DNS name to NetScaler ADNS.

Configure Active/Passive GSLB

Passive Virtual Server

  1. On the left, expand Traffic Management, expand GLSB, 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 GSLBService Binding.
    1. Click where it says Click to select.
    2. Check the box next to an existing Passive GSLB Service, and click Select.
    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 GLSB Virtual Server.

Active Virtual Server

  1. On the left, expand Traffic Management, expand GLSB, 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 GSLBService 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. 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 identical GSLB Virtual Servers on the other NetScaler appliance pair. Both NetScaler 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 appliances.

Configure Active/Active GSLB

  1. On the left, expand Traffic Management, expand GLSB, 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 GSLBService 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. Change the Choose Method drop-down to Static Proximity or similar. This assumes 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. Change the Persistence drop-down to Source IP.
    2. Enter a Persistence Id.
      1. This ID must match on every NetScaler pair participating in GSLB.
      2. Each active/active GSLB Virtual Server should have a different Persistence ID.
    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 NetScaler appliance pair. Both NetScaler 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 appliances.


GSLB Configuration Synchronization Script

Manual GSLB Synchronization

  1. The 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.
  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 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 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.
  6. The NetScaler ADNS services at both GSLB sites should be giving the same response.
  7. To simulate a failure, if the GSLB Service IP is a NetScaler Traffic Management or Gateway IP, you can disable the Traffic Management or Gateway Virtual Server.
  8. Then the responses should change. Verify on both ADNS services.
  9. Re-enable the traffic 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 host’s 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 NetScaler ADNS:

  • Delegate the individual record. For example, delegate gateway.corp.com to the two NetScaler ADNS services (gslb1.corp.com and gslb2.corp.com).
  • Delegate an entire subzone. For example, delegate the subzone gslb.corp.com to the two NetScaler ADNS services. Then create a CNAME record in the parent DNS zone for gateway.corp.com that is aliased to gateway.gslb.corp.com. When DNS queries make it to NetScaler, they will be for gateway.gslb.corp.com and thus gateway.gslb.corp.com needs to be bound to the GSLB Virtual Server instead of gateway.corp.com. For additional delegations, simply create more CNAME records.

Delegate an individual DNS record

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScaler 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 NetScaler appliances.
  4. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other NetScaler appliance.
  5. If you currently have a host record for the service that you are delegating to GSLB (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. If you run nslookup against your Microsoft DNS server, it will respond with Non-authoritative answer. That’s because it got the response from NetScaler, and not from itself.

Delegate a Sub-zone

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScaler pairs in each data center. 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 NetScaler appliances.
  4. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other NetScaler appliance.
  5. Right-click the parent DNS zone, and click New Delegation.
  6. In the Welcome to the New Delegation Wizard page, click Next.
  7. 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.
  8. In the Name Servers page, click Add.
  9. 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.
  10. Then click Add to add the other GSLB ADNS server.
  11. Once both ADNS servers are added to the list, click Next.
  12. In the Completing the New Delegation Wizard page, click Finish.
  13. The sub-zone delegation is shown in the DNS Manager console.

Each GSLB-enabled DNS name must be CNAMED to GSLB:

  1. In NetScaler, 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 CNAMED 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 NetScaler. Click OK.
  5. Repeat the Domain Binding on the other NetScaler 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 CNAMED DNS name that is delegated to NetScaler. For example, if you delegated gslb.corp.com to NetScaler, 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 NetScaler GSLB.
  12. You can repeat these steps to delegate (CNAME) additional DNS names to NetScaler GSLB.
↧

SmartAccess / SmartControl – NetScaler Gateway 12

August 28, 2017, 1:09 pm
$
0
0

Navigation

💡 = Recently Updated

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 NetScaler Gateway. Decisions are based on NetScaler 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 NetScaler, while SmartAccess requires configuration on both NetScaler, and inside Citrix Studio.
  • SmartControl requires NetScaler Platinum Edition licensing, while SmartAccess is available in all NetScaler Editions.
    • Both features require NetScaler Gateway Universal licenses for every concurrent connection.

Prerequisites

Both SmartAccess and SmartControl have the same prerequisites. You can configure SmartAccess in XenApp/XenDesktop at any time, but it won’t work, until you do the following:

  1. NetScaler appliance license: See Feature Licensing in the Gateway Tweaks post. In summary:
    • SmartAccess is available in all editions of NetScaler appliances.
    • SmartControl is available only in NetScaler Platinum Edition.
  2. NetScaler Gateway Universal Licenses – On the NetScaler, go to System > Licenses, and make sure you have NetScaler Gateway Universal Licenses allocated to the appliance.
    1. Most NetScaler Editions (except NetScaler Gateway Enterprise VPX) come with built-in Gateway Universal licenses: NetScaler Standard Edition = 500 licenses, NetScaler Enterprise Edition = 1,000 licenses, and NetScaler Platinum Edition = unlimited licenses.
    2. Additional NetScaler 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. NetScaler Gateway must have ICA Only unchecked.
    1. On the NetScaler, go to NetScaler 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 NetScaler Gateway to start using Universal licenses, and enables the SmartAccess and SmartControl features.
  4. Enable Trust XML on the XenDesktop Site/Farm:
    1. On a XenApp/XenDesktop 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 NetScaler 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 NetScaler 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, and only from a web browser (not from native Receiver). 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.

EPA Policies

There are two methods of 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 NetScaler 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.

Post-authentication Policies and Profiles are configured at NetScaler 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. Note: In NetScaler 12 build 51, the OPSWAT EPA Editor link does not work correctly. But you can use the OPSWAT EPA Editor on a Preauthentication Policy, and then copy the expression to a Session Policy.
  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.
  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 to VPN only, and does not affect SmartAccess.

EPA Expressions

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

  • Both EPA expression types require the Session Policy to be Classic Syntax. If you see any messages about Classic Syntax being deprecated, ignore those messages.

To configure OPSWAT EPA expressions:

  1. When creating a 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:

To configure the original Client Security expressions:

  1. When creating a Preauthentication Policy or 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. A common configuration is to check for domain membership as detailed at CTX128040 How to Configure a Registry-Based Scan Expression to Look for Domain Membership.

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

  1. Edit a NetScaler 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 Troubleshooting

From Citrix CTX209148 Understanding/Configuring EPA Verbose Logging Feature:

  1. Go to NetScaler 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 NetScaler 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
  • Citrix Policy (user half only) > filters > Access control

In both cases, 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 NetScaler Gateway Virtual Server.
  • Set Access condition or Filter to the name of the NetScaler Gateway Session Policy (or Preauthentication Policy).
  • You can use * as a wildcard in either field.
  • The matching NetScaler Gateway Session Policy typically has an EPA Expression configured in the Policy Rule. 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 NetScaler Gateway to hide the published icons from all NetScaler 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 NetScaler Platinum Edition. If you don’t have Platinum 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, Gateway Universal licenses installed, Callback URL configured at StoreFront, and Trust XML enabled on Delivery Controllers.
  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 NetScaler 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

↧

NetScaler Gateway 12 – RDP Proxy

August 28, 2017, 4:50 pm
$
0
0

Navigation

💡 = Recently Updated

RDP Proxy Overview

NetScaler supports RDP Proxy through NetScaler Gateway. No VPN required. RDP can connect through NetScaler Gateway on port 443.

There are several ways of launching RDP sessions through NetScaler Gateway RDP Proxy:

  • Bookmarks on the Clientless Access portal page.
    • Bookmarks can be defined by the administrator.
    • Or users can add their own RDP bookmarks.
  • After logging in, change the URL in the browser to /rdpproxy/MyRDPServer. MyRDPServer can be IP or DNS.
  • In the RfWebUI Portal Theme, the Bookmark link lets users enter an RDP address, and click Go.

Links:

Requirements

Here are some requirements for RDP Proxy:

  • NetScaler Enterprise Edition or Platinum Edition.
  • NetScaler Gateway Universal Licenses for each user.
    • Most NetScaler Editions come with built-in Gateway Universal licenses: NetScaler Standard Edition = 500 licenses, NetScaler Enterprise Edition = 1000 licenses, and NetScaler Platinum Edition = unlimited licenses. See Feature Licensing in the Gateway Tweaks post.
  • TCP 443 opened to the NetScaler Gateway Virtual Server.
  • TCP 3389 opened from the NetScaler SNIP to the RDP Servers.

Configuration

Enable RDP Proxy Feature

  1. Go to System > Settings, and click Configure Advanced Features.
  2. In the left column, near the bottom, check the box for RDP Proxy, and click OK.

Create RDP Proxy Profile

  1. Expand NetScaler Gateway, expand Policies, and click RDP.
  2. On the right, switch to the Client Profiles tab, and click Add.
    1. Give the RDP Client Profile a name, and configure it as desired. Scroll down.
    2. It is no longer necessary to configure a Pre shared key or RDP Host. Just click Create.
  3. It is no longer necessary to create a RDP Server Profile.

Create RDP Bookmarks

  1. If you want to put RDP bookmarks on the Clientless Access portal page, on the left, expand NetScaler Gateway, expand Resources, and click Bookmarks.
  2. Alternatively, Simon Gottschlag Publish RDP Proxy Link via StoreFront shows how NetScaler Rewrite can insert an RDP Proxy link into a StoreFront web page.
  3. On the right, click Add.
    1. Give the Bookmark a name.
    2. For the URL, enter rdp://MyRDPServer using IP or DNS (FQDN).
    3. Check the box next to Use NetScaler Gateway As a Reverse Proxy,
  4. Click Create.
  5. Create more bookmarks as desired.

Edit a Session Profile

  1. Create or edit a Session Profile.
  2. On the Security tab, set Default Authorization Action to ALLOW. Or you can use Authorization policies to control access.
  3. On the Remote Desktop tab, check Override Global, and select the RDP Client Profile you created earlier.
  4. If you want to use Bookmarks, on the Client Experience tab, set Clientless Access to On.
  5. On the Published Applications tab, make sure ICA Proxy is OFF.
  6. Click OK when done.

Edit NetScaler Gateway Virtual Server

  1. Edit or Create your Gateway Virtual Server.
  2. In the Basic Settings section, click the pencil icon to edit it, and click More to show more settings.
    1. It is no longer necessary to bind a RDP Server Profile. Instead, RDP is proxied through 443 on the Gateway.
    2. Scroll down. Make sure ICA Only is not checked. This means you’ll need NetScaler Gateway Universal licenses for each user that connects through this Gateway.
    3. Click OK to close the Basic Settings section.
  3. Bind a certificate.
  4. Bind authentication policies.
  5. In the Policies section, bind the Session Policy that has the RDP Client Profile configured.


  6. You can bind RDP Bookmarks to either the NetScaler Gateway Virtual Server, or to a AAA group. To bind to the NetScaler Gateway Virtual Server, on the right, in the Advanced Settings section, click Published Applications.
  7. On the left, in the Published Applications section, click where it says No Url.
  8. Bind your Bookmarks.

  9. While editing your Gateway vServer, you can also enable the RfWebUI Portal Theme.

Configure DNS

  1. If you want to connect to RDP servers using DNS, make sure DNS servers are configured on the appliance (Traffic Management > DNS > Name Servers).
  2. If you want to use the short names instead of FQDNs, add a DNS Suffix (Traffic Management > DNS > DNS Suffix).

Use RDP Proxy

  1. Connect to your Gateway and login.
  2. If you configured Bookmarks, if RfWebUI theme, on the Apps tab, click Web and SaaS Apps.
    1. If X1 theme, the bookmarks are on the Web Apps page.
  3. If RfWebUI theme, you can click Details to mark the Bookmark as a Favorite.

  4. Or you can change the address bar to /rdpproxy/MyRDPServer. You can enter an IP address (e.g. rdpproxy/192.168.1.50) or a DNS name (/rdpproxy/myserver).
  5. If you edit the downloaded .rdp file, notice that it’s connecting on port 443.
  6. Then open the downloaded .rdp file.
  7. You can view the currently connected RDP users by going to NetScaler Gateway > Policies > RDP, and on the right, is the Connections tab.

Personal Bookmarks

  1. If using the RfWebUI theme, another way to launch RDP sessions is to click the Bookmark link, enter a destination DNS/IP, check the box next to RDP Link, and click Go.
  2. You can also give the Bookmark a name and Save it.
  3. Then access the saved bookmark from Apps > Personal Bookmarks.

  4. Personal bookmarks are stored in /var/vpn/bookmark on the appliance. You might want to back these up and replicate them to other Gateway appliances participating in GSLB. See NetScaler 11.1 Personal Bookmarks at Citrix Discussions.
  5. The X1 theme has an Add button on the Web Apps page.
  6. But there is no Go button. Instead, you save the Bookmark and launch it from the list.
↧
↧

NetScaler Gateway 12 – SSL VPN

August 29, 2017, 12:41 pm
$
0
0

Navigation

💡 = Recently Updated

Overview

Here’s an overview of the NetScaler Gateway connection process:

  1. Users use SSL/TLS to connect to a NetScaler Gateway Virtual Server (VIP).
  2. NetScaler Gateway prompts the user for authentication.
  3. Once the user is authenticated, NetScaler Gateway uses Session Policies/Profiles to determine what happens next.

NetScaler Gateway 12 supports six different connection methods:

  • ICA Proxy to XenApp/XenDesktop and StoreFront – the client is built into Citrix Receiver
  • SSL VPN – requires installation of NetScaler Gateway plug-in (VPN client)
  • Clientless – browser only, no VPN client, uses rewrite
  • Secure Browse – from MDX-wrapped mobile applications (XenMobile), uses rewrite
  • RDP Proxy – only RDP client is needed
  • PCoIP Proxy – only VMware Horizon Client is needed

You can configure NetScaler Gateway Session Policies/Profiles to only use one of the connection methods. Or NetScaler Gateway can be configured to let users choose between ICA Proxy, Clientless, and SSL VPN connection methods. Here’s a sample Client Choices screen using the RfWebUI theme:

  • The Clientless Access option opens a portal page that has icons from Citrix StoreFront (ICA Proxy), icons for RDP Proxy, icons for PCoIP Proxy, and links to websites.
    • The website links can be proxied through NetScaler. Proxy methods include: clientless rewrite, SSL VPN, and traditional load balancing.
    • NetScaler Gateway can optionally Single Sign-on to the websites.
  •  The Virtual App and Desktop Access option only displays icons from Citrix StoreFront (ICA Proxy). For other types of icons, you’ll need Clientless Access.
  • The Connect with NetScaler Gateway Plug-in option launches the VPN tunnel. After the tunnel is established, a portal page is displayed. This can be the Clientless Access portal, or a user defined website URL (e.g. intranet).

Session Policies/Profiles have several settings that control the behavior seen after authentication:

  • ICA Proxy – ON or OFF
    • If ON, then ICA Proxy is the only connection method allowed, overriding the other connection methods.
    • ICA Proxy does not launch the VPN client. It only needs Citrix Receiver.
    • ICA Proxy shows the Webpage that’s configured in the Web Interface Address field of the Session Profile. This is typically the StoreFront Receiver for Web page, but technically it can be any internal website.
    • If OFF, that doesn’t mean ICA Proxy doesn’t work. You can still send ICA traffic to the NetScaler Gateway Virtual Server, and the NetScaler Gateway Virtual Server will still proxy it to internal VDAs.
    • Setting it to OFF allows the other connection methods to function. For example, Clientless Access can show both NetScaler Gateway Bookmarks and StoreFront published apps. If VPN is launched, then the portal page shown to the user after the tunnel is established can contain the StoreFront published applications.
  • Clientless Access – On, Off, Disabled
    • If On, then Clientless is the only connection method allowed, assuming ICA Proxy is not set to ON. After the user logs in, the user is presented with a portal page that contains a list of Gateway bookmarks and/or StoreFront published icons. The VPN Client is not launched.
    • The Home Page setting in the Session Profile allows you to display an internal website instead of displaying the NetScaler Gateway Portal Page.
    • Bookmarks are configured at NetScaler Gateway > Resources > Bookmarks. You can bind the Bookmarks (Urls) to the NetScaler Gateway Virtual Server, or to AAA Groups.
    • Only Bookmarks configured for Clientless Access will work without a VPN. The internal websites are rewritten so they are proxied through NetScaler Gateway. For example, if the internal website is http://intranet.corp.local, then Gateway rewrites them to https://gateway.corp.com/cvpn/http/internal.corp.local. This causes the web browser to send the HTTP Request to NetScaler Gateway, which then forwards the HTTP Request to the internal web server. No VPN needed.
  • Plug-in Type – Windows/MAC OS X
    • If both Clientless and ICA Proxy are set to Off, then the VPN Client will be downloaded and launched.
    • Once the VPN tunnel is established, the webpage configured in the Home Page setting is displayed. Or the NetScaler Gateway Portal Page (Clientless Access) is displayed if no Home Page is configured. The Bookmarks in the Portal Page can link to internal websites that are only accessible through a VPN tunnel. Or Bookmarks can be configured for Clientless Access.
    • Additional Gateway objects control VPN behavior including: DNS Suffix, Intranet Applications, Intranet IPs, and Authorization Policies.
  • Client Choices – checked or unchecked
    • If Client Choices is checked, then it displays a page containing up to three buttons allowing the user to choose between VPN, Clientless, or StoreFront. The Network Access with the NetScaler Gateway Plug-in (VPN) button is always displayed. The Clientless Access button is displayed if Clientless Access is set to On or Off (not Disabled). The Virtual App and Desktop Access button is displayed if a Web Interface Address is configured.

Here are some characteristics of Session Policies:

  • NetScaler Gateway > Global Settings > Change Global Settings has the same settings as a Session Profile. However, all Session Policies/Profiles override the settings configured in Global Settings. That’s the whole point of the Override Global checkboxes in the Session Profiles.
  • Session Policy Expression – If the Session Policy Expression is true, then the settings contained in the Session Profile are applied.
    • Action = Session Profile – The Session Profile is also sometimes called the Action. That’s because all NetScaler policies follow a standard structure – if the expression evaluates to True, then perform the Action. For Session Policies in particular, the policy Action = Session Profile.
    • EPA – The Session Policy Expression in Classic Syntax could include an Endpoint Analysis (EPA) expression.
  • Default Syntax Expressions vs Classic Syntax Policy Expressions – NetScaler 12 supports Default (Advanced) Syntax Expressions on Session Policies, in addition to the older Classic Syntax.
    • No syntax mixing – All Session Policies bound anywhere must be either Default or Classic. You cannot mix the two types.
    • EPA is Classic only – EPA Scans are only supported in Classic Expressions.
    • AD Group in Default Syntax – Default Syntax allows expressions for AD Group Membership like HTTP.REQ.USER.IS_MEMBER_OF("MyADGroup"). This could eliminate AAA Groups in some circumstances.
  • Policy Bind Points – Session Policies can be bound to three different bind points – NetScaler Gateway Virtual Server, AAA Groups, and AAA User.
    • When bound to a NetScaler Gateway Virtual Server, the Session policy/profile applies to all users that log into that Virtual Server.
    • When bound to a AAA Group, the Session policy/profile only applies to members of the AAA group (Active Directory group or local group)
    • When bound to a AAA User, the Session policy/profile only applies to the AAA user (Active Directory user or local user)
  • Profile Conflicts – Multiple Session Policies/Profiles could apply to a single session. In this case, the Profile settings are merged. But if there’s a conflict (e.g. one Session Profile enables Clientless access, but another Session Profile disables Clientless access), then which one wins?
    • Priority number – When you bind a Session Policy to a bind point, you specify a priority number. This priority number usually defaults to 100.
    • Lowest priority number wins – The Session Policy binding that has the lowest priority number, wins. Session Policies bound with a priority of 80 will win over Session Policies bound with a priority of 100. Remember, for settings that don’t conflict, the two Profiles merge, but for settings that do conflict, the lower priority number policy/profile settings win.
    • Priority and multiple bind points – the bind point location doesn’t matter. If you bind a Session Policy to a AAA Group with a priority of 100, and you also bind a Session Policy to the NetScaler Gateway Virtual Server with a priority of 80, then the conflicting settings in the Session Policy bound to the NetScaler Gateway Virtual Server will win because it has the lower priority number. You might think that AAA-bound policies always override Virtual Server-bound policies, but that is not the case.
  • Global Settings vs Virtual Server Settings – When you bind a Session Policy to a NetScaler Gateway Virtual Server, the settings in the Session Profile only apply to connections through that particular NetScaler Gateway Virtual Server.
    • Settings in NetScaler Gateway > Global Settings > Change Global Settings apply to every Gateway Virtual Server.
    • Settings in AAA Group > Policies > Session Policy/Profile apply to every Gateway Virtual Server.
    • If you want a particular Gateway Virtual Server to override AAA or Global, your only choice is to bind a Session Policy to the Gateway Virtual Server with a lower priority number than the AAA Bind Points.

AAA Groups are a critical component of NetScaler Gateway VPN configuration:

  • Group extraction – Make sure the LDAP Policy/Server is configured to extract to the user’s Active Directory Groups.
  • Create AAA Groups on the NetScaler that match exactly (case sensitive) with the user’s Active Directory Group Name.
    • Default Syntax and AD Groups – An alternative to AAA Groups is to use HTTP.REQ.USER.IS_MEMBER_OF("MyADGroup") Default Syntax expressions. However, Default Syntax does not support Endpoint Analysis. And Default Syntax only applies to Session Policies and Authorization Policies, so you might still need AAA Groups for Bookmarks, Intranet Applications, and Intranet IPs.
  • You can bind policies and other Gateway objects to the AAA Group, and these bindings only affect that particular AAA Group. These bindings include:
  • If the user belongs to multiple AAA Groups, then policies are applied as follows:
    • Session Policies – the settings are merged, unless there’s a conflict. If a conflict, then the policy with the lowest priority number wins.
    • Bookmarks, Intranet Applications, and Authorization Policies are merged.
    • Intranet IPs (IP Pool) are probably random allocation. It’s probably best to make sure a user only belongs to one AAA Group that assigns Intranet IPs.
  • You can also create local AAA Groups that are unrelated to Active Directory groups. There are several ways of getting users into these local AAA groups:
    • Create local AAA Users and assign them to the AAA Group
    • Configure Session Policy/Profile with a Client Security Check String (EPA Scan). If the scan succeeds, users are placed into local Authorization AAA Groups. If the scan fails, then users are placed into a local Quarantine AAA Group, and removed from all other AAA Groups.
    • When users are authenticated with a particular authentication server, the authentication server can be configured to place users into a Default Authentication Group. This lets you apply different Session Policy/Profiles (and other Gateway objects) depending on how the user authenticated.

NetScaler Gateway supports Client Security Expressions (Endpoint Analysis expressions) at three different locations:

  • Preauthentication Policy Expression
    • If the EPA Scan succeeds, then the user is allowed to login.
    • If the EPA Scan fails, then the user is not allowed to login.
    • Preauthentication Policies are bound to NetScaler Gateway Virtual Servers only, and thus applies to all users of that Virtual Server.
  • Session Policy Expression –
    • This type of EPA Scan is configured in the Session Policy Expression, not the Session Profile.
    • If the EPA Scan succeeds, then the settings in the Session Profile are applied to the session.
    • If the EPA Scan fails, then the Session Profile is ignored. Other Session Policies expressions are still evaluated. Remember, Session Policy/Profiles merge, so all applicable Session Policies must be considered.
    • A limitation of this EPA method is that nothing negative happens. Instead, you typically design higher priority number (lower priority) Session Policies with restrictive settings so that if the EPA Scans fail, then users still get something. For example, you can configure your highest priority number Session Policy/Profile with StoreFront (ICA Proxy) only. In the lower priority number Session Policies/Profiles, VPN might be enabled, but only if the EPA scan succeeds. More restrictive Session Profiles usually uncheck Client Choices, and enable Clientless Access or ICA Proxy.
    • This method of EPA Scans is used in SmartAccess and SmartControl configurations.
    • EPA expressions are not supported in Default Syntax, so you’ll need to use Classic Syntax instead.
  • Session Profile > Security tab > Advanced Settings > Client Security Check String
    • If the EPA Scan succeeds, add the user to the listed Authorization AAA Groups.
    • If the EPA Scan fails, add the user to the selected Quarantine Group, and remove the user from all other AAA Groups.
    • If Quarantine Group is not defined, then prevent SSL VPN. Other methods of connecting (Clientless, StoreFront), still work.
  • Assigning EPA scans to Session Policies and Session Profiles is also known as Post-Authentication EPA Scans.
  • If Endpoint Analysis is configured anywhere, then an Endpoint Analysis plug-in is downloaded to the Windows or Mac client.

Prerequisites

Gateway Universal Licenses

Except for ICA Proxy, all NetScaler Gateway connection methods require a NetScaler Gateway Universal License for each concurrent session. Go to System > Licenses and make sure NetScaler Gateway User licenses are installed. Most NetScaler Editions come with built-in licenses.

DNS Name Servers

DNS usually needs to function across the VPN tunnel. Go to Traffic Management > DNS > Name Servers to add DNS servers.

AAA Groups

  1. Edit your LDAP Policy/Server, and make sure Group Extraction is configured. Configure the Group Attribute and the Sub Attribute Name. This causes NetScaler to extract the user’s AD groups when the user logs in using LDAP.
  2. Go to NetScaler Gateway > User Administration > AAA Groups.
  3. On the right, click Add.
  4. Enter a case sensitive group name that matches the group name in Active Directory. Click OK.
  5. On the right, in the Advanced Settings column, you can see the types of objects that can be bound to AAA Groups. These objects are detailed later in this post.

Create Session Profile

To enable SSL VPN: first create the Session Profile. Then create a Session Policy.

You can create multiple Session Policies/Profiles with different settings. Then you can bind these Session Policies to AAA groups and/or NetScaler Gateway Virtual Servers. The Session Profiles are merged, and if conflicts, lower priority bind points win.

To enable SSL VPN in a Session Profile:

  1. On the left, expand NetScaler Gateway, expand Policies, and click Session.
  2. On the right, switch to the Session Profiles tab, and click Add.
  3. Name the profile VPN or similar.
  4. In Session Profiles, every field has an Override Global checkbox to the right of it. If you check this box next to a particular field, then you can configure that field, and the field in this session profile will override settings configured globally (NetScaler Gateway > Global Settings > Change Global Settings), or in a lower priority (higher priority number) session policy.

Network Configuration tab

  1. In the Session Profile, switch to the Network Configuration tab.
  2. You will find a setting that lets you select a DNS Virtual Server. Or if you don’t select anything, then the tunnel will use the DNS servers configured under Traffic Management > DNS > Name Servers.

Client Experience Tab

  1. In the Session Profile, switch to the Client Experience tab. This tab contains most of the NetScaler Gateway VPN settings.
  2. Override Plug-in Type, and set it to Windows/Mac OS X.
  3. On the Client Experience tab, override Split Tunnel and make your choice. Setting it to OFF will force all traffic to use the tunnel. Setting it to ON will require you to create Intranet Applications so the NetScaler Gateway Plug-in will know which traffic goes through the tunnel, and which traffic goes directly out the client NIC (e.g. to the Internet). REVERSE means all traffic goes through the tunnel except for the addresses defined in Intranet Applications.
  4. On the Client Experience tab, there are timers that can be configured. Global Settings contains default timers, so you might want to configure this Session Profile to override the defaults and increase the timeouts. See Configuring Time-Out Settings at Citrix Docs for details.
    1. Client Idle Time-out is a NetScaler Gateway Plug-in timer that disconnects the session if there is no user activity (mouse, keyboard) on the client machine.
    2. Session Time-out is a NetScaler timer that disconnects the session if there is no network activity for this duration.
    3. In addition to these two timers, on the Network Configuration tab, under Advanced Settings…
    4. There’s a Forced Timeout setting.

  5. By default, once the VPN tunnel is established, a portal page appears containing Gateway Bookmarks, and StoreFront published icons. An example of the portal page in the RfWebUI theme is shown below:
    1. The X1 theme is shown below:
  6. On the Client Experience tab, the Home Page field lets you override the the default portal page, and instead display a different webpage (e.g. Intranet). This homepage is displayed after the VPN tunnel is established (or immediately if connecting using Clientless Access).
  7. NetScaler Gateway can automatically start the VPN tunnel whenever the user is remote. On the Client Experience tab, click the plus icon next to AlwaysON Profile Name.
    1. Give the profile name. Hover over the question marks to see what each of them does.
    2. Then click Create.
    3. More info at AlwaysON at Citrix Docs.
  8. Additional VPN settings can be found by clicking Advanced Settings near the bottom of the Client Experience tab.
  9. Under Client Experience > Advanced Settings, on the General tab, there are settings to run a login script at login, enable/disable Split DNS, and enable Local LAN Access. Use the question marks to see what they do.
  10. Note: if Split Tunnel is OFF, and if Split DNS is set to REMOTE, NetScaler only returns one IP address to DNS queries. This behavior can be changed by following Citrix CTX200243 DNS Query Responds with Only One IP to Client PC When Connected Through NetScaler Gateway Full VPN.
  11. Under Client Experience > Advanced Settings, on the General tab, is a checkbox for Client Choices. This lets the user decide if they want VPN, Clientless, or ICA Proxy (StoreFront). Without Client Choices, one of the connection methods will occur automatically, depending on what’s enabled.
  12. An example of Client Choices is shown below:
    1. On the main Client Experience tab, if you enabled Client Choices, you can set Clientless Access to Off to add Clientless to the list of available connection methods in the Client Choices screen. Note: this used to be Allow in NetScaler 11.1 and older.
  13. The Client Experience > Advanced Settings section has additional tabs. A commonly configured tab is Proxy, which allows you to enable a proxy server for VPN users.

Security Tab

  1. Back in the main Session Profile, switch to the Security tab.
  2. Set the default authorization to Allow or Deny. If Deny (recommended), you will need to create authorization policies to allow traffic across the tunnel. You can later create different authorization policies for different groups of users.

Published Applications Tab

  1. On the Published Applications tab, set ICA Proxy to Off. This ensures VPN is used instead of ICA Proxy.
  2. Configure the Web Interface Address to embed StoreFront into the default Clientless Access portal page.
    • Note: for X1 theme, additional iFrame configuration is required on the StoreFront side as detailed below. RfWebUI theme does not need any StoreFront changes.
    • From Michael Krasnove: if you configured the Session Policy to direct users to StoreFront, but aren’t using RfWebUI, then placing the following code in c:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js will cause StoreFront to end the VPN tunnel when the user logs off of StoreFront. 
      var LOGOFF_REDIRECT_URL = 'https://YourGatewayFQDN.com/cgi/logout';
 
// Prevent the default "logoff" screen from being displayed
CTXS.Controllers.LogoffController.prototype._handleLogoffResult = $.noop;
 
CTXS.Extensions.afterWebLogoffComplete = function () {
 window.location.href = LOGOFF_REDIRECT_URL;
};
  3. See the ICA Proxy post for more information on integrating StoreFront with NetScaler Gateway.

Other Tabs

  1. The Remote Desktop tab is detailed in the RDP Proxy post.
  2. The PCoIP tab is detailed in the PCoIP Proxy post.
  3. Click Create when you’re done creating the Session Profile.

Create Session Policy

Once the Session Profile is created, you need a Session Policy linked to it. The Session Policy contains an expression, where if true, then the Session Profile is applied.

If multiple Session Policies apply to a particular connection, then the settings in the policies are merged. For conflicting settings, the Session Policy with the highest priority (lowest priority number) wins. Session Policies bound to AAA groups only override Session Policies bound to NetScaler Gateway Virtual Servers if the AAA group bind point has a lower priority number. In other words, priority numbers are evaluated globally no matter where the Session Policy is bound. You can run the command nsconmsg –d current –g pol_hits to see which Session Policies are applying to a particular connection. See CTX214588 Understanding Session Policy Priority on Different Bind Points.

You can also include Endpoint Analysis expressions in a Session Policy, so that the Session Policy only applies to machines that pass the Endpoint Analysis scan. However, EPA Scans are only supported with Classic Syntax policy expressions, and not with Default Syntax.

To create a Session Policy that is linked to a Session Profile:

  1. On the left, go to NetScaler Gateway > Policies > Session.
  2. In the right pane, switch to the Session Policies tab, and click Add.
  3. Give the policy a descriptive name.
  4. Change the Profile drop-down to the VPN Profile you just created.
  5. The Expression box has an option for switching to Default Syntax.
    1. If Default Syntax, enter true in the Expression box so it always evaluates to true. If Classic Syntax, it would be ns_true instead of true.
    2. If Default Syntax, you can enter HTTP.REQ.USER.IS_MEMBER_OF("MyADGroup") to restrict the Session Profile to members of a specific AD group. In Classic Syntax, this isn’t possible in an expression, and instead you must assign the Session Policy to a AAA Group.
  6. If Classic Syntax, you can add Endpoint Analysis scans to the Expression box. If the Endpoint Analysis scan succeeds, then the session policy is applied. If the Endpoint Analysis scan fails, then this session policy is skipped, and the next one is evaluated. This is how you can allow VPN if EPA scan succeeds, but all failed EPA scans will get a different session policy that only has ICA Proxy enabled.
    1. To add an Endpoint Analysis scan, use one of the Editor links on the right.
    2. Configure OPSWAT scans in the OPSWAT EPA Editor.
    3. Configure Client Security Expressions in the Expression Editor.
    4. You can combine multiple Endpoint Analysis scan expressions using Booleans (&&, ||, !).
  7. Click Create when done.

Bind Session Policy

Most of the NetScaler Gateway configuration objects can be bound to a NetScaler Gateway Virtual Server, AAA Groups, or both. This section details binding of Session Policies, but the other NetScaler Gateway objects (e.g. Authorization Policies) can be bound using similar instructions.

  • Objects bound directly to the NetScaler Gateway Virtual Server are evaluated for every user of that Gateway Virtual Server.
  • Objects bound to a AAA Group are only evaluated for members of that AAA Group.
    • Polices bound to AAA Groups usually have lower priority numbers than policies bound to Gateway Virtual Servers, so the AAA binding can override the Gateway binding.
    • However, objects/policies bound to a AAA Group are applied to every Gateway Virtual Server on the same appliance. To override AAA bindings at a specific Gateway, you can bind lower priority number policies to the Gateway Virtual Server.

Bind the new Session Policy to a NetScaler Gateway Virtual Server, or a AAA group.

To bind to a NetScaler Gateway Virtual Server

  1. Edit a NetScaler Gateway Virtual Server (or create a new one).
  2. To make sure ICA Only is unchecked:
    1. Click the pencil icon for the Basic Settings section.
    2. Click More.
    3. Make sure ICA Only is unchecked, and click OK to close the Basic Settings section.
    4. Note: with this box unchecked, Gateway Universal licenses are now required for all users connecting through this Gateway Virtual Server.
  3. While editing the Gateway Virtual Server, consider changing the Portal Theme to RfWebUI. This changes the default portal page to look identical to StoreFront.
  4. Scroll down to the Policies section, and click the Plus icon.
  5. In the Choose Type page, ensure the Choose Policy drop-down is set to Session.
  6. Ensure the Choose Type drop-down is set to Request, and click Continue.
  7. Click where it says Click to select.
    1. If you already have Session Policies bound to this Gateway Virtual Server, then you might have to click Add Binding first.
  8. Click the radio button next to the previously created Session Policy, and click Select.
  9. Note: you cannot mix Classic Syntax Policies and Default Syntax Policies.
  10. In the Priority field, adjust the priority number. If you want this Session Policy to override other Session Policies, then set the priority number to a low value. See CTX214588 Understanding Session Policy Priority on Different Bind Points.
  11. Click Bind.
  12. If you already have Session Policies bound to the Gateway Virtual Server, then the list of Policies is displayed. If you don’t see this list, on the left, in the Policies section, click the line that says Session Policies.
  13. From this list, you can right-click the policies to Edit Binding (priority number), or Edit Profile.

Bind to AAA Group

  1. To bind to a AAA Group, go to NetScaler Gateway > User Administration > AAA Groups.
  2. On the right, add a AAA group with the same name (case sensitive) as the Active Directory group name. This assumes your LDAP policies/server are configured for group extraction (Group Attribute, and Sub Attribute).
  3. Edit the AAA Group.
  4. On the right, in the Advanced Settings column, add the Policies section.
  5. Click the plus icon to bind one or more Session Policies.
  6. If you want these Session Policies to override the Session Policies bound to the NetScaler Gateway Virtual Server, then make sure the Session Policies bound to the AAA Group have lower priority numbers. See CTX214588 Understanding Session Policy Priority on Different Bind Points.


NetScaler Gateway Plug-in Installation

Here is what the user sees when launching the VPN session for the first time. This assumes the user is an administrator of the local machine.



And then the default portal page is displayed. If using the RfWebUI theme, it might prompt you to install Receiver.

Only administrators can install the NetScaler Gateway Plug-in. You can download the Gateway plug-in from the NetScaler appliance at /var/netscaler/gui/vpns/scripts/vista and push it to corporate-managed machines. Or you can download VPN clients from Citrix.com. The VPN client version must match the NetScaler firmware version.

While a VPN tunnel is established, you can open the Gateway Plug-in to see status. If the Gateway Plug-in is merged with Receiver, right-click Receiver, click Advanced Preferences, click NetScaler Gateway Settings, and click Open.

Or, if the Gateway Plug-in icon is separated from Receiver, then right-click the Gateway Plug-in icon, and click Open.

The hamburger menu on the left lets you see more info about the VPN tunnel.

If the Gateway VPN session isn’t established, you can open the Gateway plug-in, and login. No browser needed.

The Configuration page lets you enable Logging. Then the Logging page lets you collect the logs. See Citrix CTX138155 How to Collect Client VPN Logs for NetScaler Gateway.

VPN Client (NetScaler Gateway Plug-in) Session Profile Settings

Separate Icons for Receiver and Gateway

  1. By default, if Receiver, and NetScaler Gateway Plug-in, are installed on the same machine, then the icons are merged. To see the NetScaler Gateway Plug-in Settings, you right-click Receiver, open Advanced Preferences, and then click NetScaler Gateway Settings. This makes it difficult to log off.

  2. You can configure the Session Profile to prevent the NetScaler Gateway Plug-in from merging with Receiver. Edit your VPN Session Policy/Profile. On the Client Experience tab…
  3. Scroll down, and check the box next to Advanced Settings.
  4. At the bottom of the General tab, check the box next to Show VPN Plugin-in icon with Receiver.
  5. This setting causes the two icons to be displayed separately thus making it easier to access the NetScaler Gateway Plug-in settings, including Logoff.

Cleanup

  1. When the user logs off of VPN, a Cleanup page is displayed. This can be enabled or disabled in a Session Profile on the Client Experience tab.

  2. The cleanup options can be forced in a Session Profile on the Client Experience tab…
  3. Under Advanced Settings > Client Cleanup.

VPN Client Upgrades

  1. Whenever NetScaler firmware is upgraded, all users will be prompted to upgrade their VPN clients. You can edit a Session Policy/Profile, and on the Client Experience tab…
  2. Use the Upgrade drop-downs to disable the automatic upgrade.
  3. The Plugin Upgrade settings are also configurable in the Gateway Virtual Server…
  4. In the Basic Settings > More section.


Authorization Policies

If your Session Profile has Security tab > Default Authorization Action set to Deny (recommended), then create Authorization Policies to allow access across the tunnel.

  1. On the left, under NetScaler Gateway, expand Policies, and click Authorization.
  2. On the right, click Add.
  3. Name the Authorization Policy.
  4. Select Allow or Deny.
  5. For the Expression, NetScaler Gateway 12 supports both Classic Syntax and Default Syntax.
    • Default Syntax gives you much greater flexibility in matching the traffic that should be allowed or denied. Hit Control+Space on your keyboard to begin building a Default Syntax expression. You typically want to identify traffic based on Destination IP Address, Destination Port Number, HTTP Request URL, HTTP Host Header, etc. Common expressions include:
      • CLIENT.IP.DST.IN_SUBNET()
      • CLIENT.TCP.DSTPORT.EQ()
      • You can also use HTTP.REQ.USER.IS_MEMBER_OF("MyADGroup") in your expressions.
    • Note: you cannot mix both Classic Syntax and Default Syntax. You must unbind every Classic Syntax Authorization Policy before you can bind Default Syntax Authorization Policies.
  6. Click Create when done.
  7. Authorization Policies are usually bound to AAA groups. This allows different groups to have different access across the tunnel.
    1. Or, you can use HTTP.REQ.USER.IS_MEMBER_OF("MyADGroup") in your Default Syntax expressions.
  8. Edit a AAA Group at NetScaler Gateway > User Administration > AAA Groups.
  9. On the right, in the Advanced Settings column, add the Authorization Policies section.
  10. Then click where it says No Authorization Policy to bind policies.

Intranet Applications

If you enabled Split Tunnel, then you’ll need to create Intranet Applications to specify which traffic goes through the tunnel.

  1. On the left, under NetScaler Gateway, expand Resources, and click Intranet Applications.
  2. On the right, click Add.
    1. Enter a name for the Internal subnet.
    2. Change the Interception Mode to TRANSPARENT.
    3. Enter an IP subnet. Only packets destined for this network go across the tunnel.
      1. You typically specify a summary address for all internal subnets (e.g. 10.0.0.0/8).
      2. Alternatively, you can define minimal Intranet Application destinations as a security mechanism (assuming Split Tunnel is enabled), but Authorization Policies are more appropriate for that task.
  3. Click Create.
  4. Create additional Intranet applications for each internal subnet.
  5. Intranet Applications are usually bound to the Gateway Virtual Server, but you can also bind them to AAA Groups.
  6. On the right, in the Advanced Settings column, add the Intranet Applications section.
  7. On the left, click No Intranet Application to bind Intranet Applications.

DNS Suffix

Specify a DNS Suffix for Split DNS to function with single label DNS names. NetScaler Gateway adds these DNS suffixes to DNS queries across the VPN tunnel.

  1. On the left, under NetScaler Gateway, expand Resources, and click DNS Suffix.
  2. On the right, click Add.
  3. Enter the DNS Suffix, and click Create. You can add multiple suffixes.

Bookmarks

Bookmarks are the links that are displayed in the default portal interface. They can point to websites, or RDP addresses. PCoIP bookmarks come from VMware Horizon Connection Server. ICA bookmarks come from Citrix StoreFront.

  1. Under NetScaler Gateway, expand Resources, and click Bookmarks.
  2. On the right, click Add.
    1. Give the bookmark a name, and display text.
    2. Enter a website or RDP address.
    3. Optionally browse to an Icon file.
    4. You typically need to check Use NetScaler Gateway As a Reverse Proxy, especially for Clientless Access (rewrite without VPN) to an internal website.
    5. The other fields are for Single Sign-on through Unified Gateway.
  3. Click Create.
  4. Bookmarks (aka Published Applications > Url) are usually bound to AAA groups so different groups can have different bookmarks. But it’s also possible to bind Bookmarks to NetScaler Gateway Virtual Servers.
  5. If NetScaler Gateway Virtual Server, add the Published Applications section to bind Bookmarks (Url).
  6. For AAA Group, it’s the Bookmarks section.
  7. On the left, find the Published Applications section, and click No Url to bind Bookmarks.

VPN Client IP Pools (Intranet IPs)

By default, NetScaler Gateway VPN clients use NetScaler SNIP as their source IP when communicating with internal resources. To support IP Phones or endpoint management, you must instead assign IP addresses to VPN clients.

Any IP pool you add to NetScaler must be reachable from the internal network. Configure a static route on the upstream router. The reply traffic to VPN Client IPs should be routed through a NetScaler SNIP. Or the NetScaler can participate in OSPF.

When a client is assigned a client IP, this IP address persists across multiple sessions until the appliance reboots, or until the appliance runs out of IPs in the pool.

  1. Edit a NetScaler Gateway Virtual Server, or a AAA group.
  2. On the right, in the Advanced Settings section, click the plus icon next to Intranet IP Addresses.
  3. On the left, click where it says No Intranet IP.
  4. Enter a subnet and netmask. Click Bind.
  5. In a Session Profile, on the Network Configuration tab, check the box next to Advanced Settings.
  6. Use the Intranet IP drop-down to configure the behavior when there are more VPN clients than available IPs in the address pool.
    1. If you set it to NOSPILLOVER, then users can only have one VPN session, as described in CTX218066 How to Limit One Session Per User on NetScaler Gateway?.


  7. To see the Client IP address, on the client side, after the tunnel is established, right-click the NetScaler Gateway Plug-in, and click Open.
  8. See the Internal network address.
  9. To see the client IP on the NetScaler, go to NetScaler Gateway, and on the right is Active user sessions.
  10. Select one of the views, and click Continue.
  11. The right column contains the Intranet IP.

StoreFront in Gateway X1 Portal

If you enabled the RfWebUI theme, then no StoreFront configuration is necessary.

But if you want to embed StoreFront in the other Gateway themes (X1, Default, Green Bubble), then follow these instructions.

  1. On StoreFront, edit the file C:\Inetpub\wwwroot\Citrix\StoreWeb\web.config.
    1. On the bottom, there are three sections containing X-Frame-Options. Change all three of them from deny to allow.
    2. Also change frame-ancestors from none to self.
  2. In NetScaler, go to NetScaler Gateway > Global Settings, and click Configure Domains for Clientless Access.
  3. Change the selection to Allow Domains, enter your StoreFront FQDN, and click the plus icon.
  4. Click OK.
  5. In a Session Policy/Profile:
    1. On the Client Experience tab, make sure Single Sign-on to Web Applications is enabled.
    2. On the Published Applications tab, configure the Web Interface Address to point to the StoreFront Receiver for Web page.
    3. Configure the Single Sign-on domain to match what’s configured in StoreFront.
  6. The Applications page of the 3-page portal (e.g. X1 theme) should automatically show the StoreFront published icons.

Quarantine Group

NetScaler Gateway can be configured so that if Endpoint Analysis scans fail, then the user is placed into a Quarantine Group. You can bind session policies, authorization policies, etc. to this quarantine group. Policies bound to other AAA groups are ignored.

  1. Go to NetScaler Gateway > User Administration > AAA Groups.
    1. Add a new local group for your Quarantined Users. This group is local, and does not need to exist in Active Directory.
    2. Bind session policies, authorization policies, etc. to your quarantine AAA group. These policies typically allow limited access to the internal network so users can remediate. Or, it might simply display a webpage telling users how to become compliant.
    3. The Session Policy bound to the Quarantine Group is usually different than the Session Policies bound to other AAA groups. You can use the variation in Session Policy names for SmartAccess.
      1. One option is to configure the Delivery Groups > Access Policy so that icons are shown for Session Policies bound to non-quarantine AAA Groups, but not for the Session Policy that is bound to the Quarantine Group.
      2. Another option is to configure Citrix Policies > Access Control to disable functionality for the Quarantine Group Session Policy, but not for other AAA Group Session Policies.
  2. Create or edit a Session Profile to include a Client Security Expression that checks for compliance.
    1. In the Session Profile, on the Security tab, check the box next to Advanced Settings.
    2. Scroll down, and check the box to the right of Client Security Check String.
    3. Use the Editor links to add an Endpoint Analysis expression.
    4. Just below the Client Security Check String, select the previously created Quarantine Group. If the Client Security Check String EPA Scan fails, then the failed users are added to the Quarantine Group and removed from all other AAA Groups.
  3. Click Create when done creating or editing the Session Profile.
  4. Create a Session Policy for the Session Profile that contains the Client Security Check String.
    1. Enter ns_true as the expression.
    2. Then click Create.
  5. Edit your Gateway Virtual Server, and bind the Session Policy/Profile that has the Client Security Check String configured.


  6. To troubleshoot Quarantine policies, use the command nsconmsg –d current –g pol_hits.
  7. NetScaler MAS Gateway Insight shows users that failed EPA scans, and their quarantine status.

Related Pages

↧

Citrix Director Load Balancing – NetScaler 12

August 29, 2017, 1:47 pm
$
0
0

Navigation

Monitor

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it Director or similar.
  4. Change the Type drop-down to HTTP.
  5. If you will use SSL to communicate with the Director servers, then on the Standard Parameters tab, scroll down, and check the box next to Secure.
  6. Scroll up, and switch to the Special Parameters tab.
  7. In the HTTP Request field, enter GET /Director/LogOn.aspx?cc=true
    1. If Single Sign-on is enabled on Director, then you might have to add 302 as a Response Code.
  8. Scroll down, and click Create.

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 Director server.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding Director servers.

Service Group

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-Director-SSL).
  4. Change the Protocol to HTTP or SSL, depending on if IIS on the Director server is enabled for https or not.
    1. . If the protocol is SSL, ensure the Monitor for Director has Secure enabled, as detailed earlier.
  5. Scroll down, and click OK.

  6. Click where it says No Service Group Member.
    1. Change the selection to Server Based, and select the Director server objects.

    2. Enter 80 or 443 as the port. Then click Create.
  7. Click OK to close the Service Group Members section.
  8. On the right, under Advanced Settings, click Monitors.
  9. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
    1. Click where it says to Click to select.
    2. Click the radio button next to the Director monitor, and click Select.
    3. Then click Bind.
  10. To verify that the monitor is working, on the left, in the Service Group Members section, click the Service Group Members line.
  11. Right-click a member, and click Monitor Details.
  12. The Last Response should be Success – HTTP response code 200 received. Click Close twice.
  13. Then click Done.

Responder

Create a Responder policy to redirect users from the root page to /Director.

  1. Go to AppExpert > Responder, and enable the feature if it isn’t already enabled.
  2. Go to AppExpert > Responder > Actions.
  3. On the right, click Add.
    1. Give the Action a name (e.g. Director_Redirect).
    2. Change the Type to Redirect.
    3. In the Expression box, enter "/Director", including the quotes.
  4. Click Create.
  5. Go to AppExpert > Responder > Policies.
  6. On the right, click Add.
    1. Give the Policy a name (e.g. Director_Redirect).
    2. Select the previously created Action.
    3. In the Expression box, enter HTTP.REQ.URL.PATH.EQ("/")
  7. Click Create.

Load Balancing Virtual Server

  1. Create or install a certificate that will be used by the SSL Virtual Server. This certificate must match the DNS name for the load balanced Director servers.
  2. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  3. On the right, click Add.
  4. Do the following in the Basic Settings section:
    1. Name it lbvip-Director-SSL or similar.
    2. Change the Protocol to SSL.
    3. Specify a new internal VIP.
    4. Enter 443 as the Port.
  5. Click OK to close the Basic Settings section.
  6. On the left, in the Services and Service section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
    1. Click where it says Click to select.
    2. Click the radio button next to your Director Service Group, and click Select.
    3. Click Bind.
  7. Click Continue to close the Services and Service Groups section.
  8. Click where it says No Server Certificate.
    1. Click where it says Click to select.
    2. Click the radio button next to the certificate for this Director Load Balancing Virtual Server, and click Select.
    3. Click Bind.
  9. Click Continue to close the Certificate section.
  10. On the right, in the Advanced Settings column, click Persistence.
  11. On the left, in the Persistence section, do the following:
    1. Change the Persistence drop-down to COOKIEINSERT.
    2. Set the Time-out to 0 minutes. This makes it a session cookie instead of a persistent cookie.
    3. Set the Backup Persistence to SOURCEIP.
    4. Set the Backup Time-out to match the timeout of Director. The default timeout for Director is 245 minutes.
    5. The IPv4 Netmask should default to 32 bits.
  12. Click OK.
  13. On the right, in the Advanced Settings section, add the Policies section.
  14. On the left, in the Policies section, click the plus icon.
    1. Change the Choose Policy drop-down to Responder, and click Continue.
    2. Select the previously created Director_Redirect policy, and click Bind.
  15. If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind a Modern A+ Cipher Group, and enable Strict Transport Security.

SSL Redirect

Do one of the following to configure a redirect from HTTP to HTTPS:

SSL Warning

  1. If you are doing SSL Offload (SSL on front end, HTTP on back end), when connecting to Director, it might complain about “You are not using a secure connection”.
  2. To turn off this warning, login to the Director servers, and run IIS Manager.
  3. On the left, navigate to Server > Sites > Default Web Site > Director.
  4. In the middle, double-click Application Settings.
  5. Change UI.EnableSslCheck to false.

CLI Commands

Here is a list of NetScaler CLI commands for Director Load Balancing:

add server Director01 10.2.2.18
add server Director02 10.2.2.100
add server 127.0.0.1 127.0.0.1
add service AlwaysUp 127.0.0.1 HTTP 80
add serviceGroup svcgrp-Director-HTTP HTTP
add ssl certKey wildcom -cert WildcardCorpCom_pem -key WildcardCorpCom_pem
add lb vserver lbvip-Director-SSL SSL 10.2.2.210 443 -persistenceType SOURCEIP -timeout 245
add lb vserver lbvip-Director-HTTP-SSLRedirect HTTP 10.2.2.210 80 -persistenceType NONE
add responder action Director_Redirect redirect "\"/Director\"" -responseStatusCode 302
add responder action http_to_ssl_redirect_responderact redirect "\"https://\" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE" -responseStatusCode 302
add responder policy Director_Redirect "http.REQ.URL.PATH.EQ(\"/\")" Director_Redirect
add responder policy http_to_ssl_redirect_responderpol HTTP.REQ.IS_VALID http_to_ssl_redirect_responderact
bind lb vserver lbvip-Director-HTTP-SSLRedirect AlwaysUp
bind lb vserver lbvip-Director-SSL svcgrp-Director-SSL
bind lb vserver lbvip-Director-SSL -policyName Director_Redirect -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver lbvip-Director-HTTP-SSLRedirect -policyName http_to_ssl_redirect_responderpol -priority 100 -gotoPriorityExpression END -type REQUEST
add lb monitor Director HTTP -respCode 200 -httpRequest "GET /Director/LogOn.aspx?cc=true" -LRTM DISABLED -secure YES
bind serviceGroup svcgrp-Director-SSL Director01 443
bind serviceGroup svcgrp-Director-SSL Director02 443
bind serviceGroup svcgrp-Director-SSL -monitorName Director
set ssl serviceGroup svcgrp-Director-SSL -tls11 DISABLED -tls12 DISABLED
bind ssl vserver lbvip-Director-SSL -certkeyName wildcom
bind ssl vserver lbvip-Director-SSL -eccCurveName P_256
bind ssl vserver lbvip-Director-SSL -eccCurveName P_384
bind ssl vserver lbvip-Director-SSL -eccCurveName P_224
bind ssl vserver lbvip-Director-SSL -eccCurveName P_521
↧
Search

VMware Horizon Unified Access Gateway Load Balancing – NetScaler 12

August 30, 2017, 5:49 pm
$
0
0

Navigation

Use this procedure to load balance VMware Unified Access Gateway (formerly known as Access Point).

Overview

To simplify this post, this post is focused on Unified Access Gateway, which is the replacement for Horizon Security Servers.

For load balancing of other Horizon components:

  • Internal Horizon Connection Servers – This is standard load balancing on SSL_BRIDGE protocol, port 443, and Source IP persistence. See the CLI commands for a sample configuration.
  • Horizon Security Servers – Detailed configuration for Horizon Security Servers have been removed from this version of the post. But the CLI commands for Security Server load balancing are preserved at the bottom of this post.

UAG appliances vs Horizon Security Servers

There are two VMware-provided remote access solutions for Horizon View:

Unified Access Gateway appliances are preferred over Horizon Security Servers for the following reasons:

  • No need to pair with internal Connection Servers, which simplifies the configuration.
  • Linux appliance instead of Windows server.
  • Authentication can be offloaded to the Unified Access Gateway. This includes: Smart Cards, RSA, and RADIUS.
  • Blast Extreme Adaptive Transport (BEAT) in Horizon 7.1 and newer only works with Unified Access Gateway 2.9 and newer. Security Server and older Access Points don’t work.

Here is a typical Unified Access Gateway architecture:

  • Two Internal Connection Servers – these need to be load balanced on an internal VIP on TCP 443. Internal users connect to the internal VIP.
    • Instructions for load balancing the internal Connection Servers are not detailed in this post. Instead, see the CLI Commands.
  • Two DMZ Unified Access Gateway (Access Point) appliances – these need to be load balanced on a DMZ VIP on several ports. External users connect to the DMZ VIP.
    • Unified Access Gateway appliances connect to the internal Load Balancing VIP for the internal Connection Servers using HTTPS protocol
    • Unified Access Gateway appliances connect directly to Horizon Agents using Blast or PCoIP protocol.

Protocols/Ports

Horizon 7 introduces a new Blast Extreme protocol. VMware Technical White Paper Blast Extreme Display Protocol in Horizon 7.

For VMware Unified Access Gateway (UAG), Blast Extreme only needs TCP 443, and UDP 443. If you use VMware Unified Access Gateway with Blast Extreme exclusively, then the number of ports to UAG is minimal, and load balancing configuration is simplified. Here are typical load balancing port requirements for Unified Access Gateway with Blast Extreme only:

  • TCP 443
  • UDP 443

Note: UDP is disabled by default, but it can be enabled using a Blast GPO setting.

To support Blast Extreme, PCoIP, and HTML Blast connectivity, the following ports must be load balanced to the UAGs:

  • TCP 443
  • UDP 443
  • TCP 4172
  • UDP 4172
  • TCP 8443
  • UDP 8443

The initial connection to UAG is always TCP 443 (HTTPS). If a user is load balanced on port 443 to a particular UAG, then the connection on UDP 4172 must go the same UAG. Normally load balancing persistence only applies to a single port number, so whatever UAG was selected for port 443, won’t be considered for the 4172 connection. But in NetScaler, you can configure a Persistency Group to use a single persistency across multiple load balancing Virtual Servers with different port numbers. In F5, you configure Match Across.

Also see Load Balancing across VMware Unified Access Gateway Appliances by Mark Benson at VMware Communities.

This topic primarily focuses on NetScaler GUI configuration. Alternatively, you can skip directly to the CLI commands.

Load Balancing Monitors

Users connect to Unified Access Gateway appliances on multiple ports: TCP 443, UDP 443, TCP 8443, UDP 8443, TCP 4172, and UDP 4172. Create Load Balancing Monitors for each port number. Since UDP can’t be easily monitored, use TCP monitors as substitutes for UDP. That means you only need three monitors:

  • TCP 443 – HTTPS
  • TCP 4172
  • TCP 8443

SSL (443) Monitor

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it Horizon-SSL or similar.
  4. Change the Type drop-down to HTTP-ECV.
  5. On the Standard Parameters tab, in the Destination Port field, enter 443.
  6. Scroll down the Standard Parameters tab, and check the box next to Secure.
  7. Scroll back up, and switch to the Special Parameters tab.
  8. In the Send String section, enter GET /broker/xml
  9. In the Receive String section, enter clientlaunch-default
  10. Scroll down, and click Create.

PCoIP (4172) Monitor

  1. On the right, click Add.
  2. Name it Horizon-PCoIP or similar.
  3. Change the Type drop-down to TCP.
  4. On the Standard Parameters tab, in the Destination Port field, enter 4172.
  5. Scroll down, and click Create.

Blast (8443) Monitor

  1. On the right, click Add.
  2. Name it Horizon-Blast or similar.
  3. Change the Type drop-down to TCP.
  4. On the Standard Parameters tab, in the Destination Port field, enter 8443.
  5. Scroll down, and click Create.

Load Balancing Servers

Create Load Balancing Server Objects for the DMZ Unified Access Gateway appliances.

  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 appliance name.
  4. Enter the IP address of a Unified Access Gateway appliance.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding Unified Access Gateway appliances.

Load Balancing Services

Overview

Since there are six protocol/ports to UAG, there will be six service groups – one for each protocol/port:

  • TCP 443 – SSL_BRIDGE
  • UDP 443
  • UDP 4172
  • TCP 4172
  • TCP 8443 – SSL_BRIDGE
  • UDP 8443

Users will initially connect to TCP port 443, and then must be redirected to one of the other ports on the same UAG appliance that was initially used for the TCP 443 connection. If TCP 443 is up, but UDP 4172 is down on the same appliance, then you probably TCP 443 to go down too. To facilitate this, bind all three port number monitors to the TCP 443 service. If any of the bound monitors goes down, then TCP 443 is also taken down.

  • Only the TCP 443 service group needs to monitor all port numbers.
  • Other port number service groups only need to monitor that specific port number. For example, the TCP 8443 Service Group should monitor port TCP 8443.
  • Since UDP is difficult to monitor, the UDP Service Groups will monitor the equivalent TCP port. For example, the UDP 4172 Service Group will monitor TCP 4172. This isn’t the best option, but it’s better than ping.

TCP 443 Load Balancing Service Group

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-UAG-SSL).
  4. Change the Protocol to SSL_BRIDGE, and click OK to close the Basic Settings section.
  5. On the left, click where it says No Service Group Member.
    1. Change the selection to Existing Server, and select the Unified Access Gateway appliances you created earlier.

    2. In the Port field, enter 443, and 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. Click where it says Click to select.
    2. Click the radio button next to the Horizon-SSL monitor, and click Select.
    3. Click Bind.
  9. The TCP 443 Service Group should monitor all port numbers. To bind more monitors, on the left, click where it says 1 Service Group to Monitor Binding.
    1. Click Add Binding.
    2. Click where it says Click to select.
    3. Click the radio button next to the Horizon-PCoIP monitor, and click Select.
    4. Then click Bind.
    5. Repeat these steps to bind the Horizon-Blast monitor. If any of these monitors goes down, then the UAG is taken offline.
    6. Click Close.
  10. To verify the monitors, on the left, in the Service Group Members section, click the line that says # Service Group Members.
    1. Right-click one of the members, and click Monitor Details.
    2. The Last Response should indicate Success. If you bound multiple monitors to the Service, then the member will only be UP if all monitors succeed.
    3. Click Close when done.
  11. Then click Done to finish creating the Service Group.

Other Ports Load Balancing Services

Here are general instructions for the other Horizon UAG load balancing service groups.

  1. On the left, go to Traffic Management > Load Balancing > Service Groups.
  2. On the right, click Add.
  3. Name it svcgrp-Horizon-UDP443 or similar.
  4. Change the Protocol to UDP. Click OK.
  5. Click where it says No Service Group Member.
    1. Change the selection to Server Based, and then click Click to select.
    2. Select your multiple Unified Access Gateway appliances, and click Select.
    3. Enter 443 as the Port. Click Create.
  6. Click OK to close the Service Group Members section.
  7. On the right, in the Advanced Settings column, add the Monitors section.
    1. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
    2. Click where it says Click to select.
    3. Select the Horizon-SSL monitor, click Select, and then click Bind.
  8. Click Done to finish creating the Service Group for UDP 443.
  9. Add another Service Group for PCoIP on TCP 4172.
    1. Name = svcgrp-Horizon-PCoIPTCP or similar.
    2. Protocol = TCP
    3. Members = multiple Unified Access Gateway appliances.
    4. Port = 4172.
    5. Monitors = Horizon-PCoIP. You can add the other monitors if desired.
  10. Add another Service Group for PCoIP on UDP 4172.
    1. Name = svcgrp-Horizon-PCoIPUDP or similar.
    2. Protocol = UDP
    3. Members = multiple Unified Access Gateway appliances
    4. Port = 4172.
    5. Monitors = Horizon-PCoIP. You can add the other monitors if desired.
  11. Add another Service Group for SSL_BRIDGE 8443.
    1. Name = svcgrp-Horizon-TCP8443 or similar.
    2. Protocol = SSL_BRIDGE
    3. Members = multiple Unified Access Gateway appliances
    4. Port = 8443.
    5. Monitors = Horizon-Blast. You can add the other monitors if desired.
  12. Add another Service Group for UDP 8443 (Blast Extreme in Horizon 7).
    1. Name = svcgrp-Horizon-UDP8443 or similar.
    2. Protocol = UDP
    3. Members = multiple Unified Access Gateway appliances
    4. Port = 8443.
    5. Monitors = Horizon-Blast. You can add the other monitors if desired.
  13. The six service groups should look something like this:

Load Balancing Virtual Servers

Unified Access Gateway appliances listen on multiple ports so you will need separate load balancers for each port number. Here is a summary of their Virtual Servers, all listening on the same Virtual IP address:

  • Virtual Server on SSL_BRIDGE 443 – bind the SSL_BRIDGE 443 service group.
  • Virtual Server on UDP 443 (Horizon 7) – bind the UDP 443 service group.
  • Virtual Server on UDP 4172 – bind the PCoIP UDP service group.
  • Virtual Server on TCP 4172 – bind the PCoIP TCP service group.
  • Virtual Server on SSL_BRIDGE 8443 – bind the SSL_BRIDGE 8443 service group.
  • Virtual Server on UDP 8443 (Horizon 7) – bind the UDP 8443 service group.

Do the following to create the Virtual Servers:

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section:
    1. Name it lbvip-Horizon-SSL or similar.
    2. Change the Protocol to SSL_BRIDGE.
    3. Specify a new VIP. This one VIP will be used for all of the Virtual Servers.
    4. Enter 443 as the Port.
  4. Click OK to close the Basic Settings section.
  5. On the left, 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 radio button next to the Horizon-SSL Service Group, and click Select.
    3. Click Bind.
  6. Click Continue to close the Services and Service Groups section.
  7. Then click Done to finish creating the Load Balancing Virtual Server. Persistency will be configured later.
  8. Create another Load Balancing Virtual Server for UDP 443. You can right-click the existing Load Balancing Virtual Server, and click Add to copy some settings.
    1. Same VIP as the TCP 443 Load Balancer.
    2. Protocol = UDP, Port = 443
    3. Service Group Binding = the UDP 443 Service Group

  9. Create another Load Balancing Virtual Server for PCoIP UDP 4172:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = UDP, Port = 4172
    3. Service Group Binding = the PCoIP UDP Service Group.

  10. Create another Load Balancing Virtual Server for PCoIP TCP 4172:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = TCP, Port = 4172
    3. Service Group Binding = the PCoIP TCP Service Group

  11. Create another Load Balancing Virtual Server for SSL_BRIDGE 8443:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = SSL_BRIDGE, Port = 8443
    3. Service Group Binding = the TCP 8443 SSL_BRIDGE Service Group

  12. Ceate another Load Balancing Virtual Server for UDP 8443:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = UDP, Port = 8443
    3. Service Group Binding = the UDP 8443 Service Group

  13. This gives you six Virtual Servers on the same VIP, but different protocols and port numbers.

Persistency Group

Users will first connect to SSL_BRIDGE 443, and be load balanced. Subsequent connections to the other port numbers must go to the same load balanced appliance. Create a Persistency Group to facilitate this.

  1. On the left, under Traffic Management, expand Load Balancing, and click Persistency Groups.
  2. On the right, click Add.
  3. Give the Persistency Group a name (e.g. Horizon).
  4. Change the Persistence drop-down to SOURCEIP.
  5. Enter a Time-out that is equal to, or greater than the timeout in Horizon View Administrator, which defaults to 10 hours (600 minutes).
  6. In the Virtual Server Name section, click Add.
  7. Move all six Unified Access Gateway Load Balancing Virtual Servers to the right. Click Create.

Horizon 7 Origin Check

Origin Check might prevent you from connecting to load balanced Connection Servers and/or Unified Access Gateways. You can disable Origin Check as detailed at VMware 2144768 Accessing the Horizon View Administrator page displays a blank error window in Horizon 7.

Load Balancing CLI Commands

Internal Connection Server Load Balancing

add server VCS01 10.2.2.19
add server VCS02 10.2.2.20
add serviceGroup svcgrp-VCS-SSL SSL_BRIDGE
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.5.203 443 -persistenceType SOURCEIP -timeout 600
bind lb vserver lbvip-Horizon-SSL svcgrp-VCS-SSL
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -LRTM DISABLED -destPort 443 -secure YES
bind serviceGroup svcgrp-VCS-SSL VCS01 443
bind serviceGroup svcgrp-VCS-SSL VCS02 443
bind serviceGroup svcgrp-VCS-SSL -monitorName Horizon-SSL

Unified Access Gateway load balancing with Blast Extreme only (no PCoIP)

add server UAG01 10.2.2.187
add server UAG02 10.2.2.24
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -secure YES
add serviceGroup svcgrp-Horizon-SSL SSL_BRIDGE
add serviceGroup svcgrp-Horizon-UDP443 UDP
bind serviceGroup svcgrp-Horizon-SSL UAG01 443
bind serviceGroup svcgrp-Horizon-SSL UAG02 443
bind serviceGroup svcgrp-Horizon-SSL -monitorName Horizon-SSL
bind serviceGroup svcgrp-Horizon-UDP443 UAG01 443
bind serviceGroup svcgrp-Horizon-UDP443 UAG02 443
bind serviceGroup svcgrp-Horizon-UDP443 -monitorName Horizon-SSL
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.2.204 443
add lb vserver lbvip-Horizon-UDP443 UDP 10.2.2.204 443
bind lb vserver lbvip-Horizon-SSL svcgrp-Horizon-SSL
bind lb vserver lbvip-Horizon-UDP443 svcgrp-Horizon-UDP443
bind lb group Horizon lbvip-Horizon-SSL
bind lb group Horizon lbvip-Horizon-UDP443
set lb group Horizon -persistenceType SOURCEIP -timeout 600

Unified Access Gateway load balancing with Blast and PCoIP

add server UAG01 10.2.2.187
add server UAG02 10.2.2.188
add serviceGroup svcgrp-UAG-SSL SSL_BRIDGE
add serviceGroup svcgrp-UAG-UDP443 UDP
add serviceGroup svcgrp-UAG-PCoIPTCP TCP
add serviceGroup svcgrp-UAG-PCoIPUDP UDP
add serviceGroup svcgrp-UAG-TCP8443 SSL_BRIDGE
add serviceGroup svcgrp-UAG-UDP8443 UDP
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.5.204 443
add lb vserver lbvip-Horizon-UDP443 UDP 10.2.5.204 443
add lb vserver lbvip-Horizon-PCoIPUDP UDP 10.2.5.204 4172
add lb vserver lbvip-Horizon-PCoIPTCP TCP 10.2.5.204 4172
add lb vserver lbvip-Horizon-8443SSL SSL_BRIDGE 10.2.5.204 8443
add lb vserver lbvip-Horizon-8443UDP UDP 10.2.5.204 8443
bind lb vserver lbvip-Horizon-SSL svcgrp-UAG-SSL
bind lb vserver lbvip-Horizon-UDP443 svcgrp-UAG-UDP443
bind lb vserver lbvip-Horizon-PCoIPTCP svcgrp-UAG-PCoIPTCP
bind lb vserver lbvip-Horizon-PCoIPUDP svcgrp-UAG-PCoIPUDP
bind lb vserver lbvip-Horizon-8443SSL svcgrp-UAG-TCP8443
bind lb vserver lbvip-Horizon-8443UDP svcgrp-UAG-UDP8443
add lb group Horizon -persistenceType SOURCEIP -timeout 600
bind lb group Horizon lbvip-Horizon-SSL
bind lb group Horizon lbvip-Horizon-UDP443
bind lb group Horizon lbvip-Horizon-PCoIPUDP
bind lb group Horizon lbvip-Horizon-PCoIPTCP
bind lb group Horizon lbvip-Horizon-8443SSL
bind lb group Horizon lbvip-Horizon-8443UDP
set lb group Horizon -persistenceType SOURCEIP -timeout 600
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -LRTM DISABLED -destPort 443 -secure YES
add lb monitor Horizon-PCoIP TCP -LRTM DISABLED -destPort 4172 -secure YES
add lb monitor Horizon-Blast TCP -LRTM DISABLED -destPort 8443 -secure YES
bind serviceGroup svcgrp-UAG-SSL UAG01 443
bind serviceGroup svcgrp-UAG-SSL UAG02 443
bind serviceGroup svcgrp-UAG-SSL -monitorName Horizon-SSL
bind serviceGroup svcgrp-UAG-SSL -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-UAG-SSL -monitorName Horizon-Blast
bind serviceGroup svcgrp-UAG-UDP443 UAG01 443
bind serviceGroup svcgrp-UAG-UDP443 UAG02 443
bind serviceGroup svcgrp-UAG-UDP443 -monitorName Horizon-SSL
bind serviceGroup svcgrp-UAG-PCoIPTCP UAG01 4172
bind serviceGroup svcgrp-UAG-PCoIPTCP UAG02 4172
bind serviceGroup svcgrp-UAG-PCoIPTCP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-UAG-PCoIPUDP UAG01 4172
bind serviceGroup svcgrp-UAG-PCoIPUDP UAG02 4172
bind serviceGroup svcgrp-UAG-PCoIPUDP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-UAG-TCP8443 UAG01 8443
bind serviceGroup svcgrp-UAG-TCP8443 UAG02 8443
bind serviceGroup svcgrp-UAG-TCP8443 -monitorName Horizon-Blast
bind serviceGroup svcgrp-UAG-UDP8443 UAG01 8443
bind serviceGroup svcgrp-UAG-UDP8443 UAG02 8443
bind serviceGroup svcgrp-UAG-UDP8443 -monitorName Horizon-Blast

Horizon Security Server load balancing

add server VSS01 10.2.2.187
add server VSS02 10.2.2.24
add lb monitor Horizon-PCoIP TCP -destPort 4172
add lb monitor Horizon-Blast TCP -destPort 8443
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -secure YES
add lb monitor Horizon-SSL-VCS01 HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -destIP 10.2.2.19 -destPort 443 -secure YES
add lb monitor Horizon-SSL-VCS02 HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -destIP 10.2.2.20 -destPort 443 -secure YES
add service svc-VSS01-SSL VSS01 SSL_BRIDGE 443
add service svc-VSS02-SSL VSS02 SSL_BRIDGE 443
bind service svc-VSS02-SSL -monitorName Horizon-SSL-VCS02
bind service svc-VSS02-SSL -monitorName Horizon-SSL
bind service svc-VSS02-SSL -monitorName Horizon-Blast
bind service svc-VSS02-SSL -monitorName Horizon-PCoIP
bind service svc-VSS01-SSL -monitorName Horizon-SSL-VCS01
bind service svc-VSS01-SSL -monitorName Horizon-Blast
bind service svc-VSS01-SSL -monitorName Horizon-PCoIP
bind service svc-VSS01-SSL -monitorName Horizon-SSL
add serviceGroup svcgrp-Horizon-UDP443 UDP
add serviceGroup svcgrp-Horizon-PCoIPTCP TCP
add serviceGroup svcgrp-Horizon-PCoIPUDP UDP
add serviceGroup svcgrp-Horizon-TCP8443 SSL_BRIDGE
add serviceGroup svcgrp-Horizon-UDP8443 UDP
bind serviceGroup svcgrp-Horizon-UDP443 VSS01 443
bind serviceGroup svcgrp-Horizon-UDP443 VSS02 443
bind serviceGroup svcgrp-Horizon-UDP443 -monitorName Horizon-SSL
bind serviceGroup svcgrp-Horizon-PCoIPTCP VSS01 4172
bind serviceGroup svcgrp-Horizon-PCoIPTCP VSS02 4172
bind serviceGroup svcgrp-Horizon-PCoIPTCP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-Horizon-PCoIPUDP VSS01 4172
bind serviceGroup svcgrp-Horizon-PCoIPUDP VSS02 4172
bind serviceGroup svcgrp-Horizon-PCoIPUDP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-Horizon-TCP8443 VSS01 8443
bind serviceGroup svcgrp-Horizon-TCP8443 VSS02 8443
bind serviceGroup svcgrp-Horizon-TCP8443 -monitorName Horizon-Blast
bind serviceGroup svcgrp-Horizon-UDP8443 VSS01 8443
bind serviceGroup svcgrp-Horizon-UDP8443 VSS02 8443
bind serviceGroup svcgrp-Horizon-UDP8443 -monitorName Horizon-Blast
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.2.204 443
add lb vserver lbvip-Horizon-UDP443 UDP 10.2.2.204 443
add lb vserver lbvip-Horizon-PCoIPUDP UDP 10.2.2.204 4172
add lb vserver lbvip-Horizon-PCoIPTCP TCP 10.2.2.204 1472
add lb vserver lbvip-Horizon-8443TCP SSL_BRIDGE 10.2.2.204 8443
add lb vserver lbvip-Horizon-8443UDP UDP 10.2.2.204 8443
bind lb vserver lbvip-Horizon-SSL svc-VSS01-SSL
bind lb vserver lbvip-Horizon-SSL svc-VSS02-SSL
bind lb vserver lbvip-Horizon-UDP443 svcgrp-Horizon-UDP443
bind lb vserver lbvip-Horizon-PCoIPTCP svcgrp-Horizon-PCoIPTCP
bind lb vserver lbvip-Horizon-PCoIPUDP svcgrp-Horizon-PCoIPUDP
bind lb vserver lbvip-Horizon-8443TCP svcgrp-Horizon-TCP8443
bind lb vserver lbvip-Horizon-8443UDP svcgrp-Horizon-UDP8443
bind lb group Horizon lbvip-Horizon-SSL
bind lb group Horizon lbvip-Horizon-UDP443
bind lb group Horizon lbvip-Horizon-PCoIPUDP
bind lb group Horizon lbvip-Horizon-PCoIPTCP
bind lb group Horizon lbvip-Horizon-8443TCP
bind lb group Horizon lbvip-Horizon-8443UDP
set lb group Horizon -persistenceType SOURCEIP -timeout 600
↧

NetScaler SDX 12

September 3, 2017, 9:00 am
$
0
0

Navigation

Overview

CItrix CTX226732 Introduction to Citrix NetScaler SDX.

NetScaler SDX is normal NetScaler hardware, but runs XenServer hypervisor, and several virtual machines:

  • Service VM (aka Management Service, aka SVM) – every SDX comes with this Virtual Machine. This VM enables the SDX Administrator to create additional VMs on XenServer.
    • It’s not possible to build this VM yourself. If it something happens to it, your only choice is to do a factory reset on the physical appliance, which deletes all local virtual machines, and recreates the Service VM.
    • Each Service VM only manages the VMs on the local SDX. Each SDX has its own Service VM. To manage multiple SDXs, use NetScaler MAS.
    • XenServer on SDX is a special build. Do not attempt to directly upgrade XenServer, patch XenServer, configure XenServer, etc. Instead, all upgrades and configurations should be performed by the Service VM.
  • NetScaler VPX Instances – you create one or more NetScaler instances on top of XenServer
    • The number of NetScaler instances you can create is limited by your SDX license.
    • The physical resources (CPU, Memory, NICs, SSL Chips, FIPS HSM) of the SDX are partitioned to the different instances.
    • The amount of bandwidth (throughput) available to the VPX instances depends on your license. For example, the 14040 SDX license gives you 40 Gbps of throughput, which is partitioned across the instances.
    • The NetScaler instances are created from a normal XenServer .xva template.
    • Each VPX has its own NSIP. Once the VPX is provisioned, you connect to the NSIP, and configure it like a normal NetScaler.

If the top left of the window says SDX, then you are logged into the Management Service (aka Service VM, aka SVM). If it says VPX, then you are logged into an instance.

High Availability – NetScaler SDX does not have any High Availability capability at the XenServer or SVM layer. In other words, every SDX is completely standalone. To achieve HA, you create NetScaler VPX instances on two separate SDXs, and pair the VPX instances in the normal fashion.

Why NetScaler VPX on top of SDX instead of normal hypervisors?

  • VPX on SDX gets physical access to SSL chips. These SSL ASICs are not available on normal hypervisors. SSL Chips provide significantly higher SSL throughput than normal hypervisors.
  • VPX on SDX gets SR-IOV access to the Network interfaces. This enables full 40 Gbps throughput to a single VM.
  • The SDX NICs can filter VLANs to different instances, thus ensuring that VPX instances cannot cross security boundaries by adding the wrong VLANs.
  • Some SDXs have Hardware Security Modules (HSM) for FIPS compliance. The VPXs on SDX can utilize this hardware security resource.

SDX Networking

  • Management port – Every SDX has a 0/1 port. The SVM and XenServer management IP are on this NIC. You need a minimum of two IPs on a management network connected to the 0/1 port. SVM and XenServer cannot use any of the data ports for management.
  • LOM port – Every SDX has a Lights Out Management (LOM) port. This port gives you out-of-band console access to XenServer. Once you’re on XenServer, you can use Xen commands to see the SVM console, and/or VPX consoles.
  • Data ports – The remaining interfaces can be aggregated into port channels. Port channels are configured at XenServer, and not from inside the VPXs. Use the Service VM to create channels, and then connect the VPXs to the channels.
  • VPX networking – When VPXs are created, you specify which physical ports to connect it to.
    • If you want the VPX NSIP to be on the same subnet as SVM and XenServer, then connect the VPX to 0/1.
    • Connect the VPX to one or more LA/x interfaces (port channels).
    • Once the VPX is created, log into it, and create VLAN objects in the normal fashion. VLAN tagging is handled by the VPX, not XenServer.
    • On SVM, when creating the VPX instance, you can specify a list of allowed VLANs. The VPX administrator is only allowed to add VLANs that are in this list.
  • SVM to NSIP – SVM must be able to communicate with every VPX NSIP. If VPX NSIP is on a different subnet than SVM, then ensure that routing/firewall allows this connection.

LOM IP Configuration

There are two ways to set the IP address of the Lights Out Module (LOM):

  • Crossover Ethernet cable from a laptop with an IP address in the 192.168.1.0 network.
  • ipmitool from the NetScaler SDX XenServer command line
    • For MPX, you can run ipmitool from the BSD shell.

Ipmitool Method:

  1. For NetScaler SDX, SSH to the XenServer IP address (this is not the Service VM IP).
    1. For NetScaler MPX, SSH to the NetScaler NSIP.
  2. Default XenServer credentials are root/nsroot.
    1. Default MPX credentials are nsroot/nsroot.
  3. If MPX, run shell. XenServer is already in the shell.
  4. Run the following: 
    ipmitool lan set 1 ipaddr x.x.x.x
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr x.x.x.x

  5. You should now be able to connect to the LOM using a browser.

Laptop method:

  1. Configure a laptop with static IP address 192.168.1.10 and connect it to the Lights Out Module port.
  2. In a Web browser, type the IP address of the LOM port. For initial configuration, type the LOM port’s default address: http://192.168.1.3
  3. In the User Name and Password boxes, type the administrator credentials. The default username and password are nsroot/nsroot.
  4. In the Menu bar, click Configuration, and then click Network.
  5. Under Options, click Network, and type values for the following parameters:
    1. IP Address—The IP address of the LOM port.
    2. Subnet Mask—The mask used to define the subnet of the LOM port.
    3. Default Gateway—The IP address of the router that connects the appliance to the network.
  6. Click Save.
  7. Disconnect the laptop, and instead connect a cable from a switch to the Lights Out Module.

LOM Firmware Upgrade

The LOM firmware at https://www.citrix.com/downloads/netscaler-adc/components/lom-firmware-upgrade differs depending on the hardware platform. The LOM firmware for the 8000 series is different than the 11000 series and the 14000 series. Do not mix them up.

While this article focuses on SDX, note that NetScaler MDX has a new method for updating LOM as detailed at CTX218264 How to Upgrade the LOM Firmware on Any NetScaler MPX Platform

The SDX Update Bundle does not include LOM firmware update so you must update it separately:

  1. Determine which firmware level you are currently running. You can point your browser to the LOM and login to the see the firmware level. Or you can run ipmitool mc info from the XenServer shell.
  2. If your LOM firmware is older than 3.0.2, follow the instructions at http://support.citrix.com/article/CTX137970 to upgrade the firmware.
  3. If your LOM firmware is version 3.02 or later, follow the instructions at http://support.citrix.com/article/CTX140270 to upgrade the firmware. This procedure is shown below.
  4. Now that the firmware is version 3.0.2 or later, you can upgrade to 3.39. Click the Maintenance menu and then click Firmware Update.
  5. On the right, click Enter Update Mode.
  6. Click OK when prompted to enter update mode.
  7. Click Choose File, and browse to the extracted bin file.
  8. After the file is uploaded, click Upload Firmware.
  9. Click Start Upgrade.
  10. The Upgrade progress will be displayed.
  11. After upgrade is complete, click OK to acknowledge the 1 minute message.
  12. The LOM will reboot.
  13. After the reboot, login and notice that the LOM firmware is now 3.39.

SDX IP Configuration

Default IP for Management Service is 192.168.100.1/16 bound to interface 0/1. Use a laptop with crossover cable to reconfigure the IP. Point your browser to http://192.168.100.1. Default login is nsroot/nsroot.

Default IP for XenServer is 192.168.100.2/16. Default login is root/nsroot. Note: XenServer IP and Management Service IP must be on the same subnet.

There should be no need to connect to XenServer directly. Instead, all XenServer configuration (e.g. create new VM) is performed through the Management Service (SVM).

To change the XenServer IP, make the change through the SVM as detailed below:

  1. Point a browser to http://192.168.100.1, and login as nsroot/nsroot.
  2. When you first login to the SDX Management Service, the Welcome! Wizard appears. Click Management Network.
  3. Configure the IP addresses.
    1. Appliance Management IP = SVM (Management Service). This is the IP you’ll normally use to manage SDX.
    2. Application supportability IP = XenServer. You’ll almost never connect to this IP.
    3. The bottom has an Additional DNS checkbox that lets you enter more DNS servers.
    4. You can change the nsroot password at this time, or change it later after LDAP is configured.
  4. Click Done.
  5. Click the System Settings box.
  6. Enter a Host Name.
  7. Select the time zone, and click Continue.
  8. Click the Licenses box.
  9. Click Add New License.
  10. Allocate NetScaler SDX licenses normally.
    1. The SDX license defines the number of instances you can create.
    2. It also defines the amount of throughput available to the instances.
    3. The SDX license is allocated to ANY, which means you can use the same license on all SDX hardware, assuming all of them are purchased with the same license model.
  11. After uploading, click Finish and it should apply automatically.
  12. Or you can click Apply Licenses.
  13. Then click Continue.

Another way to change the Management Service IP address is through the serial port. This is actually the XenServer Dom0 console. Once logged in to XenServer, run ssh 169.254.0.10 to access the Management Service virtual machine. Then follow instructions at http://support.citrix.com/article/CTX130496 to change the IP.

The console of the Management Service virtual machine can be reached by running the following command in the XenServer Dom0 shell (SSH or console):

xe vm-list params=name-label,dom-id name-label="Management Service VM"

Then run /usr/lib64/xen/bin/xenconsole <dom-id>

SDX Platform Software Bundle

If your NetScaler SDX is not version 11 or newer, and if your NetScaler SDX is running 10.5 build 57 or later, then do the following:

  1. Go to Management Service > Software Images, and upload the Single Bundle for 12.0. The single bundle is around 1.3 GB.
  2. On the left, click System. On the right, click Upgrade Management Service. Select the Single Bundle upgrade file you already uploaded.
  3. Management Service will upgrade and reboot. A few minutes after that, XenServer will be upgraded. Be patient as there’s no notification that the box will reboot again.

Starting with SDX 11.0, all updates are bundled together and installed at once.

  1. Make sure your Management Service (SVM) is running SDX 11.0 or newer.
  2. Download the latest SDX Platform Software bundle from Downloads > NetScaler ADC > Release 12.0 > Service Delivery Appliances.

  3. Login to the SDX Management Service, go to Configuration > System.
  4. On the right, in the right column, click Upgrade Appliance.
  5. Browse to the build-sdx-12.0.tgz software bundle, and click OK.
  6. It should show you the estimated installation time. Check boxes next to the instances that need configs saved. Click Upgrade.
  7. Click Yes to continue with the upgrade.
  8. The Management Service displays installation progress.
  9. Once the upgrade is complete, click Login.

  10. If you click the Configuration tab, the Information page will be displayed showing the version of XenServer, Management Service (Build), etc.

DNS Servers

Older versions of SDX only let you enter one DNS server. To add more, do the following:

  1. In the Management Service, on the left, click System.
  2. On the right, click Network Configuration.
  3. On the bottom, there’s a checkbox for Additional DNS that lets you put in more DNS servers.
  4. Click OK when done.

Management Service NTP

  1. On the Configuration tab, in the navigation pane, expand System, and then click NTP Servers.
  2. To add a new NTP server, in the right pane, click Add.
  3. In the Create NTP Server dialog box, enter the NTP server name (e.g. pool.ntp.org), and click Create.
  4. Click Yes when prompted to restart NTP Synchronization.
  5. In the right pane, click NTP Synchronization.
  6. In the NTP Synchronization dialog box, select Enable NTP Sync. Click OK.
  7. Click Yes when asked to restart the Management Service. This only restarts the SVM. Other instances on the same box won’t be affected.

Management Service Alerting

Syslog

  1. On the Configuration tab, expand System > Auditing, and click Syslog Servers.
  2. In the right pane, click the Add button.
    1. Enter a name for the Syslog server.
    2. Enter the IP address of the Syslog server.
    3. Change the Choose Log Level section to Custom, and select log levels.
  3. Click Create.
  4. On the right is Syslog Parameters.
  5. You can configure the Date Format and Time Zone. Click OK.

Mail Notification

  1. On the Configuration tab, expand System > Notifications, and click Email.
  2. In the right pane, on the Email Servers tab, click Add.
  3. Enter the DNS name of the mail server, and click Create.
  4. In the right pane, switch to the Email Distribution List tab, and click Add.
  5. In the Create Email Distribution List page:
    1. Enter a name for the mail profile.
    2. Select the Email Server to use.
    3. Enter the destination email address (distribution list).
  6. Click Create.

System SNMP

  1. Go to System > SNMP.
  2. On the right, click Configure SNMP MIB.
  3. Enter asset information, and click OK. Your SNMP management software will read this information.
  4. Under the SNMP node, configure normal SNMP including: Trap Destinations, Managers, Alarms, etc.

  5. MIBs can be downloaded from the Downloads tab.

Instance SNMP

  1. The instances will send SNMP traps to the Service VM. To get alerted for these traps, in the Configuration page, in the navigation pane, expand NetScaler, expand Events, and click Event Rules.
  2. On the right, click Add.
    1. Give the rule a name.
    2. Select the Major and Critical severities, and move them to the right.
    3. Scroll down.
    4. For the other sections, if you don’t configure anything then you will receive alerts for all of the devices, categories, and failure objects. If you configure any of them, then only the configured entities will be alerted.
    5. Scroll down.
    6. Click Save.
  3. Select an Email Distribution List, and click Done.

Management Service nsroot Password and AAA

Change nsroot password

  1. On the Configuration tab, in the navigation pane, expand System, expand User Administration, and then click Users.
  2. On the right, in the Users pane, right-click the nsroot user account, and then click Edit.
  3. In the Configure System User dialog box, check the box next to Change Password.
  4. In Password and Confirm Password, enter the password of your choice. Click OK.

AAA Authentication

To enable LDAP authentication for the Service VM:

  1. Go to Configuration > System > Authentication > LDAP.
  2. In the right pane, click Add.
  3. This is configured identically to NetScaler.
    1. Enter a Load Balancing VIP for LDAP servers.
    2. Change the Security Type to SSL, and Port to 636.
    3. Scroll down.
    4. Note: if you want to Validate LDAP Certificate, then there are special instructions for installing the root certificate on the SVM. See Installing CA certificates to the SDX/SVM for LDAPS user authentication at Citrix Discussions for details.
    5. Enter the Base DN in LDAP format.
    6. Enter the bind account in UPN format, or Domain\Username format, or DN format.
    7. Check the box for Enable Change Password.
    8. Click Retrieve Attributes, and scroll down.
    9. For Server Logon Attribute, select sAMAccountName.
    10. For Group Attribute, select memberOf.
    11. For Sub Attribute Name, select CN.
    12. To prevent unauthorized users from logging in, configure a Search Filter as detailed in the LDAP post. Scroll down.
  4. Click Create.
  5. Expand System, expand User Administration, and click Groups.
  6. On the right, click Add.
  7. In the Create System Group page:
    1. Enter the case sensitive name of the Active Directory group.
    2. Check the box next to System Access.
    3. Configure the Session Timeout.
  8. Click Create.
  9. On the left, under System, click User Administration.
  10. On the right, click User Lockout Configuration.
    1. If desired, check the box next to Enable User Lockout, and configure the maximum logon attempts. Click OK.
  11. On the left, under System, click Authentication.
  12. On the right, click Authentication Configuration.
    1. Change the Server Type drop-down to EXTERNAL, and click Insert.
    2. Select the LDAP server you created earlier, and click OK.
    3. Make sure Enable fallback is enabled, and click OK.

SSL Certificate and Encryption

Replace SDX Management Service Certificate

To replace the Management Service certificate:

  1. PEM format: The certificate must be in PEM format. The Management Service does not provide any mechanism for converting a PFX file to PEM. You can convert from PFX to PEM by using the Import PKCS#12 task in a NetScaler instance.
  2. On the left, click System.
  3. On the right, in the left column, in the Set Up Appliance section, click Install SSL Certificate.
  4. Select the certificate and key files in PEM format. If the key file is encrypted, enter the password. Then click OK.
  5. The Management Service will restart. Only the SVM restarts; the NetScaler instances do not restart.


Force HTTPS to the Management Service

  1. Connect to the SVM using HTTPS. You can’t make this upcoming change if you are connected using HTTP.
  2. On the Configuration tab, click System.
  3. On the right, click Change System Settings.
  4. Check the box next to Secure Access Only, and click OK. This forces you to use HTTPS to connect to the Management Service.

SSL Encrypt Management Service to NetScaler Communication

From http://support.citrix.com/article/CTX134973: Communication from the Management Service to the NetScaler VPX instances is HTTP by default. If you want to configure HTTPS access for the NetScaler VPX instances, then you have to secure the network traffic between the Management Service and NetScaler VPX instances. If you do not secure the network traffic from the Management Service configuration, then the NetScaler VPX Instance State appears as Out of Service and the Status shows Inventory from instance failed.

  1. Log on to the Management Service .
  2. On the Configuration tab, click System.
  3. On the right, click Change System Settings.
  4. Change the Communication with NetScaler Instance drop-down to https, as shown in the following screen shot:
  5. Run the following command on the NetScaler VPX instance, to change the Management Access (-gui) to SECUREONLY:

set ns ip ipaddress -gui SECUREONLY

Or in the NetScaler instance management GUI, go to Network > IPs, edit the NSIP, and then check the box next to Secure access only.

SDX/XenServer LACP Channels

For an overview of NetScaler SDX networking, see Citrix CTX226732 Introduction to Citrix NetScaler SDX

To use LACP, configure Channels in the Management Service, which creates them in XenServer. Then when provisioning an instance, connect it to the Channel.

  1. In the Management Service, on the Configuration tab, expand System, and click Channels.
  2. On the right, click Add.
  3. In the Create Channel page:
    1. Select a Channel ID.
    2. For Type, select LACP or STATIC. If using Cisco vPC, then LACP is required. The other two options are for switch independent load balancing.
    3. In the Interfaces section, move the Channel Member interfaces to the right by clicking the plus icon.
    4. In the Settings section, for LACP you can select Long or Short, depending on switch configuration. Long is the default.
  4. Click Create when done.
  5. Click Yes when asked to proceed.
  6. The channel will then be created on XenServer.

VPX Instances – Provision

Admin profile

Admin profiles specify the nsroot user credentials for the instances. Management Service uses these nsroot credentials later when communicating with the instances to retrieve configuration data.

The default admin profile for an instance specifies a user name of nsroot, and the password is also nsroot. To specify a different nsroot password, create a new admin profile.

  • You can create a single admin profile that is used by all instances. To delegate administration, don’t give out the nsroot password to the instance administrators. One option is to enable LDAP inside the instance before granting access to a different department.
  • When creating an instance, there’s an option to create a non-nsroot account, which has almost the same permissions as nsroot, but leaves out some SDX specific features (e.g interfaces). This is another option for delegating administration to a different team.
  • Or you can create different admin profiles for different instances, which allows you to inform the different departments the nsroot password for their VPX instances.

Important: Do not change the password directly on the NetScaler VPX instance. If you do so, the instance becomes unreachable from the Management Service. To change a password, first create a new admin profile, and then modify the NetScaler instance, selecting this profile from the Admin Profile list.

  1. On the Configuration tab, in the navigation pane, expand NetScaler, and then click Admin Profiles.
  2. In the Admin Profiles pane, click Add.
  3. In the Create Admin Profile dialog box, set the following parameters:
    • Profile Name*—Name of the admin profile.
    • User Name—User name used to log on to the NetScaler instances. The user name of the default profile is nsroot and cannot be changed.
    • Password*—The password used to log on to the NetScaler instance. Maximum length: 31 characters.
    • Confirm Password*—The password used to log on to the NetScaler instance.
    • Use global settings for NetScaler communication – you can uncheck this box and change the protocol to https.
  4. Click Create. The admin profile you created appears in the Admin Profiles pane.

Upload a NetScaler VPX .xva file

You must upload a NetScaler VPX .xva file to the SDX appliance before provisioning the NetScaler VPX instances. XVA files are only used when creating a new instance. Once the instance is created, use normal firmware upgrade procedures.

  1. Download the NetScaler XVA (for XenServer) from the SDX Software Bundle Download Page. It’s in the Virtual Appliance section.
  2. After downloading, extract the .gz file (use 7-zip). You can’t upload the .gz file to SVM. You must extract it first.
  3. On the Configuration tab, in the navigation pane, expand NetScaler, and then click Software Images.
  4. On the right, switch to the XVA Files tab, and then click Upload.
  5. In the Upload NetScaler Instance XVA dialog box, click Browse, and select the XVA image file that you want to upload. Click Upload.

  6. The XVA image file appears in the XVA Files pane after it is uploaded.

Provision a NetScaler instance

  1. On the SDX Management Service, go to the Dashboard page.
  2. On the bottom right, the System Resource Utilization pane shows you the amount of physical resources that are available for allocation.
  3. On the Configuration tab, in the navigation pane, expand NetScaler, and then click Instances.
  4. In the NetScaler Instances pane, click Add.
  5. In the Provision NetScaler section, enter a name for the instance.
  6. Enter the NSIP, mask, and Gateway.
  7. Nexthop to Management Service – If the instance’s NSIP is on a different subnet than the SVM IP, and if the instance’s default gateway is on a different network than the NSIP, then enter a next hop router address on the NSIP network, so the instance can respond to the SDX Management Service.
  8. In the XVA File field, you can Browse > Local to select an XVA file on your local machine that hasn’t been uploaded to SDX yet. Or you can Browse > Appliance, and select an XVA file that has already been uploaded to SDX.

  9. Select an Admin Profile created earlier. Or you can click the plus icon to create a new Admin Profile.
  10. Enter a Description. Scroll down.
  11. In the License Allocation section, change the Feature License to Platinum.
  12. For Throughput, partition your licensed bandwidth. If you are licensed for 40 Gbps, make sure the total of all VPX instances does not exceed that number.
  13. For Allocation Mode, Burstable is also an option. Fixed bandwidth can’t be shared with other instances. Burstable can be shared. See Bandwidth Metering in NetScaler SDX at Citrix Docs.
  14. In the Resource Allocation section, consider changing the Total Memory to 4096.
  15. For SSL Chips, specify a number. Some SSL/TLS features require at least one chip.
    • NetScaler SDX 8900 series does not use SSL Chips. Instead, it uses Crypto Units. See Crypto Management at Citrix Docs.
  16. For CPU, for production instances, select one of the Dedicated options. Dev/Test instances can use Shared CPU. Then scroll down.
  17. In the Instance Administration section, you can optionally add an instance administrator. Enter a new local account that will be created on the VPX. This instance admin is in addition to the nsroot user. Note, networking functionality is not available to this account. Scroll down.

  18. In the Network Settings section, leave 0/1 selected, and deselect 0/2.
  19. Click Add to connect the VPX to more interfaces.
  20. If you have Port Channels, select one of the LA interfaces.
  21. If you configure any VLAN settings here, then XenServer filters the VLANs available to the VPX instance. Changing the VLAN filtering settings later probably requires a reboot. Click Add. Note: VLAN tagging is configured inside the instance.
  22. In the Management VLAN Settings section, do not configure anything in this section unless you need to tag the NSIP VLAN.
  23. Click Done.
  24. After a couple minutes the instance will be created. Click Close.

  25. If you go to the Dashboard page…
    1. If you click an instance name, you can see how the instance is connected to the physical NICs.
  26. Back in Configuration > NetScaler > Instances, in your Instances list, click the IP address link to launch the VPX management console. Or, simply point your browser to the NSIP and login.
  27. Do the following at a minimum (instructions are in the NetScaler System Configuration post):
    1. Create Policy Based Route for the NSIP – System > Settings > Network > PBRs
    2. Add SNIPs for each VLAN – System > Network > IPs
    3. Add VLANs and bind to SNIPs – System > Network > VLANs
    4. Create Static Routes for internal networks – System > Network > Routes
    5. Change default gateway – System > Network > Routes > 0.0.0.0
    6. Create another instance on a different SDX, and High Availability pair them together – System > High Availability

VPX Instances – Manage

You may login to the VPX instance and configure everything normally. SDX also offers the ability to manage IP addresses, and SSL certificates, from SDX, rather than from inside the VPX instance. The SDX Management Service does not have the ability to create certificates, so it’s probably best to do that from within the VPX instance.

View the console of a NetScaler instance

  1. Connect to the Management Service using https.
    1. Viewing the virtual machine console might not work unless you install a valid certificate for the Management Service.
  2. In the Management Service, go to Configuration > NetScaler > Instances.
  3. On the right, right-click an instance, and click Console.
  4. The instance console then appears.
  5. Another option is to use the Lights Out Module, and the xl console command, as detailed at Citrix Blog Post SDX Remote Console Access of VIs.

Start, stop, delete, or restart a NetScaler instance

  1. On the Configuration tab, in the navigation pane, expand NetScaler, and click Instances.
  2. On the right, in the Instances pane, right-click the NetScaler instance on which you want to perform the operation, and then click Start or Shut Down or Delete or Reboot.
  3. In the Confirm message box, click Yes.

Create a Subnet IP Address on a NetScaler Instance

  1. On the Configuration tab, in the navigation pane, click NetScaler.
  2. On the right, in the NetScaler Configuration pane, click Create IP.
  3. In the Create NetScaler IP dialog box, specify values for the following parameters.
    • IP Address* – Specify the IP address assigned as the SNIP address.
    • Netmask* – Specify the subnet mask associated with the SNIP address.
    • Type* – Specify the type of IP address. Possible values: SNIP.
    • Save Configuration* – Specify whether the configuration should be saved on the NetScaler. Default value is false.
    • Instance IP Address* – Specify the IP address of the NetScaler instance on which this SNIP will be created.
  4. Click Create.

Create a VLAN on a NetScaler instance

  1. Go to NetScaler > Instances.
  2. On the right, right-click an instance, and click VLAN Bindings.
  3. Click Add.
  4. Enter a VLAN ID, and select an interface.
  5. Check the box for Tagged if needed.
  6. Notice there’s no way to bind a SNIP. You do that inside the instance. Click Create.

Save the configuration of a NetScaler instance

  1. On the Configuration tab, in the navigation pane, click NetScaler.
  2. On the right, in the NetScaler pane, click Save Configuration.
  3. In the Save Configuration dialog box, in Instance IP Address, select the IP addresses of the NetScaler instances whose configuration you want to save.
  4. Click OK.

Change NSIP of VPX Instance

The best way to change the NSIP is to edit the instance.

If you change NSIP inside of VPX instead of Editing the Instance in the Management Service, see article CTX139206 How to Change NSIP of VPX Instance in SDX to adjust the XenServer settings.

Enable Call Home

  1. On the Configuration tab, in the navigation pane, click the NetScaler node.
  2. On the right, click Call Home.
  3. Enter an email address to receive communications regarding NetScaler Call Home.
  4. Check the box next to Enable Call Home.
  5. Click Add.
  6. Select the instances to enable Call Home by moving them to the right, and click OK.
  7. You can view the status of Call Home by expanding NetScaler, and clicking Call Home.
  8. The right pane indicates if it’s enabled or not. You can also configure Call Home from here.

VPX Instance – Firmware Upgrade

Upload NetScaler Firmware Build Files

To upgrade a VPX instance from the Management Service, first upload the firmware build file.

  1. Download the NetScaler firmware using the normal method. It’s in the Build section.
  2. On the SDX, in the Configuration tab, on the left, expand NetScaler, and click Software Images.
  3. On the right, in the Software Images tab, click Upload.
  4. Browse to the build…tgz file, and click Open.

Upgrade Multiple NetScaler VPX Instances

You can upgrade multiple instances at the same time:

  1. To prevent any loss of the configuration running on the instance that you want to upgrade, save the configuration on the instance before you upgrade the instance.
  2. On the Configuration tab, in the navigation pane, expand NetScaler, and click Instances.
  3. Right-click an instance, and click Upgrade.
  4. In the Upgrade NetScaler dialog box, in Build File, select the NetScaler upgrade build file of the version you want to upgrade to. Click OK.

Management Service Monitoring

  1. To view syslog, in the navigation pane, expand System, click Auditing, and then click Syslog Message in the right pane.
  2. To view the task log, in the navigation pane, expand Diagnostics, and then click Task Log.
  3. To view Management Service events, on the Configuration tab, in the expand System and click Events.
  4. NetScaler > Entities lets you see the various Load Balancing entities configured on the instances. You might have to click Poll Now to get them to show up.
  5. To view instance alerts, go to NetScaler > Events > All Events.
  6. There is also event reporting.

Management Service Backups

The SDX appliance automatically keeps three backups of the Management Service configuration that are taken daily at 12:30 am.

Backups in NetScaler SDX contain the following:

  • Single bundle image
  • NetScaler XVA image
  • NetScaler upgrade image
  • Management Service image
  • Management Service configuration
  • NetScaler SDX configuration
  • NetScaler configuration

You can go to Management Service > Backup Files to backup or restore the SDX appliance’s configuration. And you can download the backup files.

You can configure the number of retained backups by clicking System on the left, and then clicking Backup Policy in the right pane.

You can even transfer the backup files to an external system.

↧
↧

NetScaler Management and Analytics System (MAS) 12.1

June 10, 2018, 1:20 pm
$
0
0

Navigation

The older 12.0 version of NetScaler MAS is detailed in a different post.

💡 = Recently Updated

Change Log

Planning

Why MAS?

MAS enables every NetScaler administrator to achieve the following:

  • Alert notifications – Receive email alerts whenever something goes down. For example, if a Load Balancing service goes down, you can receive an email alert.
    • MAS can email you for any Major SNMP trap produced by any NetScaler appliance.
  • Automatically backup all NetScaler instances.
    • MAS can even transfer the backups to an external system, which is then backed up by a normal backup tool.
  • SSL Certificate Expiration – Alert you when SSL certificates are about to expire.
    • Show you all SSL certificates across all NetScaler appliances.
  • Configuration Record and Play – Use the Configuration Recorder to configure one NetScaler appliance, and then push out the same configuration changes to additional appliances. This is the easiest method of managing NetScaler appliances in multiple datacenters.
  • AppFlow Reporting – Receive ICA AppFlow traffic from NetScaler and show it in graphs.
    • Integrate MAS with Citrix Director so Help Desk can see the AppFlow data.

Everything listed above is completely free, so there’s no reason not to deploy MAS.

MAS Overview

For an overview of MAS, see Citrix’s YouTube video Citrix NetScaler MAS: Application visibility and control in the cloud.

Cloud vs on-prem

MAS is available both on-premises, and as a Cloud Service. For the Cloud Service, you import a MAS Agent appliance to an on-prem hypervisor, or deploy a MAS Agent to AWS or Azure. The MAS Agent is the broker between the Cloud Service and the on-prem (or cloud hosted) NetScaler appliances. For more info on the MAS Cloud Service, see the following:

The rest of this article focuses on the on-premises version, but much of it also applies to the Cloud Service.

On-premises MAS Licensing:

  • Instance management is free (unlimited). This includes Configuration Jobs, Instance Backups, Network Functions/Reporting. Basically everything in the Networks node is free.
  • Analytics and Application monitoring are free for up to 30 Virtual Servers (Load Balancing, NetScaler Gateway, Content Switching, etc.).
    • Beyond 30 Virtual Servers, licenses can be purchased in 100 Virtual Server packs. See NetScaler MAS Licensing at Citrix Docs.
    • You can control assignment of licenses to Virtual Servers.

MAS version – The version/build of NetScaler MAS must be the same or newer than the version/build of the NetScaler appliances being monitored. MAS 12.1 can monitor 12.0 and older appliances.

HDX Insight

HDX Insight Requirements (aka AppFlow Analytics for Citrix ICA traffic):

  • Your NetScaler appliance must be running Enterprise Edition or Platinum Edition.
  • NetScaler must be 10.1 or newer.
  • HDX Insight works with the following Receivers:
    • Receiver for Windows must be 3.4 or newer.
    • Receiver for Mac must be 11.8 or newer.
    • Receiver for Linux must be 13 or newer.
    • Notice no mobile Receivers. See the Citrix Receiver Feature Matrix for the latest details.
  • For ICA Session Reliability with AppFlow: NetScaler 10.5 build 54 and newer.
    • For ICA Session Reliability, AppFlow, and NetScaler High Availability: NetScaler 11.1 build 49 and newer.
  • AppFlow statistics are only generated when ICA traffic flows through a NetScaler. Internally, when a user clicks an icon from StoreFront, an ICA connection is established directly from Receiver to the VDA, thus bypassing the internal NetScaler. Here are some methods of getting ICA traffic to flow through an internal NetScaler:
  • For ICA round trip time calculations, in a Citrix Policy, enable the following settings:
    • ICA > End User Monitoring > ICA Round Trip Calculation
    • ICA > End User Monitoring > ICA Round Trip Calculation Interval
    • ICA > End User Monitoring > ICA Round Trip Calculation for Idle Connections
  • Citrix CTX215130 HDX Insight Diagnostics and Troubleshooting Guide contains the following contents:
    • Introduction
    • Prerequisites for Configuring HDX Insight
    • Troubleshooting
      • Issues Related to ICA parsing
      • Error Counter details
    • Checklist before Contacting Citrix Technical Support
    • Information to collect before Contacting Citrix Technical support
    • Known Issues

Citrix CTX204274 How ICA RTT is calculated on NetScaler Insight: ICA RTT constitutes the actual application delay. ICA_RTT = 1 + 2 + 3 + 4 +5 +6:

  1. Client OS introduced delay
  2. Client to NS introduced network delay (Wan Latency)
  3. NS introduced delay in processing client to NS traffic (Client Side Device Latency)
  4. NS introduced delay in processing NS to Server (XA/XD) traffic (Server Side Device Latency)
  5. NS to Server network delay (DC Latency)
  6. Server (XA/XD) OS introduced delay (Host Delay)

Multi-Datacenter Deployment Architecture

In a main datacenter, import two NetScaler MAS appliances into the same subnet and configure them as an HA pair with a Floating IP address.

In a DR datacenter, import a MAS appliance, and configure it to replicate with the main datacenter.

For NetScaler appliances in additional datacenters, import two MAS Agent appliances into each datacenter, and configure them as remote agents to the main datacenter. Two MAS Agents per datacenter enables HA. The virtual appliance for MAS Agent is different than the normal MAS appliance.

Import MAS Appliance

To import a MAS Appliance into vSphere, do the following. The same process is used for all types of MAS appliances in all datacenters.

  1. Download NetScaler MAS for ESX, and then extract the .zip file.
  2. In vSphere Web Client, right-click a cluster, and click Deploy OVF Template.
  3. In the Select an OVF Template page, select Local file, and browse to the NetScaler MAS .ovf files. If vCenter 6.5+, select all three files. Click Next.

  4. In the Select name and folder page, enter a name for the virtual machine, and select an inventory folder. Then click Next.
  5. In the Select a resource page, select a cluster or resource pool, and click Next.
  6. In the Review details page, click Next.
  7. In the Select storage page, select a datastore. Due to high IOPS, SSD or Flash is recommended.
  8. Change the virtual disk format to Thin Provision. Click Next.
  9. In the Select networks page, choose a valid port group, and click Finish.
  10. In the Ready to Complete page, click Finish.
  11. Before powering on the appliance, you can review its specs. Right-click the virtual machine, and click Edit Settings.
  12. Review the specs. Citrix Docs VMware ESXi Hardware Requirements has recommended specs.
  13. Citrix Docs How to Attach an Additional Disk to NetScaler MAS says that an additional disk must be added before initial deployment.
    • Use the MAS storage calculator to determine the recommended size of the disk. Ask your Citrix Partner for the tool.
    • The new disk must be larger than 120 GB.
    • In MAS 12.1, the new disk can be larger than 2 TB.
    • In MAS 12.1, the new disk can be grown later, and /mps/DiskPartitionTool.py can resize the partition, but only up to 2 TB. If you need more than 2 TB, the initial disk should be larger than 2 TB.
  14. Power on the Virtual Machine.

Appliance IP Address Configuration

  1. Open the console of the virtual machine.
  2. Configure an IP address.
  3. Enter 7 when done.

Second Disk

  1. Login as nsrecover/nsroot.
  2. Enter /mps/DiskPartitionTool.py
  3. Enter info to see that there are no existing partitions on the second disk.
  4. Enter create to create partitions on the second disk. A reboot is required.
  5. During the reboot, the database is moved to the second disk.
  6. After the reboot, the Disk Partition Tool info command shows the partition on the second disk.
  7. If you need to increase the size of the disk, reboot the MAS appliance so it detects the larger size. Then use the Disk Partition Tool resize command.

Deployment Modes

HA Pair in the Main Datacenter

First Node:

  1. Login as nsrecover/nsroot.
  2. Enter deployment_type.py.
  3. Enter 1 for NetScaler MAS Server.
  4. Enter no when prompted for NetScaler MAS Standalone deployment.
  5. For the First Server Node prompt, enter yes.
  6. Enter yes to Restart the system.

Second Node:

  1. Import another MAS appliance to the same subnet, and configure an IP address.
  2. If you added a second disk to the first MAS appliance, then you must add the same size second disk to the second MAS appliance.
  3. After configuring the new nodes’ IP address, login as nsrecover/nsroot.
  4. Enter deployment_type.py.
  5. Enter 1 for NetScaler MAS Server.
  6. Enter no when prompted for NetScaler MAS Standalone deployment.
  7. Enter no when prompted for First Server Node.
  8. Enter the IP address of the first MAS node.
  9. Enter the nsroot password of the first node. The default password is nsroot.
  10. Enter a new Floating IP address.
  11. Enter yes to restart the system.

Deploy HA Configuration:

  1. Point your browser to the first appliance’s IP address, and login as nsroot/nsroot.
  2. If you see CUXIP, either Skip or Enable the Customer User Experience Improvement Program.
  3. Click Get Started
  4. Select Two servers deployed in High Availability Mode, and click Next.
  5. You should see both nodes. At the top right, click the Deploy button.
  6. Click Yes when prompted to restart.
  7. After deployment, you can now use the Floating IP to manage the appliance.
  8. System > Deployment lets you see the HA nodes. Note: HA failover only occurs after three minutes of no heartbeats.
  9. On the top right is a HA Settings button that lets you change the Floating IP.

DR Node

  1. The main datacenter must have an HA pair of MAS appliances. Standalone in the main datacenter is not supported. However, the DR MAS appliance is standalone.
  2. Import another MAS appliance into a remote datacenter, and configure an IP address.
  3. If you added a second disk to the main datacenter MAS appliances, then you must add the same size second disk to the DR MAS appliance.
  4. After configuring the new nodes’ IP address, login as nsrecover/nsroot.
  5. Enter deployment_type.py.
  6. Enter 2 for Remote Disaster Recovery Node.
  7. Enter the Floating IP address of the HA pair in the main datacenter.
  8. Enter the nsroot password, which is nsroot by default.
  9. The DR node registers with the MAS HA Pair.
  10. Point your browser to the Floating IP Address and login.
  11. Go to System > System Administration.
  12. On the right, in the right column, click Disaster Recovery Settings.
  13. The Registered Recovery Node should already be filled in.
  14. Check the box next to Enable Disaster Recovery, and click Apply Settings.
  15. Click Yes to enable DR.
  16. A System Backup is performed and replicated to the DR appliance.
  17. Disaster Recovery is not automatic. See the manual DR procedure at at Citrix Docs.
    • /mps/scripts/pgsql/pgsql_restore_remote_backup.sh

MAS Agents

The virtual appliance for MAS Agent is different than the normal MAS appliance.

  1. Download the MAS Agent from the main MAS download page. Scroll down the page to find the MASAGENT images.
  2. Extract the downloaded .zip file.
  3. Import the .ovf to vSphere.

  4. Edit the settings of the virtual machine to see the allocated CPU and Memory.
  5. Power on the MAS Agent virtual machine.
  6. At the virtual machine’s console, configure an IP address.
  7. Login as nsrecover/nsroot.
  8. Run /mps/register_agent_onprem.py
  9. Enter the floating IP address of the main MAS HA Pair.
  10. Login to the MAS Floating IP.
  11. Go to Networks > Agents.
  12. On the right, select the MAS Agent, and then click Attach Site.
  13. In the Site drop-down, if you don’t see your site, then you can click the plus icon to create a new site.
  14. Enter a name, enter a search location, and click Get Location to get the coordinates. Click Create when done.
  15. Click Save to attach the site.
  16. For HA, import two MAS Agents into the same Site.

MAS Appliance Maintenance

Add Instances

NetScaler MAS must discover NetScaler instances before they can be managed. Citrix Docs How NetScaler MAS Discovers Instances.

  1. Once you’ve built all of the nodes, point your browser to the NetScaler MAS Floating IP address, and login as nsroot/nsroot.
  2. If you see the What is NetScaler Management and Analytics System screen, then click Get Started.
  3. Deployment should already be done, so click Next.
  4. On the Add New Instances page, click Add Instance near the top right.

  5. Enter the NSIP address of a NetScaler appliance.
  6. Click the pencil next to ns_nsroot_profile.
  7. Type in the nsroot password, and then scroll down.
  8. The NetScaler Profile defaults to using https for instance communication. You can change it by unchecking Use global settings for NetScaler communication.
  9. Enter an SNMP v3 Security Name that NetScaler MAS will configure on the appliance.
  10. Click OK.
  11. Select the Site for the instance. You can click the plus icon to create a Site.
  12. For remote sites, you can optionally choose a MAS Agent.
  13. Then click OK to add the instance.
  14. A progress window will appear.
  15. You can add more instances, or just click Finish.
  16. To add more instances later, click the top left hamburger icon, go to Networks > Instances > NetScaler ADC. On the right, select a tab (e.g. MPX), and then click Add.

  17. To edit, or create new Admin Profiles, go to Networks > Instances > NetScaler ADC, and on the right is a Profiles button.

NetScaler SDX

  1. At Networks > Instances > NetScaler ADC, on the SDX tab, you can click Add to discover a SDX appliance, and all VPXs on that SDX appliance. You don’t have to discover the VPXs separately.
  2. In the Add NetScaler SDX page, click the pencil icon next to the Profile Name drop-down to edit nssdx_default_profile. Or you can click the plus icon to create a new SDX Profile. Note: SDX profiles are different than VPX profiles.
  3. Enter the credentials for the SDX SVM Management Service.
  4. For NetScaler Profile, select an admin profile that has nsroot credentials for the VPX instances. After the VPXs are discovered, MAS uses the NetScaler Profile to login to each VPX. If you don’t have a VPX Admin Profile in your drop-down list, click the plus icon. Note: You can only select one NetScaler Profile. If each VPX instance has different nsroot credentials, you can fix it after SDX discovery has been performed. The NetScaler Profile is different than the SDX Profile.
    1. In the Create NetScaler Profile page, enter the nsroot credentials for the VPX instances, and then scroll down.
    2. Enter a new SNMP Security Name or Community String.
    3. Then click Create.
  5. Back in the Configure NetScaler SDX Profile page, enter a new Community string for the SDX SVM. This appears to be SNMP v2 only.
  6. You can uncheck the box for Use global settings for SDX communication, and change the protocol. Click OK when done.
  7. Back in the Add NetScaler SDX page, select a Site, and optionally an Agent.
  8. Click OK to start discovery.
  9. After discovery is complete, switch to the NetScaler VPX tab. You should automatically see the VPX instances.
  10. To specify the nsroot credentials for a VPX, right-click the VPX, and click Edit.
    1. In the Modify NetScaler VPX page, either select an existing Profile Name, or click the plus icon to create a new one. Click OK when done. It should start rediscovery automatically.
  11. After fixing the nsroot credentials, right-click the VPX instance, and click Configure SNMP. MAS will configure the VPX to send SNMP Traps to MAS.

Instance management

  • REST API proxy – NetScaler MAS can function as a REST API proxy server for its managed instances. Instead of sending API requests directly to the managed instances, REST API clients can send the API requests to NetScaler MAS. See Citrix CTX228449 NetScaler MAS as an API Proxy Server
  • NetScaler VPX Check-In/Check-Out Licensing – You can allocate VPX licenses to NetScaler VPX instances on demand from NetScaler MAS. The Licenses are stored and managed by NetScaler MAS, which has a licensing framework that provides scalable and automated license provisioning. A NetScaler VPX instance can check out the license from the NetScaler MAS when a NetScaler VPX instance is provisioned, or check back in its license to NetScaler MAS when an instance is removed or destroyed. See Citrix CTX228451 NetScaler VPX Check-In/Check-Out Licensing with NMAS

Licenses

Virtual Server License Packs

Without licenses, you can enable analytics features on only 30 Virtual Servers. You can install additional licenses in 100 Virtual Server packs. More info at NetScaler MAS Licensing at Citrix Docs.

  1. On the left, go to Networks > Licenses.
  2. On the right, notice the Host ID.
  3. At mycitrix.com, allocate your NetScaler MAS licenses to this Host ID.
  4. Then use the Browse button to upload the allocated license file.
  5. Click Finish after uploading the license file to apply it.
  6. The License Expiry Information section shows you the number of installed licenses and when they expire.
  7. You can use the Notification Settings section to email you when licenses are almost fully consumed or about to expire.
  8. If you don’t have an Email server setup yet, click the plus icon to create one.

Allocate licenses to Virtual Servers

You can manually unassign a MAS Virtual Server license and reassign it to a different Virtual Server.

  1. Go to Networks> Licenses > System Licenses to see the number of currently installed licenses, and the number of managed virtual servers.
  2. By default, Auto-select Virtual Servers is enabled. If you disable this setting, then the Click to select button appears.
  3. Click the Click to select button.
  4. The top right shows you the number of licensed Virtual Servers.
  5. In the left, select the type of Virtual Server you want to unlicense or license.
  6. On the Licensed tab, select one or more Virtual Servers, and click the Unlicense button. This returns licenses to the pool.
  7. Switch to the Unlicensed tab.
  8. Select a Virtual Server you want to license, and then click the License button.
  9. Click the blue back arrow when done.

Enable AppFlow / Insight

  1. Go to Networks > Instances > NetScaler ADC. On the right, switch to one of the instance type tabs (e.g. VPX).
  2. Select an instance, open the Select Action menu, and click Configure Analytics.
  3. At the top of the page are boxes you can check.
  4. In the Application List page, with Load Balancing selected in the View list, select your StoreFront load balancer, and then click Enable AppFlow. If you don’t see your Virtual Server in this list, then you need to assign a license.
  5. In the Enable AppFlow window, do the following:
    1. In the larger Expression box, type in true.
    2. For newer NetScaler appliances, change the Transport Mode selection to Logstream instead of IPFIX. Notice the firewall requirement for TCP port 5557.
    3. Select Web Insight.
    4. If App Firewall is enabled on the vServer, then also select Security Insight.
    5. Client Side Measurement injects JavaScript in HTTP responses to measure page load times and can sometimes cause problems in Receiver.
  6. Click OK.
  7. Use the View drop-down to select VPN.
  8. Right-click a NetScaler Gateway Virtual Server, and click Enable AppFlow.
  9. In the Enable AppFlow window, do the following:
    1. In the Select Expression drop-down, select true.
    2. For newer NetScaler appliances, change the Transport Mode to Logstream. Notice the firewall warning.
    3. Select both ICA and HTTP. The HTTP option is for Gateway Insight.
    4. The TCP option is for the second appliance in double-hop ICA. If you need double-hop, then you’ll also need to run set appflow param -connectionChaining ENABLED on both appliances. See Enabling Data Collection for NetScaler Gateway Appliances Deployed in Double-Hop Mode at Citrix Docs for more information.
  10. Click OK.
  11. By default, with AppFlow enabled, if a NetScaler High Availability pair fails over, all Citrix connections will drop, and users must reconnect manually. NetScaler 11.1 build 49 adds a new feature to replicate Session Reliability state between both HA nodes.
    1. From Session Reliability on NetScaler High Availability Pair at Citrix Docs: Enabling this feature will result in increased bandwidth consumption, which is due to ICA compression being turned off by the feature, and the extra traffic between the primary and secondary nodes to keep them in sync.
    2. On a NetScaler 11.1 build 49 and newer appliance, go to System > Settings.
    3. On the right, in the Settings section, click Change ICA Parameters.
    4. Check the box next to Session Reliability on HA Failover, and click OK.
  12. In a NetScaler 12 instance, at System > AppFlow > Collectors, you can see if the Collector (MAS) is up or not. However, NetScaler uses SNIP to verify connectivity, but AppFlow is sent using NSIP, so being DOWN doesn’t necessarily mean that AppFlow isn’t working. Citrix CTX227438 After NetScaler Upgrade to Release 12.0 State of AppFlow Collector Shows as DOWN.

  13. AppFlow for ICA (HDX Insight) information can be viewed in NetScaler MAS under the Analytics > HDX Insight node.

Citrix Blog Post – NetScaler Insight Center – Tips, Troubleshooting and Upgrade

Enable Syslog on Instance

MAS can configure NetScaler instances to send Syslog to MAS. Note: this might increase disk space consumption on the MAS appliances.

  1. Go to Networks > Instances > NetScaler ADC. On the right, select a tab..
  2. On the right, select an instance, open the Select Action drop-down, and click Configure Syslog.
  3. Uncheck All and check the other boxes. You probably don’t want Debug or None. Click OK.

MAS nsroot Password

Changing the nsroot password also changes the nsrecover password.

  1. In MAS, go to System > User Administration > Users.
  2. On the right, select the nsroot account, and click Edit.
  3. Check the box next to Change Password and enter a new password.
  4. You can also specify a session timeout by checking the box next to Configure Session Timeout.
  5. Click OK.

Management Certificate

The certificate to upload must already be in PEM format. If you have a .pfx, you must first convert it to PEM (separate certificate and key files). You can use a NetScaler to convert the .pfx, and then download the converted certificate from the appliance.

  1. Go to System > System Administration.
  2. On the right, in the Set Up NetScaler MAS section, click Install SSL Certificate.
  3. Click Choose File to browse to the PEM format certificate and key files. If the keyfile is encrypted, enter the password. Click OK.
  4. Click Yes to reboot the system.

System Configuration

  1. Go to System > System Administration.
  2. On the right, modify settings (e.g. Change Time Zone) as desired.

  3. Click Change System Settings.
    1. Check the box next to Enable Session Timeout, and specify a value.
    2. By default, at Networks > Instances > NetScaler ADC , if you click a blue IP address link, it opens the instance in a new web page, and logs in automatically using the nsroot credentials. If you want to force MAS users to login using non-nsroot credentials, in Modify System Settings, check the bottom box for Prompt Credentials for Instance Login.

    3. Click OK when done.
  4. Configure SSL Settings lets you disable TLS 1 and TLS 1.1.
    1. Click the Protocol Settings section in the Edit Settings section on the right side of the screen.
    2. On the left, uncheck TLSv1 and TLSv1.1. Then click OK and Close.
    3. A restart is required.

Prune Settings

  1. On the left are Prune Settings.
  2. System Prune Settings …
    1. Defaults to deleting System Events, Audit Logs, and Task Logs after 15 days. System events are generated by the MAS appliance, which is different than Instance events (SNMP traps) that are generated by NetScaler appliances.
    2. MAS can initiate a purge automatically as the database starts to get full.
    3. If you click the pencil next to the purge threshold value, you can configure an alarm for when the database gets full.

  3. To see the current database disk usage, go to System > Statistics.
  4. Instance Events prune Settings controls when instance SNMP traps are pruned, which defaults to 40 days.

  5. If you are sending Syslog from instances to MAS, Instance Syslog Purge Settings controls when the log entries are purged.

Backup Settings

  1. In the right column, under Backup Settings, are additional settings.
  2. System Backup Settings defines how many MAS backups you want to keep.

  3. Instance Backup Settings lets you configure how often the instances are backed up.
    1. You probably want to increase the number of instance backups, or decrease the backup interval.
    2. There is an option to perform a backup whenever the NetScaler configuration is saved.
    3. The Enable External Transfer checkbox lets you transfer the backups to an external system so it can be backed up by your backup tool.

Analytics Settings

  1. There are more settings at Analytics > Settings.
  2. ICA Session Timeout can be configured by clicking the link.
    • Two minutes of non-existent traffic must occur before the session is considered idle. Then this idle timer starts.
  3. You can configure how the App Score (Application Dashboard) is calculated.

  4. Analytics > Settings > Data Persistence lets you configure how long Analytics data is retained. Adjusting these values could dramatically increase disk space consumption. See CTX224238 How Do I Increase Granularity of Data Points Stored on NetScaler MAS Analytics?.

    • To see the current database disk usage, go to System > Statistics.

NTP Servers

  1. On the left, click System > NTP Servers.
  2. On the right, click Add.
  3. Enter an NTP server, and click Create.

  4. After adding NTP servers, click the NTP Synchronization button.
  5. Check the box next to Enable NTP Synchronization, and click OK.
  6. Click Yes to restart.

Syslog

This is for log entries generated by MAS, and not for log entries generated by instances.

  1. Go to System > Auditing > Syslog Servers.
  2. On the right, click Add.
  3. Enter the syslog server IP address, and select Log Levels. Click Create.
  4. You can click Syslog Parameters to change the timezone and date format.

System Email Notifications

  1. Go to System > Notifications > Email.
  2. On the right, on the Email Servers tab, click Add.
  3. Enter the SMTP server address, and click Create.
  4. On the right, switch to the Email Distribution List tab, and click Add.
  5. Enter an address for a destination distribution list, and click Create.
  6. On the left, click System > Notifications.
  7. On the right, click Change Notification Settings.
  8. Move notification categories (e.g. UserLogin) to the right.
  9. Check the box next to Send Email. Select a notification distribution list. Then click OK.

Authentication

  1. Go to System > Authentication > LDAP.
  2. On the right, click Add.
  3. This is configured identically to NetScaler. Enter a Load Balancing VIP for LDAP.
    1. Change the Security Type to SSL, and Port to 636. Scroll down.
    2. Enter the Base DN in LDAP format.
    3. Enter the bind account credentials.
    4. Check the box for Enable Change Password.
    5. Click Retrieve Attributes, and scroll down.
    6. For Server Logon Attribute, select sAMAccountName.
    7. For Group Attribute, select memberOf.
    8. For Sub Attribute Name, select cn.
    9. To prevent unauthorized users from logging in, configure a Search Filter. Scroll down.
    10. If desired, configure Nested Group Extraction.
  4. Click Create.
  5. On the left, go to System > User Administration > Groups.
  6. On the right, click Add.
    1. Enter the case sensitive name of your NetScaler Admins AD group.
    2. Move the admin Permission to the right.
    3. The Configure User Session Timeout checkbox lets you configure a session timeout.
    4. Click Next.
    5. On the Authorization Settings page, if you are delegating limited permissions, you can uncheck these boxes and delegate specific entities.
    6. Click Create Group.
    7. In the Assign Users page, click Finish. Group membership comes from LDAP, so there’s no need to add local users.
  7. On the left, go to System > User Administration.
  8. On the right, click User Lockout Configuration.
  9. If desired, check the box next to Enable User Lockout, and configure the maximum logon attempts. Click OK.
  10. On the left, go to System > Authentication.
  11. On the right, click Authentication Configuration.
  12. Change the Server Type to EXTERNAL, and click Insert.
  13. Select the LDAP server you created, and click OK.
  14. Make sure Enable fallback local authentication is checked, and click OK.

Analytics Thresholds

  1. Go to Analytics > Settings > Thresholds.
  2. On the right, click Add.
  3. Enter a name.
  4. Use the Traffic Type drop-down to select HDX, Web, Security, or APPANALYTICS.
  5. Use the Entity drop-down to select a category of alerts. What you choose here determines what’s available as Metrics when you click Add Rule.
    1. With HDX as the Traffic Type, to add multiple rules for multiple Entity types, simply change the Entity drop-down before adding a new rule.
    2. If the Traffic Type is HDX, and the Entity drop-down is set to Users, on the bottom in the Configure Geo Details section, you can restrict the rule so it only fires for users for a specific geographical location.

  6. In the Notification Settings section, check the box to Enable Treshold.
  7. Check the box to Notify through Email, and select an existing Email Distribution List.
  8. Click Create.

Private IP Blocks

You can define Geo locations for internal subnets.

  1. Go to Networks > Sites > IP Blocks.
  2. On the right, click Add.
  3. In the Create IP Blocks page:
    1. Enter a name for the subnet.
    2. Enter the starting and ending IP address.
    3. Select a Geo Location (Country, Region, City). As you change the fields, the coordinates are automatically filled in.
  4. Click Create.

Instance Email Alerts (SNMP Traps)

You can receive email alerts whenever a NetScaler appliance sends a critical SNMP trap.

  1. On the left, go to Networks > Events > Rules.
  2. On the right, click Add.
  3. Give the rule a name.
  4. Move Severity filters (e.g. Major, Critical) to the right by clicking the plus icon next to each Severity.
  5. While scrolling down, you can configure additional alert filters. Leaving them blank will alert you for all categories, objects, and instances.
  6. On the bottom of the page, in the Event Rule Actions section, click Add Action.
  7. In the Add Event Action page:
    1. Select an Action Type (e.g. Send e-mail Action).
    2. Select the recipients (or click the plus icon to add recipients).
    3. Optionally, enter a Subject and/or Message.
    4. Emails can be repeated by selecting Repeat Email Notification until the event is cleared.
  8. Click OK.
  9. Then click Create.
  10. See the Event Management section at MAS How-to articles at Citrix Docs.

Events Digest

MAS can email you a daily digest (PDF format) of system and instance events

To enable the daily digest:

  1. Go to System > Notifications.
  2. On the right, click Configure Event Digest Settings.
  3. Uncheck the box next to Disable Event Digest.
  4. Configure the other settings as desired, and click OK.

Director Integration

Integrating NetScaler MAS with Director adds Network tabs to Director’s Trends and Session Details views. Citrix Blog Post Configure Director with Netscaler Management & Analytics System (MAS)

Requirements:

  • XenApp/XenDesktop must be licensed for Platinum Edition. This is only required for the Director integration. Without Platinum, you can still access the HDX Insight data by going visiting the NetScaler MAS website.
  • Director must be 7.11 or newer for NetScaler MAS support.

To link Citrix Director with NetScaler MAS:

  1. On the Director server, run C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /confignetscaler.
  2. Enter the NetScaler MAS nsroot credentials.
  3. If HTTPS Connection (recommended), the NetScaler MAS certificate must be valid and trusted by both the Director Server and the Director user’s browser.
  4. Enter 1 for NetScaler MAS.
  5. Do this on both Director servers.

Use NetScaler MAS

Networks

Everything under the Networks node is free.

At Networks > Instances, select an instance, and view its Dashboard.

MAS 12.1 adds a series of tabs to the Instance Dashboard.

Backups are available by selecting an instance, and clicking Backup/Restore.

Networks > Network Reporting lets you create Dashboards where you can view Instance performance data.

Networks > Network Reporting > Thresholds lets you create thresholds when counters cross a threshold. For example, you might want a notification when Throughput gets close to the licensed limit.

Configuration Record and Play

Use MAS to record a configuration change on one instance, and push to other instances.

  1. Go to Networks > Configuration Jobs.
  2. On the right, click Create Job.
  3. Change the Configuration Source drop-down to Record and Play.
  4. Change the Source Instance drop-down to the instance you want to record.
  5. Click Record.
  6. MAS opens the instance GUI. Make changes as desired.
  7. When done, go back to MAS, and click Stop.
  8. MAS retrieves the changed config.
  9. On the left, you’ll see the changed commands. Drag them to the right.
  10. On the right, you can change instance-specific values to variables by simply highlighting the values. This allows you to change the values for each instance you push this config to.
  11. Proceed through the rest of the Configuration Job wizard like normal. You’ll select instances, specify variable values for each instance, and schedule the job.

Dave Brett Automating Your Netscaler 11.1 Vserver Config Using Netscaler Management and Analytics System uses a Configuration Job to deploy StoreFront load balancing configuration to an instance.

Analytics and Applications

This functionality requires Virtual Server licenses, which can come from your built-in 30 free licenses.

The AppFlow Analysis tools (e.g. HDX Insight) are located under the Analytics node. See Viewing HDX Insight Reports and Metrics at Citrix Docs.

Applications > Dashboard automatically includes all licensed vServers in the Others section. On the top middle, click Define Custom App to group vServers together into an application. The grouped vServers are removed from the Others list.

Applications > Configurations > Stylebooks lets you use Stylebooks to create new NetScaler configurations.

There are built-in Stylebooks for Exchange, SharePoint, Oracle, ADFS, etc. Or you can create your own Stylebook and use it to create NetScaler configurations. For details, see Stylebooks at Citrix Docs.

The Applications Node has quite a bit of functionality. See Application Analytics and Management at Citrix Docs for details.

Link:

HDX Insight

HDX Insight Dashboard displays ICA session details including the following:

  • WAN Latency
  • DC Latency
  • RTT (round trip time)
  • Retransmits
  • Application Launch Duration
  • Client Type/Version
  • Bandwidth
  • Licenses in use

Citrix CTX215130 HDX Insight Diagnostics and Troubleshooting Guide contains the following contents:

  • Introduction
  • Prerequisites for Configuring HDX Insight
  • Troubleshooting
    • Issues Related to ICA parsing
    • Error Counter details
  • Checklist before Contacting Citrix Technical Support
  • Information to collect before Contacting Citrix Technical support
  • Known Issues

Gateway Insight

In the Analytics node is Gateway Insight.

This feature displays the following details:

  • Gateway connection failures due to failed EPA scans, failed authentication, failed SSON, or failed application launches.
  • Bandwidth and Bytes Consumed for ICA and other applications accessed through Gateway.
  • # of users
  • Session Modes (clientless, VPN, ICA)
  • Client Operating Systems
  • Client Browsers

More details at Gateway Insight at Citrix Docs.

Security Insight

The Security Insight dashboard uses data from Application Firewall to display Threat Index (criticality of attack), Safety Index (how securely NetScaler is configured), and Actionable Information. More info at Security Insight at Citrix Docs.

Troubleshooting

Citrix CTX215130 HDX Insight Diagnostics and Troubleshooting Guide: Syslog messages; Error counters; Troubleshooting checklist, Logs

Citrix CTX224502 NetScaler MAS Troubleshooting Guide

Upgrade NetScaler MAS

  1. Download the latest Upgrade Package for NetScaler Management and Analytics System. You want the Upgrade Package, not a MAS image.
  2. Login to NetScaler MAS.
  3. Go to System > System Administration.
  4. On the right, in the right pane, click Upgrade NetScaler MAS.
  5. Browse to the build-mas-12.1…tgz Upgrade Package, and click OK.
  6. Click Yes to reboot the appliance.



  7. After it reboots, login. The new firmware version will be displayed by clicking your username in the top right corner.
↧

Native One Time Passwords (OTP) – Citrix Gateway 13

May 30, 2019, 2:55 pm
$
0
0

Navigation

Change Log

Overview

Citrix ADC 13 Native OTP lets you enable two-factor authentication without purchasing any other authentication product. A typical configuration uses Citrix SSO app (mobile VPN Client) to receive push notifications, or Google Authenticator to generate Passcodes. See the following for an overview:

Here are some notes and requirements for Native OTP:

  • Licensing – Citrix ADC Native OTP is part of nFactor, and thus requires Citrix ADC Advanced Edition or Citrix ADC Premium Edition licensing. Citrix ADC Standard Edition licensing is not sufficient.
    • OTP Push Notifications require ADC Premium Edition
  • Workspace app 1809 and newer with Citrix Gateway 12.1 build 49 and newer support nFactor authentication. Older Receivers and older NetScalers don’t support nFactor with Receiver, so you’ll instead have to use a web browser.

  • Citrix Gateway VPN Plug-in 12.1 build 49 and later support nFactor when authenticating from the VPN Plug-in.

  • Push notifications – Citrix ADC 13 and newer supports OTP push notifications of logon request to the mobile (iOS, Android) Citrix SSO app. Other authenticator apps are not supported for OTP Push, but they can be used with OTP Passcode.
  • Authenticator – If not using Citrix SSO app, then Google Authenticator can generate passcodes. Christian in the comments indicated that Microsoft Authenticator also works. Click on plus sign -> other (Google,…).
  • Internet for Push – Push notifications requires the Citrix ADC appliance to be able to send API calls across the Internet to Citrix Cloud.
  • Active Directory attribute – Citrix ADC stores OTP device enrollment secrets in an string-based Active Directory attribute. Citrix’s documentation uses the userParameters Active Directory attribute.
    • The LDAP bind account must have permission to modify this attribute on every user.
    • The userParameters attribute must not be populated. Active Directory Users & Computers might set the userParameters attribute if you modify any of the RDS property pages.
  • Enroll multiple devices – Citrix ADC 13 and newer lets you control the number of devices that a user can enroll.
  • Manageotp is difficult to secure – The manageotp website is usually only protected by single factor authentication so external access must be blocked.

Notes on Citrix ADC Configuration Objects for OTP

Here are some notes on the Citrix ADC OTP configuration objects. Detailed instructions are provided later.

  • Make sure NTP is configured on the Citrix ADC. Accurate time is required.
  • AAA vServer – nFactor requires a AAA vServer, which can be non-addressable. You don’t need any additional public IP for OTP.
    • An Authentication Profile links the AAA vServer to the Citrix Gateway vServer.
  • Citrix Cloud – For Push notifications, create a Citrix Cloud account. No Citrix Cloud licensing needed. Citrix ADC uses Cloud API credentials to authenticate with Citrix Cloud.
  • NSC_TASS cookie – To access the manageotp web page, users add /manageotp to the end of the Gateway URL. Citrix ADC puts this URL path into a cookie called NSC_TASS. You can use this cookie and its value in policy expressions for determining which Login Schema is shown to the user.
  • Login Schema for manageotp – The built-in Login Schema file named SingleAuthManageOTP.xml has hidden fields that enable the manageotp web page. If the Login Schema Policy expression permits the SingleAuthManageOTP.xml Login Schema to be shown to the user, then after authentication the user will be taken to the manageotp web page.
    • LDAP authentication is expected to be bound to the same factor as this SingleAuthManageOTP login schema.
    • The next factor is a LDAP Policy/Server with authentication disabled (unchecked) but with arguments specifying the Active Directory attribute for the OTP Secret and Push Service configuration.

  • Login Schema for OTP authentication – The built-in Login Schema file named DualAuthPushOrOTP.xml performs the two-factor authentication utilizing the push service. There’s a checkbox that lets users choose Passcode instead of Push. This login schema has a Credential called otppush.

    • If you prefer to not use Push, then you can use a normal DualAuth.xml Login Schema file since for passcode authentication there are no special Login Schema requirements other than collecting two password fields.
    • Both methods expect an authenticating LDAP Policy/Server to be bound to the same Factor as the Login Schema.
    • The next factor should be a non-authenticating LDAP Policy/Server that optionally has the the Push Service defined and must have the OTP Secret attribute defined.
  • Single Sign-on to StoreFront – The OTP dual authentication Login Schema essentially collects two passwords (AD password plus push, or AD password plus passcode). Later, Citrix Gateway needs to use the AD password to perform Single Sign-on to StoreFront. To ensure the AD password is used instead of the OTP passcode, configure the OTP dual authentication Login Schema to store the AD password in a AAA attribute and then use a Citrix Gateway Traffic Policy/Profile to utilize the AAA attribute during Single Sign-on to StoreFront.
  • nFactor Visualizer – Citrix ADC 13 has a nFactor Visualizer to simplify the OTP configuration. Or you can manually create the LDAP Policies/Actions, the Login Schema Policies/Profiles, the PolicyLabels, and then bind them to a AAA vServer.

AAA Virtual Server

Create a AAA vServer that is the anchor point for our OTP nFactor configuration.

  1. Go to Security > AAA – Application Traffic.
  2. If the AAA feature is not enabled, then right-click the AAA node, and click Enable Feature.
  3. Go to Security > AAA – Application Traffic > Virtual Servers.
  4. On the right, click Add.
  5. This AAA vServer is for OTP so name it accordingly.
  6. Change the IP Address Type to Non Addressable. You don’t need to specify any additional IP address.
  7. Click the blue OK button.
  8. Click where it says No Server Certificate.
    1. In the Server Certificate Binding section, click Click to select.
    2. Click the radio button next to a certificate, and then click the blue Select button at the top of the page. You can select the same certificate as the Citrix Gateway Virtual Server.
    3. Click Bind.
  9. Click Continue to close the Certificate section.
  10. In the Advanced Authentication Policies section, don’t bind anything and just click Continue. We’ll bind a nFactor Flow later.
  11. You can optionally improve the SSL ciphers on this AAA Virtual Server but it’s probably not necessary since this AAA vServer is not directly addressable.
  12. Nothing else is needed at this time so click the blue back arrow on the top left.

Push Service

If your Citrix ADC has Internet access, then you can enable OTP Push Authentication. The ADC must be able to reach the following FQDNs:

  • mfa.cloud.com
  • trust.citrixworkspacesapi.net

Create an API Client at citrix.cloud.com:

  1. Go to https://citrix.cloud.com and login. Your cloud account does not need any licensed services.
  2. On the top left, click the hamburger (menu) icon, and then click Identity and Access Management.
  3. Switch to the tab named API Access.
  4. On this page, notice the Customer ID. You’ll need this value later.
  5. Enter a name for a new API client and then click Create Client
  6. Click Download to download the client credentials.

On ADC 13, create the Push Service:

  1. In Citrix ADC 13 management GUI, navigate to the Push Service node. The easiest way to find it is to enter Push in the search box on the top left.
  2. On the right, click Add.
  3. In the Create Push Service page, do the following:
    1. Enter a name for the Push Service.
    2. Enter the Client ID and Client Secret that you downloaded when creating your API Client.
    3. Enter the Customer ID shown on the Create Client web page at cloud.com. Make sure there are no hidden characters or whitespace around the Customer ID.
  4. Click Create.
  5. On the top right, click the refresh icon until the Status changes to COMPLETE. If it won’t go past CCTOKEN, then make sure you entered the API Client info correctly, especially the Customer ID, which might have hidden characters around it.

LDAP Actions/Servers

Create three LDAP Actions (aka LDAP Servers):

  • One LDAP Action for normal LDAP authentication against Active Directory
  • One LDAP Action to set the OTP Active Directory attribute and register with push
  • One LDAP Action to perform push authentication (in a dual-authentication flow)

Create normal LDAP Action

  1. Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions > LDAP.
  2. On the right, click Add.
  3. Create a normal LDAP Server if you don’t have one already. This one has Authentication enabled. There are no special instructions for this LDAP Server.

Create LDAP Action for OTP Device Registration

Create the LDAP Action for OTP device registration that sets the OTP Active Directory attribute and registers with push:

  1. Create another LDAP Action.
  2. Name it according to this goal: used by the manageotp web site to set the OTP authenticator in Active Directory.
  3. On the right, uncheck the box next to Authentication.
  4. Make sure the Administrator Bind DN has permissions to modify the OTP Secret Active Directory attribute for all users. A regular non-admin LDAP Bind account won’t work.
  5. If you cloned an existing LDAP Server, then make sure you re-enter the Administrator Password or the new LDAP Action won’t work.
  6. Click Test LDAP Reachability.
  7. Configure the Server Logon Name Attribute to match the one you configured in the normal authentication LDAP Server.
  8. In the Other Settings section, on the bottom right, find the OTP Secret field. Enter the name of the Active Directory attribute where Citrix ADC will store the user’s OTP secret. You can use the userParameters attribute if that attribute isn’t being used for anything else.
    • userParameters is populated by Active Directory Users & Computers if you set anything on the RDS tabs (e.g. RDS Roaming Profile).
  9. Select the Push Service that you created earlier.
  10. Click Create when done.

Create LDAP Action for OTP Authentication

Create a LDAP Action that performs OTP push authentication or verifies the OTP Passcode. The only difference from the prior LDAP Action is the addition of an LDAP Search Filter.

  1. Create another LDAP Action.
  2. Give the LDAP Action a name.
  3. On the right, uncheck the box next to Authentication.
  4. Make sure the Administrator Bind DN has permissions to read the OTP Secret Active Directory attribute.
  5. If you cloned an existing LDAP Server, then make sure you re-enter the Administrator Password or the new LDAP Action won’t work.
  6. Click Test LDAP Reachability.
  7. In the Other Settings section, configure the Server Logon Name Attribute to match the one you configured in the normal authentication LDAP Server.
  8. In the Search Filter field, enter the text userParameters>=#@. This syntax ensures that only users with enrolled authenticators can login. See George Spiers NetScaler native OTP for more info.
  9. In the Other Settings section, on the bottom right, find the OTP Secret field. Enter the name of the Active Directory attribute containing the user’s OTP secret.
  10. In the Push Service drop-down, select the Push Service that you already created.
  11. Click Create when done.

nFactor Visualizer

We will build a nFactor Flow that looks something like this:

  • First factor on the left chooses either OTP Device Registration or OTP Authentication. If user enters /manageotp, then nFactor Flow takes the top path. Otherwise, nFactor flow takes the bottom path.
    • Login Schema is not needed for the first factor.
  • Second factor for Manage OTP = Login Schema with Manage OTP flag and normal LDAP authentication before allowing users to add devices.
    • Third factor is just an LDAP Policy configured with the OTP Active Directory attribute and Push Service. No Login Schema needed.
  • Second factor for OTP Authentication = Login Schema with OTP Push (or OTP Passcode) and normal LDAP authentication.
    • Third factor is just an LDAP Policy with the OTP Active Directory attribute and Push Service. No Login Schema needed.

nFactor Visualizer notes:

  • nFactor Visualizer is not required. You can instead follow the older manual ADC 12.1 instructions.
  • It doesn’t seem to be possible to rename any part of the flow once it’s created. To rename, you basically remove the entire flow and rebuild it.
  • nFactor Visualizer does not support policy expressions for Login Schemas so the older ADC 12.1 instructions must be modified to support two different branches.

Create Flow and first factor that selects Manage or selects Authenticate

  1. In ADC 13, go to Security > AAA – Application Traffic > nFactor Visualizer > nFactor Flows. Or search the menu for nFactor.
  2. On the right, click Add.
  3. Click the blue plus icon to create a factor.
  4. Name the factor based on this goal: choose manageotp or authenticate based on whether the user entered /manageotp or not. The name of the first factor is also the name of the nFactor Flow.
  5. Click the blue Create button.
  6. The first factor does not need a Schema.
  7. In the first factor, click where it says Add Policy.
  8. In the Choose Policy to Add page, click Add to create an authentication policy.
    1. Name this policy according to this goal: if this policy’s expression is true, then select the manageotp branch (instead of OTP authentication).
    2. For the Action Type drop-down, select NO_AUTHN. This policy is merely a decision point for the next factor so no actual authentication will occur at this time. The next factor is configured later.
    3. In the Expression box, enter something similar to the following. The IP subnet expression restricts the manageotp web page to only internal users. 
      http.req.cookie.value("NSC_TASS").eq("manageotp") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)
    4. Then click the blue Create button.
  9. Click the blue Add button to bind this policy to the factor.
  10. In the first factor, below the policy you just added, click the blue plus arrow to create another policy.
  11. In the Choose Policy to Add page, click Add to create another policy.
    1. Name the policy according to this goal: select the dual factor OTP authentication branch.
    2. For the Action Type drop-down, select NO_AUTHN. This is a decision point policy without authentication that leads to the next factor that does the actual authentication.
    3. In the Expression box, enter true to capture all OTP users that did not match the prior manageotp policy.
    4. Click the blue Create button.
  12. Click Add to bind this policy to the first factor but after (higher priority number) than the manageotp policy.

Create second factor for manageotp

  1. In the first factor, click the green plus icon to the right of the “SelectManageOTP” policy. If the “SelectManageOTP” policy is true, then this new factor will be evaluated.
  2. Name this factor according to this goal: perform single-factor LDAP authentication before allowing access to the manageotp web page.
  3. Then click the blue Create button.
  4. In the second factor, click where it says Add Schema.
  5. In the Choose Schema page, click Add to create a Login Schema.
    1. Name the Login Schema according to this goal: ask user for one password that will be verified with LDAP (Active Directory) before showing the manageotp web page.
    2. In the Authentication Schema field, click the pencil icon.
    3. The existing window expands to show the Login Schema Files. On the left, click the LoginSchema folder to see the files in that folder.
    4. In the list of files, click SingleAuthManageOTP.xml. This login schema asks for one password and has the special hidden credential to enable the manageotp web page.
    5. To actually select this file, on the top right, click the blue Select button. The Login Schema window will then collapse so that Login Schema Files are no longer shown.
    6. Make sure the Authentication Schema field shows the Login Schema file that you selected.
    7. Then click the blue Create button.
  6. Click OK to bind the Schema to the factor.
  7. In the second factor, below the Schema, click Add Policy.
  8. In the Choose Policy to Add page, if you already have a normal Advanced Expression LDAP policy, then select it.
  9. Otherwise, click Add to create one.
    1. Name this policy according to this goal: perform normal LDAP authentication against an Active Directory domain.
    2. In the Action Type drop-down, select LDAP.
    3. In the Action drop-down, select the LDAP Action/Server you created earlier that performs normal authentication.
    4. In the Expression box, enter true, which is an Advanced Expression.
    5. Click the blue Create button.
  10. Click Add to bind this LDAP Policy to the factor.

Create third factor that registers an OTP device with Active Directory and Push

  1. In the second factor, click the green plus icon to create another factor. This new factor is only evaluated if the LDAP Policy is successful.
  2. Name the factor according to this goal: register the device with Active Directory and optionally Push.
  3. This factor does not need any Schema.
  4. In the third factor, click Add Policy
  5. In the Choose Policy to Add page, click Add to create a policy.
    1. Name the policy according to this goal: Register OTP devices using LDAP Action without authentication that has the OTP Secret Attribute specified.
    2. In the Action Type drop-down, select LDAP.
    3. In the Action drop-down, select the LDAP Action you created earlier that registers new devices. Make sure authentication is disabled in the LDAP Action, and make sure it has OTP Secret and optionally OTP Push configured.
    4. In the Expression field, enter true.
    5. Click the blue Create button.
  6. Click the blue Add button to bind this policy to the factor.

The Factors for manageotp are complete. Now we build the factors for authenticating using OTP.

Create a second factor for LDAP Authentication

  1. Go back to the first factor and click the green plus icon next to the OTP Authentication policy.
  2. Name the factor according to this goal: ask user for one password + push, or two passwords, and then perform LDAP authentication. OTP authentication is performed in the next factor (see below).
  3. In the second factor, click where it says Add Schema.
  4. In the Choose Schema window, click Add.
    1. Name the Login Schema according to this goal: ask for one password + OTP push, or ask for two passwords.
    2. In the Authentication Schema field, click the pencil icon.
    3. The window expands to show Login Schema Files. On the left, click the LoginSchema folder to see the files under it.
    4. On the left, click the DualAuthPushOrOTP.xml file.
    5. Or if you don’t want push, then click a normal two password schema like DualAuth.xml. You can modify the DualAuth.xml file to indicate to the user that the OTP Passcode is expected in the second field.
    6. Then on the top right click the blue Select button. This causes the Login Schema window to collapse and no longer show the Login Schema Files.
    7. In the Authentication Schema field, makes sure the correct file name is selected.
    8. Click More.
    9. At the bottom, in the Password Credential Index field, enter a 1 to save the first password into AAA Attribute 1, which we’ll use later in a Traffic Policy that performs Single Sign-on to StoreFront.
    10. Then click the blue Create button.
  5. Click OK to bind the Schema to the factor.
  6. In the second factor, below the schema, click where it says Add Policy.
  7. In the Select Policy drop-down, select your normal LDAP Active Directory authentication policy. This is the same one you used for the second factor in the manageotp branch.
  8. Click the blue Add button to bind this LDAP policy to the second factor.

Create third factor to perform OTP authentication (Push or Passcode)

  1. In the second factor, click the green plus icon next to the LDAP Policy to create another factor.
  2. Name the factor according to this goal: perform OTP Push or Passcode authentication.
  3. Be aware that the nFactor Visualizer might swap your third factors.
  4. This third factor does not need a Login Schema.
  5. In the new third factor (probably the top one, follow the arrows), click where it says Add Policy.
  6. In the Choose Policy to Add page, click Add to create a policy.
    1. Name this policy according to this goal: perform OTP Push or OTP Passcode authentication.
    2. In the Action Type drop-down, select LDAP.
    3. In the Action drop-down, select the LDAP action you created earlier that verifies the OTP push or passcode. This is the Action that has the LDAP Filter configured.
    4. In the Expression box, enter true.
    5. Click the blue Create button.
  7. Click the blue Add button to bind this policy to the third factor.
  8. Click the blue Done button to close the Flow.

Bind nFactor Flow to AAA Virtual Server

  1. In the nFactor Flows menu node, highlight the nFactor Flow and click the button labelled Bind to Authentication Server.
  2. In the Authentication Server drop-down, select the AAA vServer you created earlier.
  3. Everything else should already be filled in so just click the blue Create button.

Maximum Number of Registered OTP Devices

ADC 13 lets you restrict the number of OTP devices each user can register:

  1. In the ADC menu, go to Security > AAA – Application Traffic.
  2. On the right, click Change authentication AAA OTP Parameter.
  3. Enter the number of devices each user can register and then click OK.
  4. When the user attempts to register more than the max number of devices, the error message is not user friendly.
  5. But you can see the actual error by grepping /var/log/ns.log for otp. which might show <Max permitted otp devices reached>.

Traffic Policy for Single Sign-on to StoreFront

Create Traffic Profile

  1. On the left, go to Citrix Gateway > Policies > Traffic.
  2. On the right, switch to the tab named Traffic Profiles, and click Add.
  3. Name the Traffic Profile according to this goal: use the AAA attribute 1 as password when doing Single Sign-on to StoreFront.
  4. Scroll down.
  5. In the SSO Password Expression box, enter the following which uses the Login Schema Password Attribute specified earlier. 
    AAA.USER.ATTRIBUTE(1)
  6. Click the blue Create button.

Create Traffic Policy

  1. On the right, switch to the tab named Traffic Policies, and click Add.
  2. In the Request Profile field, select the Traffic Profile you just created.
  3. Name the Traffic Policy.
  4. In the Expression box, enter true (Advanced Syntax).
    • If your Citrix Gateway Virtual Server allows full VPN, change the expression to the following. Source = Julien Mooren at NetScaler – Native OTP is breaking SSL VPN. 
      http.req.method.eq(post)||http.req.method.eq(get) && false
  5. Click the blue Create button.

Citrix Gateway, Traffic Policy, and Authentication Profile

Note: ADC 13.0 build 36.27 will perform a core dump if AppFlow is enabled on the appliance so make sure AppFlow is disabled under Advanced Features. The core dump seems to happen even if no AppFlow policies are bound to the Gateway Virtual Server.

Edit an existing Citrix Gateway Virtual Server

  1. Go to Citrix Gateway > Virtual Servers.
  2. Edit an existing Gateway vServer. If you don’t have one, see the other Citrix Gateway topics on this site.

Bind the Traffic Policy

  1. While editing a Gateway Virtual Server, scroll down to the Policies section, and click the plus icon.
  2. Change the Choose Policy drop-down to Traffic, and then click the blue Continue button.
  3. In the Policy Binding section, click Click to select.
  4. Click the radio button next to the Traffic Policy you created earlier, and then click the blue Select button at the top of the page.
  5. Click the blue Bind button.

Create Authentication Profile

Create and bind an Authentication Profile to link the Gateway Virtual Server to the AAA Virtual Server:

  1. While editing a Gateway Virtual Server, on the right, in the Advanced Settings column, click Authentication Profile.
  2. On the left, scroll down to the Authentication Profile section.
  3. Click Add to create one.
  4. Authentication Profile links the Citrix Gateway vServer with the OTP AAA vServer, so name it accordingly.
  5. In the Authentication Virtual Server section, click Click to select.
  6. Click the radio button next to the OTP AAA vServer, and then click the blue Select button at the top of the page.
  7. Click the blue Create button.
  8. Scroll down again to the Authentication Profile section, and click the blue OK button. Your selection isn’t saved until you click OK.
  9. The Portal Theme bound to the Gateway Virtual Server should be X1, RfWebUI, or a derivative.

Update Content Switching Expression for Unified Gateway

If your Citrix Gateway Virtual Server is behind a Unified Gateway (Content Switching Virtual Server), then you must update the Content Switching Expression to include the manageotp paths.

  1. In the Citrix ADC GUI, navigate to Configuration> Traffic Management > Content Switching > Policies.
  2. On the right, select the Unified Gateway Content Switching Policy, and then click Edit.
  3. Append the following expression under the Expression area, and then click OK. 
    || HTTP.REQ.URL.CONTAINS("/manageotp")

Manageotp User Experience

To access the manageotp web page:

  1. Point your browser to https://mygateway.corp.com/manageotp or similar. Add /manageotp to the end of your Gateway URL.
  2. Notice it’s only single-factor authentication. Login using normal LDAP credentials.
  3. Click Add Device.
  4. Enter a device name, and click Go.
  5. For OTP Push, on your phone, install the Citrix SSO app if it’s not already installed. Then launch it.
    1. Switch to the Password Tokens tab and tap Add New Token.
    2. Tap Scan QR Code.
    3. Then scan the QRCode shown in your browser.
    4. You should see the Device Name. Tap Save.
  6. If OTP Passcode, launch the Google Authenticator application on your phone. Click the plus icon in Google Authenticator, and scan the QRCode that is shown on the screen.
    1. Citrix SSO app also supports passcode.
    2. Christian in the comments indicated that Microsoft Authenticator also works. Click on plus sign -> other (Google,…).
  7. If you configured OTP Push, then you won’t see a Test button. To display the Test button, simply refresh your browser page.
  8. Click Test.
  9. Enter the passcode shown in your Authenticator, and click Go.
    1. Citrix SSO app shows the passcode on the main Password Tokens view.
  10. When done, on the top right, click your name and Log Off.
  11. The OTP registration info is stored in the Active Directory attribute. If users need to re-register, then help desk might need permission to clear this Active Directory attribute.

Perform OTP Authentication

  1. If you access your Gateway URL normally, you’ll be prompted for either one password or two passwords. If one password, then enter your normal LDAP credentials and Citrix Gateway will send a push notification to your phone. If two passwords, then enter the OTP passcode in the second field.
  2. The push notification is shown on the phone’s lock screen. Tap it to open the Citrix SSO app.
  3. Tap Allow to allow the authentication request.
  4. Tap OK when prompted with Logon Success.
  5. After Gateway authentication, Gateway should Single Sign-on into StoreFront with no additional password prompts.

CLI Commands

Here’s a complete OTP nFactor Flow (Visualizer) CLI configuration (except encrypted passwords):

# AAA Global Settings
# -------------------
enable ns feature AAA
set aaa otpparameter -maxOTPDevices 1


# Push Service
# ------------

add authentication pushService cloudPush -namespace "https://mfa.cloud.com/" -clientID b6effb5e-b2d3125 -clientSecret 152c84647b -encrypted -encryptmethod ENCMTHD_3 -CustomerID MyCompan -trustService "https://trust.citrixworkspacesapi.net/"

# LDAP Actions
# ------------
add authentication ldapAction LDAP-Corp -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword a368c -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED -nestedGroupExtraction ON -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN

add authentication ldapAction OTPRegisterDevice -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn admin@corp.local -ldapBindDnPassword 1f952a81 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED -pushService cloudPush -OTPSecret userParameters

add authentication ldapAction LDAPOTPAuthentication -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn admin@corp.local -ldapBindDnPassword 4319b4d7 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -searchFilter "userParameters>=#@" -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED -pushService cloudPush -OTPSecret userParameters


# Advanced Authentication Policies
# --------------------------------
add authentication Policy _OTP-AAA_OTPManageOrAuthenticate__root_0 -rule true -action NO_AUTHN

add authentication Policy SelectManageDevices -rule "http.req.cookie.value(\"NSC_TASS\").eq(\"manageotp\") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)" -action NO_AUTHN

add authentication Policy SelectOTPAuthentication -rule true -action NO_AUTHN

add authentication Policy LDAPAdv -rule true -action LDAP-Corp

add authentication Policy OTPRegisterDevice -rule true -action OTPRegisterDevice

add authentication Policy LDAPOTPAuthentication -rule true -action LDAPOTPAuthentication


# Login Schemas
# -------------
add authentication loginSchema SinglePasswordForManageOTP -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuthManageOTP.xml"

add authentication loginSchema OTPPushOrPasscode -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuthPushOrOTP.xml" -passwordCredentialIndex 1


# Authentication Policy Labels
# ----------------------------
add authentication policylabel OTPManageOrAuthenticate__root -loginSchema LSCHEMA_INT
bind authentication policylabel OTPManageOrAuthenticate__root -policyName SelectManageDevices -priority 100 -gotoPriorityExpression NEXT -nextFactor AuthenticateToManageDevices__OTPManageOrAuthenticate
bind authentication policylabel OTPManageOrAuthenticate__root -policyName SelectOTPAuthentication -priority 110 -gotoPriorityExpression NEXT -nextFactor OTPAuthentication__OTPManageOrAuthenticate

add authentication policylabel AuthenticateToManageDevices__OTPManageOrAuthenticate -loginSchema SinglePasswordForManageOTP
bind authentication policylabel AuthenticateToManageDevices__OTPManageOrAuthenticate -policyName LDAPAdv -priority 100 -gotoPriorityExpression NEXT -nextFactor OTPDeviceRegistration__OTPManageOrAuthenticate

add authentication policylabel OTPAuthentication__OTPManageOrAuthenticate -loginSchema OTPPushOrPasscode
bind authentication policylabel OTPAuthentication__OTPManageOrAuthenticate -policyName LDAPAdv -priority 100 -gotoPriorityExpression NEXT -nextFactor OTPPushOrPasscode__OTPManageOrAuthenticate

add authentication policylabel OTPDeviceRegistration__OTPManageOrAuthenticate -loginSchema LSCHEMA_INT
bind authentication policylabel OTPDeviceRegistration__OTPManageOrAuthenticate -policyName OTPRegisterDevice -priority 100 -gotoPriorityExpression NEXT

add authentication policylabel OTPPushOrPasscode__OTPManageOrAuthenticate -loginSchema LSCHEMA_INT
bind authentication policylabel OTPPushOrPasscode__OTPManageOrAuthenticate -policyName LDAPOTPAuthentication -priority 100 -gotoPriorityExpression NEXT


# Authentication Virtual Servers
# ------------------------------
add authentication vserver OTP-AAA SSL 0.0.0.0
bind authentication vserver OTP-AAA -policy _OTP-AAA_OTPManageOrAuthenticate__root_0 -priority 100 -nextFactor OTPManageOrAuthenticate__root -gotoPriorityExpression NEXT


# Authentication Profiles
# -----------------------
add authentication authnProfile OTP-AAA -authnVsName OTP-AAA


# NetScaler Gateway Session Profiles
# ----------------------------------
add vpn sessionAction AC_OS_10.2.4.120 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://xdc01.corp.local/Citrix/StoreWeb" -ClientChoices OFF -ntDomain corp.local -clientlessVpnMode OFF -storefronturl "https://xdc01.corp.local"

add vpn sessionAction AC_WB_10.2.4.120 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://xdc01.corp.local/Citrix/StoreWeb" -ClientChoices OFF -ntDomain corp.local -clientlessVpnMode OFF


# NetScaler Gateway Session Policies
# ----------------------------------
add vpn sessionPolicy PL_OS_10.2.4.120 "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" AC_OS_10.2.4.120

add vpn sessionPolicy PL_WB_10.2.4.120 "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS" AC_WB_10.2.4.120


# NetScaler Gateway Global Settings
# ---------------------------------
enable ns feature SSLVPN


# NetScaler Gateway Virtual Servers
# ---------------------------------
add vpn vserver gateway2 SSL 10.2.4.220 443 -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -deploymentType ICA_STOREFRONT -authnProfile OTP-AAA -vserverFqdn gateway3.corp.com
bind vpn vserver gateway2 -portaltheme RfWebUI
bind vpn vserver gateway2 -policy LDAP-Corp -priority 100
bind vpn vserver gateway2 -policy PL_OS_10.2.4.120 -priority 100
bind vpn vserver gateway2 -policy PL_WB_10.2.4.120 -priority 100


# SSL Virtual Servers
# -------------------
bind ssl vserver gateway2 -certkeyName WildcardCorpCom.cer_CERT_KEY
bind ssl vserver gateway2 -eccCurveName P_256
bind ssl vserver gateway2 -eccCurveName P_384
bind ssl vserver gateway2 -eccCurveName P_224
bind ssl vserver gateway2 -eccCurveName P_521

bind ssl vserver OTP-AAA -certkeyName WildcardCorpCom.cer_CERT_KEY
bind ssl vserver OTP-AAA -eccCurveName P_256
bind ssl vserver OTP-AAA -eccCurveName P_384
bind ssl vserver OTP-AAA -eccCurveName P_224
bind ssl vserver OTP-AAA -eccCurveName P_521

 

↧

nFactor Authentication – Citrix Gateway 13

June 4, 2019, 9:07 am
$
0
0

Navigation

💡 = Recently Updated

Change Log

nFactor Overview

nFactor lets you configure an unlimited number of authentication factors. You are no longer limited to just two factors.

nFactor seems to be Citrix’s preferred authentication architecture. All authentication mechanisms are moving from Citrix Gateway to nFactor.

Each authentication factor performs the following tasks:

  1. Collect credentials or data from the user. These credentials can be anything supported by Citrix ADC, including:
    • SAML assertion
    • Client Certificate
    • Forms-based authentication (traditional web-based logon page) for LDAP, RADIUS, TACACS, etc. – aka Login Schema
    • Native OTP Push authentication
    • OAuth OpenID Connect
    • Kerberos ticket
    • StoreFrontAuth – authentication is delegated to Citrix StoreFront
    • Endpoint Analysis Scan – either pre-authentication, or post-authentication.
    • EULA
    • Google reCAPTCHA
    • Swivel
    • Use a drop-down to select an authentication method
    • Cookie – e.g. NSC_TASS cookie containing URL path entered after the Gateway/AAA’s FQDN
    • Client IP address
    • No credentials/data – ADC policy expression uses criteria it already has (e.g. collected from a prior factor)
  2. Evaluate the collected credentials. The results can be:
    • No authentication – policy expression is evaluated only to determine next factor
    • Authentication success
    • Authentication failure
    • Group extraction
    • Attribute extraction from SAML, Certificate, JWT, etc.
  3. Based on the evaluation results, do one of the following:
    • Allow access to Gateway or Web site
    • Select next factor
    • Deny access
  4. If there’s a Next Factor, repeat these steps, until there are no more Next Factors to evaluate.

Factors can also be configured only a decision point meaning that the factor does not perform any authentication and instead uses Citrix ADC Policy expressions to select the Next Factor. For example:

  • If client IP is internal, next factor is LDAP only.
  • If client IP is external, next factor is LDAP and then another factor for RADIUS.

Here are some nFactor use cases, but the combinations are almost limitless:

  • Choose Authentication method based on Active Directory group: Logon screen asks for user name only. Extract user’s groups from Active Directory. Based on user’s Active Directory groups, either ask user for client certificate, or ask user for LDAP password. If LDAP, the username doesn’t need to be entered again.
  • Ask for Certificate first:
    • If client certificate is valid, perform LDAP only.
    • If no client certificate, perform LDAP + RADIUS
  • Two-factor with passwords checked in specific order: Display logon screen with two password fields. Check the first password. If the first password succeeds, then check the second password. This lets you check RADIUS before LDAP.
  • Run Endpoint Analysis first:
    • If EPA passes, perform LDAP only.
    • If EPA fails, perform LDAP + RADIUS
  • See Sample Configurations later for many more combinations.

All new authentication methods added to Citrix ADC require nFactor configuration and are not supported on native Citrix Gateway. These new authentication methods include:

nFactor is a AAA feature, which means you need Citrix ADC Advanced Edition or Citrix ADC Premium Edition. Citrix ADC Standard Edition and Citrix Gateway VPX are not entitled for nFactor.

Citrix ADC supports two types of authentication policies – Classic, and Advanced (aka Default). You can bind Classic Authentication Policies directly to Citrix Gateway Virtual Servers, but today you cannot bind Advanced Authentication Policies to Citrix Gateway. The only way to use Advanced Authentication Policies with Citrix Gateway is to configure nFactor on a AAA Virtual Server and then link the AAA Virtual Server to the Gateway Virtual Server.

Workspace app 1809 and newer with Citrix Gateway 12.1 build 49 and newer support nFactor authentication. Older Receivers and older NetScalers don’t support nFactor, so you’ll instead have to use a web browser.

nFactor High-level Configuration

Here’s a high level summary of nFactor configuration objects. Detailed instructions are provided later in this article.

Each factor is a Policy Label that combines Advanced Authentication Policies and Login Schema.

  • Login Schema is a XML file that nFactor uses to create a custom HTML form where users enter credentials.
    • Login Schemas are optional depending on the authentication method you are configuring.
  • If an Advanced authentication policy expression evaluates to true, then an authentication action is performed.
    • Citrix ADC has many different types of authentication actions.
    • nFactor authentication policy expressions use Advanced Syntax (Default Syntax) instead of the older Classic Syntax expression traditionally used in Citrix Gateway authentication policies. An example Advanced syntax expression is true. An example classic syntax expression is ns_true.
    • When binding an Advanced authentication policy to a Policy Label or AAA vServer, you can optionally select a Next Factor, which is another Policy Label.
      • If the authentication action is successful, then nFactor processes the configured Next Factor.
      • If Next Factor is not configured, then nFactor is complete and authentication is successful.
    • If the authentication action fails, then the next lower priority (higher priority number) authentication policy in the same factor is evaluated. If there are no more authentication policies in the same factor, then the entire nFactor authentication flow failed.

AAA vServer – nFactor configuration is always bound to a AAA vServer, even if you want to use nFactor with Citrix Gateway.

  • An Authentication Profile links the AAA vServer with Citrix Gateway.

nFactor Configuration methods – Citrix ADC 13 has two methods of configuring nFactor:

  • ADC 13 adds nFactor Flow Visualizer, which makes it easy to link the Factors (Policy Labels) together.
    • After creating a Flow, you bind the Flow to a AAA Virtual Server.
  • Manually – Create Policy Labels, Login Schemas, Authentication Policies/Actions, and manually bind them together and to a AAA Virtual Server. This is the only method available in ADC 12.1 and older.
    • For the first factor, you bind Authentication Policies/Actions and Login Schemas directly to a AAA Virtual Server without using a Policy Label.
    • All other factors are Policy Labels linked using the Next Factor bind points.

The Visualizer is a better option for understanding the nFactor flow, but neither method is flexible:

  • If you want to rename factors, then you have to delete the factor and remake it.
  • You can’t change a factor’s Login Schema without deleting and remaking the factor.
  • Visualizer does not let you delete factors. Instead, you can either delete the Policy Label outside of the flow configuration, or you can delete the entire flow and start over.
  • With Manual method, it is difficult to rearrange factors, especially since the first factor is not a Policy Label like the other factors. Visualizer lets you graphically change how the factors are linked together.
  • The Manual method is typically configured from bottom up which makes it difficult to understand the entire nFactor flow.

Also see:

This article will detail how to use the Manual method to configure nFactor from top to bottom:

  1. Create AAA vServer
  2. Create First Factor:
    1. Create Login Schema Profile
    2. Create Login Schema Policy – only for first factor – if policy expression is true, then display Login Schema
    3. Create Authentication Actions – LDAP, RADIUS, etc.
    4. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
    5. Edit AAA vServer, bind Login Schema, and bind Authentication Policies
  3. Create Next Factor:
    1. Create Login Schema Profile
    2. Create Authentication Actions – LDAP, RADIUS, etc.
    3. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
    4. Create Authentication Policy Label, select Login Schema, and bind Advanced Authentication Policies
    5. Edit AAA vServer, edit Authentication Policy binding, and configure Next Factor to this Policy Label
  4. Create Next Factor:
    1. Create Login Schema Profile
    2. Create Authentication Actions – LDAP, RADIUS, etc.
    3. Create Advanced Authentication Policies – if policy expression is true, then perform authentication action
    4. Create Authentication Policy Label, select Login Schema, and bind Advanced Authentication Policies
    5. Edit other Policy Label, edit Authentication Policy binding, and configure Next Factor to this Policy Label
  5. Continue creating Factors and linking them until the flow configuration is complete.
  6. Create Citrix Gateway Traffic Policy for Single Sign-on to StoreFront.
  7. Edit existing Citrix Gateway, create Authentication Profile, and bind Traffic Policy

Once you are familiar with nFactor, due to the way the objects are linked together, it’s probably easier to configure nFactor from bottom up:

  1. Create Authentication Actions for all factors – LDAP, RADIUS, etc.
  2. Create Advanced Authentication Policies for all factors
  3. Create Login Schema Profiles for all factors
  4. Create Authentication Policy Labels for all factors except the first factor.
    1. Start with leaf (bottom) factors so you can configure Next Factor when binding authentication policies in higher branch factors. For example, if your flow is Collect Username –> Perform LDAP –> Perform RADIUS, then create the RADIUS Policy Label first so you can link to it when creating the LDAP Policy Label.
  5. Create Login Schema Policy for first factor
  6. Create AAA vServer – bind Login Schema, bind Authentication Policies, and select Next Factor Policy Label
  7. Create Citrix Gateway Traffic Policy for Single Sign-on to StoreFront.
  8. Create Authentication Profile
  9. Edit existing Citrix Gateway, create Authentication Profile, and bind Traffic Policy

It can be difficult to visualize a manually-created nFactor configuration so my ADC Virtual Server Configuration Extractor script now includes a nFactor visualizer. Here’s an example for a Native OTP configuration.

AAA Virtual Server

Create AAA Virtual Server

nFactor is always configured on a AAA Virtual Server. Then you later link the AAA Virtual Server to the Citrix Gateway Virtual Server.

  1. If the AAA feature is not already enabled, on the left menu, expand Security, right-click AAA – Application Traffic, and click Enable Feature.
  2. Go to Security > AAA > Virtual Servers.
  3. On the right, click Add.
  4. Give the Virtual Server a name.
  5. If this AAA Virtual Server is only for Citrix Gateway, then you can change the IP address Type to Non Addressable.
  6. Click OK.
  7. For a non-addressable AAA vServer, configuring the certificate is optional, but the AAA vServer will be DOWN (red) without a certificate. The AAA vServer still works even if its status is DOWN. Binding a certificate will change the AAA vServer’s status from DOWN to UP (green).
    1. In the Certificates section, click where it says No Server Certificate.
    2. In the Server Certificate Binding page, click where it says Click to select.
    3. Click the radio button next to a certificate for the AAA Virtual Server, and click Select. Since this AAA Virtual Server is not directly addressable, the chosen certificate doesn’t matter.
    4. Click Bind.
  8. Click Continue to close the Certificate section.
  9. You probably haven’ts created any Advanced Authentication Policies yet, so just click Continue. Note that this is where you bind the authentication policies for the first factor.

Bind Portal Theme to AAA Virtual Server

If this AAA Virtual Server is used not just for Citrix Gateway but also directly addressable for traffic management (Load Balancing, Content Switching), then you might want to change the AAA Portal theme.

  1. Go to Citrix Gateway > Portal Themes, and add a theme. You create the theme under Citrix Gateway, and then later bind it to the AAA Virtual Server.
  2. Create a theme based on the RfWebUI Template Theme.
  3. After adjusting the theme as desired, at the top of the portal theme editing page, click the link labelled Click to Bind and View Configured Theme.
  4. Change the selection to Authentication.
  5. Use the Authentication Virtual Server Name drop-down to select the AAA Virtual Server, and click Bind and Preview. You can close the preview window.

Client Certificate Authentication

If one of your authentication Factors is client certificate, then you must perform some SSL configuration on the AAA Virtual Server:

  1. Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Root certificates do not have a key file.


  2. Go to Traffic Management >SSL > Change advanced SSL settings.
    1. Scroll down. If you see Default Profile: ENABLED, then you must use an SSL Profile to enable Client Certificate Authentication. Otherwise, you can enable Client Certificate Authentication directly on the AAA Virtual Server in the SSL Parameters section.
  3. If Default SSL Profiles are enabled, then create a new SSL Profile with Client Authentication enabled:
    1. On the left menu, expand System, and click Profiles.
    2. On the top right, switch to the tab named SSL Profile.
    3. Right-click the ns_default_ssl_profile_frontend profile, and click Add. This copies settings from the default profile.
    4. Give the Profile a name based on this goal: enable Client Certificates.
    5. Scroll down and find the Client Authentication checkbox. Check the box.
    6. Change the Client Certificate drop-down to OPTIONAL.
    7. Scroll down and click OK to close the Basic Settings section.
    8. Copying the default SSL Profile does not copy the SSL Ciphers so you’ll have to redo them.
    9. Click Done when done creating the SSL Profile.
    10. Go to Security > AAA – Application Traffic > Virtual Servers, and edit a AAA vServer.
    11. Scroll down to the SSL Profile section and click the pencil.
    12. Change the SSL Profile drop-down to the profile that has Client Certificates enabled. Click OK.
    13. Scroll down this article until you reach the instructions to bind the CA certificate.
  4. Go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server you’re using for nFactor.
  5. If default SSL Profiles are not enabled:
    1. On the left, scroll down to the SSL Parameters section, and click the pencil icon.
    2. Check the box next to Client Authentication.
    3. Make sure Client Certificate drop-down is set to Optional.
    4. Click OK to close the SSL Parameters section.
  6. On the left, scroll up to the Certificates section, and click where it says No CA Certificate. Do this whether you are using SSL Profiles or not.
    1. In the CA Certificate Binding page, click Click to select.
    2. Click the radio button next to the root certificate for the issuer of the client certificates, and then click the blue Select button on the top of the page.
    3. Click Bind.

Login Schema

Login Schema XML File

Login Schema is an XML file providing the structure of forms-based authentication logon pages.

nFactor implies multiple authentication Factors that are chained together. Each Factor can have different Login Schema pages/files. In some authentication flows, users could be presented with multiple logon screens.

Or you can have one Login Schema gather information that can be passed on to multiple Factors, so that the later Factors don’t need to display another Login Schema. This is particularly useful for traditional two-password logon screens (LDAP + RADIUS), since each password is evaluated in a separate Factor:

  • The first password is evaluated in the first factor (e.g. LDAP). If successful, then evaluate the Next Factor.
  • The second factor (e.g. RADIUS) evaluates the second password. However, the second password has already been entered, so there’s no need to ask the user for it again. To prevent the second factor from showing another Login Schema to the user, select noschema (LSCHEMA_INT) in the Authentication Policy Label.

Several Login Schema .xml files are included with Citrix ADC under /nsconfig/loginschema/LoginSchema.

In the Citrix ADC management GUI, when creating or editing a Login Schema entity, you can Edit the labels. Citrix ADC copies the modified Login Schema to a new .xml file based on the Schema Name entered in this widow, or based on the original file name.

Or you can use WinSCP to connect to the appliance, duplicate one of the existing .xml files, and edit it as desired. For example, you can configure fields (InitialValue tag) to pre-fill information from previous Factors, as shown below:

The structure of the Login Schema file is documented at Citrix Common Authentication Forms Language Citrix Developer Documentation.

CTP Sam Jacobs at SYN229 – nFactor and Login Schemas explains how to customize the .xml file.

The login schema can contain a domain drop-down. See CTX201760 nFactor – Domain Drop-Down in First Factor then Different Policy Evaluations Based on Groups for a sample configuration.

Login Schema and Authentication Factor can be a EULA. See Citrix CTX226488 How to Configure EULA as an Authentication Factor in NetScaler nFactor.

Citrix CTX219545 Custom Login Labels in NetScaler nFactor Authentication: add a Requirement element with a Label sub-element to the Login Schema .xml file. Then use JavaScript to populate the label with any desired HTML. Another example is Morten Kallesoee nFactor – adding custom links.

Several more samples can be found later.

Login Schema Profile

Login Schemas define a user interface (web page form) that is shown to the user. Login Schema Profiles are bound directly to Policy Labels (aka Factors). After the user fills out the form and submits it, nFactor uses the submitted form fields to evaluate the authentication policies bound to the same Policy Label.

To create a Login Schema Profile:

  1. Create or Edit a Login Schema .XML file based on your nFactor design.
  2. Go to Security > AAA > Login Schema.
  3. On the right, switch to the tab named Profiles and click Add.
  4. Name the Login Schema.
  5. In the Authentication Schema field, click the pencil icon.
  6. The window expands to show Login Schema Files. Click the LoginSchema folder to see the files in it.
  7. Select one of the files. You can see a preview on the right.
  8. The labels can be changed by clicking the Edit button on the top right.
  9. When you Save the changes, a new file is created under /nsconfig/LoginSchema.
  10. The top of the screen shows the new file name. You’ll have to go up a folder and select the new file instead of the folder you’re looking at.
  11. Next to each file is an icon to download the file so you can modify the XML and then upload a new copy.
  12. Once you’ve found the file you want and clicked it to preview it, then on the top right, click the blue Select button. You might be tempted to click the blue Create button on the bottom of the screen but don’t do that until you have clicked the blue Select button.
  13. After you click the blue Select button, the window collapses. Look in the Authentication Schema field to make sure you selected the correct file.
  14. Click More.
  15. You typically need to save the entered credentials so you can use them later in a Single Sign-on flow to a back-end server (e.g. Citrix StoreFront). Near the bottom of the Login Schema Profile, enter a unique value between 1 and 16 for the Password Credential Index .
    • Later you reference the index value in a Traffic Policy/Profile by using the expression AAA.USER.ATTRIBUTE(#).
    • Each Login Schema can store different credentials in different indexes.
  16. Click Create to create the Login Schema profile.

If you later edit the Login Schema .xml file using WinSCP or similar, then the changes to the file might not be reflected until you edit the Login Schema Profile, and click the blue Select button for the .xml file again.

Login Schema Policy

For most factors, you can bind a Login Schema Profile directly to a Policy Label. However, the first factor is bound directly to the AAA vServer and does not use a Policy Label. To bind a Login Schema directly to a AAA vServer, you must first create a Login Schema Policy. You don’t need Login Schema Policies for any factor other than the first one.

To create a first factor Login Schema Policy:

  1. In the left menu, go to Security > AAA > Login Schema.
  2. On the right, switch to the tab named Policies, and click Add.
  3. Use the Profile drop-down to select the Login Schema Profile you already created.
  4. Enter a Default Syntax expression (e.g. true) in the Rule box.
    1. For the first factor, you can use policy expressions to control whether a Login Schema is shown to the user or not. For example, you might bind two Login Schemas to the AAA vServer but have a policy expression that only shows a Login Schema if the client IP is in the internal network instead of from the Internet.
    2. Policy expressions only apply to the first factor; subsequent factors (Policy Labels) always show their Login Schema.
  5. Click the blue Create button when done.

Bind first factor Login Schema to AAA vServer:

  1. On the left, go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
  2. On the right, in the Advanced Settings column, click Login Schemas.
  3. On the bottom left, in the Login Schemas section, click where it says No Login Schema.
  4. In the Policy Binding window, click where it says Click to select.
  5. Click the radio button next to the Login Schema policy, and then click the blue Select button on the top of the window. Only Login Schema Policies appear in this list. Login Schema Profiles (without a policy) do not appear.
  6. Click Bind.

Authentication Policies

Authentication policies are a combination of policy expression, and policy action. If the expression is true, then perform the authentication action.

  • The Action is an authentication server (LDAP, RADIUS, etc.), or no authentication (i.e. do nothing, typically for selecting a Next Factor).
  • For nFactor, the policy expression must be in the newer default syntax, not the older classic syntax.

You typically create at least one Authentication Policy for each Factor. When you bind multiple Authentication Policies to one Factor, Citrix ADC checks each authentication policy in priority order until one of them succeeds.

Note: Citrix Gateway 12.0 and newer have deprecated Basic Authentication Policies (Classic Syntax). The only way to bind an Advanced Authentication Policy (Default Syntax) to Gateway is through nFactor and AAA.

Create Authentication Actions

Authentication Policies need configured Authentication Servers (e.g. LDAP, RADIUS, CERT, SAML, etc.). You can create Authentication Actions (Servers) prior to creating the Authentication Policy.

  • In the left menu, go to Authentication > Dashboard. On the right, click Add.
    • Select a Server Type. The instructions for creating these Authentication Servers are not detailed here. Some of them are detailed at the Authentication – Citrix ADC 13 procedures.
  • Or in the left menu, you can find all of the Action types under Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions.
  • Or when creating an Authentication Policy, there’s a Add button that lets you create Authentication Actions/Servers.

LDAP Group Extraction

Sometimes you need to extract a user’s groups from Active Directory without authenticating. These extracted groups can then be used to select the next authentication Factor.

To configure an LDAP Action/Server for only group extraction:

  1. When creating or editing an LDAP Server/Action for only group extraction, make sure Authentication is unchecked.
  2. On the left, in the Other Settings section, make sure Group Attribute and Sub Attribute Name are filled in.

Create Authentication Policies

Once you’ve created your Authentication Actions, you can now create an Advanced Authentication Policy that links an expression to the Action:

  1. Go to Security > AAA > Policies > Authentication > Advanced Policies > Policy.
  2. On the right, click Add.
  3. Name your Authentication Policy.
  4. Use the Action Type drop-down to select the Action Type (e.g. LDAP). Typically each Factor is a different type of Authentication Action.
    1. If you don’t want to perform authentication, then select NO_AUTHN as the Action Type. This is useful if you only want to use this Authentication Policy expression to choose a Next Factor.
  5. If you don’t currently have any Actions configured, or if you want to create a new one, click the Add button next to the Action drop-down. The Actions/Servers are created in the normal fashion (not detailed here).
  6. In the Expression box, enter an expression using the Default Syntax. ns_true won’t work because that’s Classic syntax. There’s an Expression Editor link on the right. Or hit Ctrl+Space to see your options. true is a valid Default expression.
  7. Click Create when done.
  8. Continue creating one or more Authentication Policies for each of your Factors.

Bind First Factor to AAA

For all factors except the first factor, the Authentication Policies are bound to Authentication Policy Labels as detailed in the next section.

However, since the first factor doesn’t use a Policy Label, you instead bind the first factor’s Authentication Policies directly to the AAA vServer.

  1. Go to Security > AAA > Virtual Servers.
  2. Edit an existing AAA Virtual Server.
  3. On the left, in the Advanced Authentication Policies section, click where it says No Authentication Policy.
  4. In the Policy Binding page, click where it says Click to select.
  5. Click the radio button next to the first factor’s Advanced Authentication Policy, and then click the blue Select button at the top of the page. Only Advanced Authentication Policies appear in this list. Classic Authentication Policies do not appear.
  6. In the Binding Details section, if this Advanced Authentication Policy fails, then the Goto Expression determines what happens next. If it is set to NEXT, then the next Advanced Authentication Policy bound to this AAA Virtual Server is evaluated. If it is set to END, or if there are no more Advanced Authentication Policies bound to this AAA Virtual Server, then authentication is finished and marked as failed.
  7. The Select Next Factor field can optionally point to an Authentication Policy Label as detailed in the next section. The Next Factor is only evaluated if this Advanced Authentication Policy succeeds. You can bind a Policy Label later since you probably don’t have any yet.
  8. Click Bind.
  9. You can optionally bind more Authentication Policies and they will be evaluated in priority order. If one of the Authentication Policies succeeds, then nFactor moves to the Next Factor and the remaining Authentication Policies in this factor are ignored.

Authentication Policy Label

For all factors except for the first factor, you create a Policy Label for each factor, and then bind the Policy Labels to the various Next Factor authentication policy bind points in the nFactor flow.

Authentication Policy Labels contain two objects:

  • Login Schema
  • Advanced Authentication Policies

The Authentication Policies can have a Next Factor link to a different Policy Label. Factors are chained together through the Next Factor links.

Here’s the nFactor authentication flow:

  1. User connects to a AAA or Citrix Gateway Virtual Server.
    1. Citrix Gateway uses an Authentication Profile to select a AAA vServer than has a nFactor configuration.
  2. The Login Schema bound to the AAA Virtual Server is displayed to the user.
  3. Advanced Authentication Policies bound to the AAA Virtual Server are evaluated.
    1. If the Advanced Authentication Policy succeeds, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
    2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
    3. If none of the Advanced Authentication Policies succeed, then authentication failed.
  4. If the Next Factor Authentication Policy Label has a Login Schema bound to it, display it to the user.
  5. Evaluate the Advanced Authentication Policies bound to the Next Factor Authentication Policy Label.
    1. If the Advanced Authentication Policy succeeds, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
    2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
    3. If none of the Advanced Authentication Policies succeeds, then authentication failed.
  6. Continue evaluating the Next Factor Authentication Policy Label until authentication succeeds or fails. You can chain together an unlimited number of Authentication Policy Labels.

When binding a Login Schema to an Authentication Policy Label, you only need the Login Schema Profile. There’s no need to create a Login Schema Policy.

Not every Factor needs a Login Schema. It’s possible for a prior Factor to gather all of the credential information and simply pass it on to the next Factor. If you don’t need a Login Schema for a particular Authentication Policy Label, simply select LSCHEMA_INT, which is mapped to noschema. Or create a new Login Schema Profile based on noschema.

Create Authentication Policy Label

To create an Authentication Policy Label:

  1. Authentication Policy Labels (Factors) are configured at Security > AAA > Policies > Authentication > Advanced Policies > Policy Label.
  2. On the right, click Add.
  3. Give the Policy Label a name which identifies this factor.
  4. Select a Login Schema Profile or click the Add button to create one.
    • If you don’t want this factor to display anything to the user, then select LSCHEMA_INT.
  5. Click Continue. Note: you won’t be able to change the Login Schema later. But you can create a new Policy Label with a different Login Schema.
  6. In the Policy Binding section, click where it says Click to select.
  7. Click the radio button next to an Advanced Authentication Policy that evaluates this Factor and then click the blue Select button at the top of the page.
  8. Use the Goto Expression drop-down to select NEXT or END. If you want to bind more Advanced Authentication Policies to this Factor, then select NEXT.
  9. In the Select Next Factor field, if you want to chain to another Factor, click where it says Click to select, and bind the next Authentication Policy Label (Next Factor).
    • If you haven’t created the Policy Label for the next factor yet, you can either do it now by clicking the Add button, or return here later after you create the next Policy Label.
    • If you don’t configure a Next Factor, and if this Advanced Authentication Action succeeds, then authentication is successful and complete.
  10. Click Bind when done.
  11. You can optionally click Add Binding to add more Advanced Authentication Policies to this Policy Label (Factor). If any one of the Authentication Policies succeeds, then nFactor moves to the Next Factor and ignores the remaining Authentication Policies in this factor.
  12. When done, click Done.
  13. If you edit the Policy Label you created, notice that it’s not possible to change the Login Schema. The only way to change the Login Schema is to create a new Policy Label.

Bind Authentication Policy Label to Next Factor

Once the Policy Label (Factor) is created, you link to it from an existing Authentication Policy binding. You can select a Next Factor (Policy Label) in two places:

  • Edit an existing AAA Virtual Server that has an Authentication Policy (first factor) already bound to it and edit the binding to include the Next Factor.
  • Edit a different Policy Label, and edit an Advanced Authentication Policy binding to include the Next Factor.

To link to a Policy Label Next Factor from a AAA Virtual Server first factor:

  1. Edit an existing AAA Virtual Server that has an Advanced Authentication Policy already bound to it.
  2. On the left, in the Advanced Authentication Policies section, click the existing Authentication Policy bindings.
  3. Right-click an existing binding, and click Edit Binding.
  4. In the Select Next Factor field, click where it says Click to select.
  5. Click the radio button next to the Policy Label for the Next Factor, and then click the blue Select button at the top of the page.
  6. Click Bind.
  7. In the list of bound Authentication Policies, the far right shows the Next Factor.
  8. Click Close.

To link to a Policy Label Next Factor from a different Policy Label:

  1. Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy Label.
  2. On the right, edit a different Policy Label.
  3. Right-click an existing Authentication Policy binding and click Edit Binding.
  4. In the Binding Details section, next to Select Next Factor, click Click to select.
  5. Click the radio button next to a Policy Label for the next factor, and then click the blue Select button at the top of the window.
  6. Click Bind.
  7. In the list of bound Authentication Policies, on the far right, you can see the configured Next Factor.
  8. Click Done to close the Policy Label.
  9. Repeat linking Policy Labels (Factors) together until your nFactor flow configuration is complete.

nFactor Flow Visualizer

ADC 13 and newer have a nFactor Flow Visualizer that you can use to create flows like this:

Find the Visualizer under Security > AAA – Application Traffic > nFactor Visualizer > nFactor Flows

For an example usage of this tool, see Native One Time Passwords (OTP) – Citrix Gateway 13.

Here are some differences for the Visualizer method vs the manual method detailed in this article:

  • Manual: First factor without Policy Label – With the manual method, the first factor is bound to the AAA vServer without using a Policy Label.
    • Visualizer: First Factor is a Policy Label – The Visualizer creates a Policy Label for the first factor. Then it binds the Policy Label to the AAA vServer.
  • Manual: Login Schema Policies for First Factor – With the manual method, you create Login Schema Policies to bind the first factor’s Login Schema to the AAA vServer. Login Schema Policies have expressions that are evaluated to determine if the Login Schema should be shown or not. This lets you bind multiple Login Schemas to the AAA vServer and a policy expression determines which Login Schema is shown to the user.
    • Visualizer: no Login Schema Policies – The Visualizer does not support Login Schema Policies and thus the Login Schema configured for a Factor is always shown.

For more information, see nFactor Visualizer for simplified configuration at Citrix Docs.

nFactor for Citrix Gateway

All nFactor configuration is performed in the menu under Security > AAA – Application Traffic. When done, your nFactor Flow should be bound to a AAA vServer.

To enable nFactor for a Citrix Gateway Virtual Server, you simply create an Authentication Profile and bind it to the Gateway Virtual Server. If you unbind the Authentication Profile from the Gateway Virtual Server, then nFactor is no longer used by that Gateway.

AAA Authentication Profile

Authentication Profile links a AAA Virtual Server to Citrix Gateway and enables nFactor on Citrix Gateway.

  1. Go to Citrix Gateway > Virtual Servers.
  2. On the right, edit an existing Citrix Gateway Virtual Server.
  3. On the right, in the Advanced Settings column, click Authentication Profile.
  4. On the bottom left, click the Add button next to the Authentication Profile drop-down.
  5. Give the Authentication Profile a name.
  6. In the Authentication Virtual Server field, click where it says Click to select.
  7. Click the radio button next to the AAA Virtual Server that has nFactor configured. The AAA Virtual Server does not need an IP address. Then click the blue Select button at the top of the page.
  8. Then click Create.
  9. And click OK to close the Authentication Profile section. The Authentication Profile isn’t enabled until you click this OK button.
  10. Note: the Authentication Profile enables nFactor, which overrides any authentication policies that are bound to the Gateway Virtual Server.
  11. If one of your Factors is client certificates, then you’ll need to configure SSL Parameters and CA certificate as detailed in the next section.
  12. When you browse to your Gateway, you’ll see the Login Schema that is bound to the AAA Virtual Server.
  13. Workspace app 1809 and newer with Gateway/ADC 12.1 build 49 and newer should support nFactor authentication. Older clients with older builds do not support nFactor, so those users will have to use a web browser.

Gateway and Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the Citrix Gateway Virtual Server:

  1. Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Certificate Authority certificates do not need key files.
  2. If default SSL Profiles are enabled, then you should have already created an SSL Profile that has Client Authentication enabled.
  3. Go to Citrix Gateway > Virtual Servers, and edit an existing Citrix Gateway Virtual Server that is enabled for nFactor.
  4. If default SSL Profiles are enabled:
    1. Scroll down to the SSL Profile section, and click the pencil icon.
    2. In the SSL Profile drop-down, select the SSL Profile that has Client Authentication enabled and set to OPTIONAL. Then click OK.
  5. If default SSL Profiles are not enabled:
    1. On the left, in the SSL Parameters section, click the pencil icon.
    2. Check the box next to Client Authentication.
    3. Make sure Client Certificate drop-down is set to Optional, and click OK.
  6. For both Default SSL Profile and SSL Parameters, on the left, in the Certificates section, click where it says No CA Certificate.
  7. In the CA Certificate Binding page, click where it says Click to select.
  8. Click the radio button next to the root certificate for the issuer of the client certificates, and click the blue Select button at the top of the page.
  9. Click Bind.
  10. You might have to also bind any Intermediate CA Certificates that issued the client certificates.

Traffic Policy for nFactor Single Sign-on to StoreFront

When performing Single Sign-on to StoreFront, nFactor defaults to using the last entered password. If LDAP is not the last entered password (e.g. RADIUS), then you need to create a Traffic Policy/Profile to override the default nFactor behavior.

  1. Go to Citrix Gateway > Policies > Traffic.
  2. On the right, switch to the tab named Traffic Profiles.
  3. Click Add.
    1. Give the Traffic Profile a name.
    2. In the Protocol section, select HTTP.
    3. Set the Single Sign-on drop-down to ON. Scroll down.
    4. In the SSO Expression fields, enter an AAA.USER.ATTRIBUTE(#) expression that matches the indexes specified in the Login Schema.
    5. Click Create.
  4. On the right, switch to the tab named Traffic Policies, and click Add.
    1. Give the policy a name.
    2. Select the previously created Traffic Profile.
    3. Enter an Advanced Expression (e.g. true), and click Create.
  5. Edit an existing Citrix Gateway Virtual Server.
  6. Scroll down to the Policies section and click the plus icon.
  7. In the Choose Type page, select Traffic > Request, and click Continue.
  8. Select the previously created Traffic Policy, and click Bind.

Sample Configurations

From Citrix Docs: Sample deployments using nFactor authentication:

  • Get two passwords up-front, then pass-through the second password to the next factor. Read
  • Username and 2 passwords, then group extraction in third factor. Read
  • Configure nFactor to process the second password before the first password, Read
  • Modify first factor username for use by second factor. Read
    • NO_AUTHN authentication policy expression checks first factor POST Body login value for UPN format. If true, Next Factor is noschema Login Schema with User Expression that transforms the HTTP.REQ.USER.NAME to DOMAIN\Username before passing to second factor authentication policy.
  • Group extraction followed by certificate or LDAP authentication, based on group membership. Read

  • SAML followed by LDAP or certificate authentication, based on attributes extracted during SAML. Read
  • SAML in first factor, followed by group extraction, and then LDAP or certificate authentication, based on groups extracted. Read
  • Capture email address in first factor, and then choose one of multiple SAML iDP based on email address suffix. Read (Manuel Kolloff)

  • Prefill user name from certificate. Read
  • Certificate authentication followed by group extraction for 401 enabled traffic management virtual servers. Read
  • Certificate fallback to LDAP in same cascade; one virtual server for both certificate and LDAP authentication. Read
  • LDAP in first factor and WebAuth in second factor. Read
  • WebAuth in first factor, LDAP in second factor. Read
  • Domain drop down in first factor, then different policy evaluations based on selected domain. Read
    • Domain drop-down, then send Domain\Username to RADIUS.  Read
  • Google reCAPTCHA first factor, LDAP second. Read (George Spiers)
  • Supporting reCaptcha with Citrix ADC nFactor. Read
  • CTX225938 nFactor – Customizing UI to Display Images – e.g. Swivel
  • Use EPA (Endpoint Analysis) in nFactor flows . See CTX223597 Concepts and Entities Used for EPA in nFactor Authentication Through NetScaler.
  • Configure Post-Authentication EPA (Endpoint Analysis) Scan as a Factor. Read
  • Configure Pre-Authentication EPA (Endpoint Analysis) Scan as a Factor. Read
  • Configure EULA (End User License Agreement) as an Authentication Factor. Read
  • Show a drop-down box in the logon form and automatically hide or show certain fields based on drop-down selection. Read

  • Step-up authentication – i.e. one Unified Gateway website needs single factor, while other website needs multi-factor. Read
  • RADIUS authentication with reversed PIN – if user enters reversed PIN, then user is under duress. This sample configuration has some interesting components:  Read
    • Policy Extension Function using the Lua language
      • Usage = HTTP.REQ.BODY(1000).TYPECAST_NVLIST_T(’=’,’&’).VALUE(”passwd1”).RPIN
    • Citrix ADC Variable of type Map with Expiration timer
      • Responder to set the variable
      • Variable identifies duress state for four hours
    • Custom syslog message (audit messageaction) triggered by a Responder
    • Default Authentication Group to put duressed user on site/farm with Session Recording enabled
    • nFactor sequence:

Certificate auth: If Successful, LDAP only. If Failure, LDAP+RADIUS

This scenario is described in Citrix Blog Post Configuration Notes on nFactor

The authentication process flows like this:

  1. User connects to Citrix Gateway.
  2. Citrix Gateway asks user for certificate.
  3. If user selects a certificate, Citrix Gateway compares certificate signature to the CA certificate that is bound to the Citrix Gateway. If it doesn’t match, then user certificate is ignored.
  4. Bound to the Citrix Gateway Virtual Server is an Authentication Profile, which links Citrix Gateway to AAA nFactor.
  5. Certificate authentication: The lowest priority number authentication policy on the AAA Virtual Server is Certificate. If there’s a valid user certificate:
    1. Extract the user’s userPrincipalName from the certificate.
    2. Next Factor = policy label that displays a logon screen (Single-factor Login Schema)
    3. The username field is pre-populated with the userPrincipalName attribute extracted from the certificate.
    4. User is prompted to enter the LDAP password only.
    5. LDAP policy/server is configured to use userPrincipalName to login to LDAP.
    6. If successful, Citrix Gateway authentication is complete. Next step is to Single Sign-on to StoreFront.
    7. If LDAP authentication fails, then Citrix Gateway authentication fails, and the user is prompted to try LDAP-only authentication again.
  6. LDAP authentication: If certificate authentication fails, try next authentication policy bound to the AAA Virtual Server, which is a different LDAP Policy.
    1. Bound to the AAA Virtual Server is a Dual Factor Login Schema that asks for username, LDAP password, and RADIUS password.
    2. LDAP policy/server is configured to use sAMAccountName to login to LDAP. SAMAccountName means users don’t have to enter full userPrincipalName.
    3. If LDAP authentication is successful:
      1. Put username in Credential Index 1 and put password in Credential Index 2. These will later be used by a Traffic Policy to Single Sign-on to StoreFront.
      2. Proceed to next factor (Policy Label), which is RADIUS.
    4. If LDAP authentication fails, Citrix Gateway login fails, and the user is prompted to try two-factor authentication again.
  7. RADIUS authentication: the second factor Policy Label is configured with Noschema. This means no additional logon form is displayed because the RADIUS password was already collected in the previous factor.
    1. When multiple passwords are collected, they are tried in order. The first password was used by the previous factor. The second password is tried by this factor (Policy Label).
    2. RADIUS policy/profile attempts authentication.
    3. If RADIUS authentication is successful, Citrix Gateway authentication is complete. Next step is Single Sign-on to StoreFront.
    4. If RADIUS authentication fails, Citrix Gateway login fails, and the user is prompted to try two-factor authentication again.
  8. Single Sign-on to StoreFront: Citrix Gateway uses the last password collected by nFactor to Single Sign-on with StoreFront. If the last password is LDAP, then no additional configuration is needed. If the last password is not LDAP, then a Traffic Policy/Profile is needed.
    1. Bound to the Citrix Gateway Virtual Server is a Traffic Policy.
    2. The Traffic Policy/Profile users Credential Index 1 for username and Credential Index 2 for Password. These are the same indexes configured in the Dual Factor Login Schema.

The order of configuration shown below doesn’t match the authentication flow because some objects have to be created before others. This is the bottom-up approach.

# Create Auth vServer, bind server cert, bind CA cert for client certificates
# Enable Optional client certificates
add authentication vserver nFactorAAA SSL 0.0.0.0 443
bind ssl vserver nFactorAAA -certkeyName WildCorpCom
bind ssl vserver nFactorAAA -certkeyName CorpRoot -CA -ocspCheck Optional
set ssl vserver nFactorAAA -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED

# Create auth policy for LDAP-UPN. UPN is extracted from certificate.
add authentication ldapAction Corp-UserPrincipalName -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-UserPrincipalName -rule true -action Corp-UserPrincipalName

# Create PolicyLabel LDAPPasswordOnly with Single-factor Login Schema
# Login Schema has InitialValue with username from certificate.
add authentication loginSchema SingleAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth-Corp.xml"
add authentication policylabel LDAPPasswordOnly -loginSchema SingleAuth
bind authentication policylabel LDAPPasswordOnly -policyName Corp-UserPrincipalName -priority 100 -gotoPriorityExpression NEXT

# Create Cert policy and bind to AAA vServer with LDAPPasswordOnly PolicyLabel as Next Factor
# Cert policy must have lower priority number (higher priority) than LDAP-SAM policy
# Cert is evaluated first. If succeed, ask for LDAP password. If fails, ask for two factor.
add authentication certAction Cert_Auth_Profile -userNameField SubjectAltName:PrincipalName
add authentication Policy Cert_Auth_Policy -rule true -action Cert_Auth_Profile
bind authentication vserver nFactorAAA -policy Cert_Auth_Policy -priority 100 -nextFactor LDAPPasswordOnly -gotoPriorityExpression NEXT

# Create LDAP-SAM Auth Policy for two-factor
# Only evaluated if cert auth fails. Login Schema asks for user, password, and passcode.
add authentication ldapAction Corp-Gateway -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName samaccountname -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-SAMAccountName -rule true -action Corp-Gateway

# Create RADIUS Auth Policy for two-factor
add authentication radiusAction RADIUS-Action -serverIP 10.2.2.42 -serverPort 1812 -radKey MyKey
add authentication Policy RADIUS-Policy -rule true -action RADIUS-Action

# Create Dual-factor Login Schema and bind directly to AAA vServer
# This Login Schema is only shown if Cert auth fails
add authentication loginSchema DualAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuth.xml" -userCredentialIndex 1 -passwordCredentialIndex 2
add authentication loginSchemaPolicy DualAuth -rule true -action DualAuth
bind authentication vserver nFactorAAA -policy DualAuth -priority 100 -gotoPriorityExpression END

# Create RADIUS Policy Label with noschema and RADIUS Auth Policy
# Already got passcode from previous factor so don't show Login Schema again
add authentication loginSchema Noschema -authenticationSchema noschema
add authentication policylabel NoSchema-RADIUS -loginSchema Noschema
bind authentication policylabel NoSchema-RADIUS -policyName RADIUS-Policy -priority 100 -gotoPriorityExpression NEXT

# Bind LDAP-SAM Auth Policy to AAA vServer with RADIUS as next factor
# LDAP-SAM Auth Policy must have higher priority number (lower priority) than Cert Policy
bind authentication vserver nFactorAAA -policy Corp-SAMAccountName -priority 110 -nextFactor NoSchema-RADIUS -gotoPriorityExpression NEXT

# Create Authentication Profile to link AAA with Gateway. Bind to Gateway.
add authentication authnProfile nFactor -authnVsName nFactorAAA -AuthenticationHost aaa.corp.com
add vpn vserver gateway.corp.com SSL 10.2.2.220 443 -icaOnly ON -dtls ON -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -appflowLog ENABLED -authnProfile nFactor

# Enable Optional Client certs on Gateway
set ssl vserver gateway.corp.com -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED
bind ssl vserver gateway.corp.com -certkeyName CorpRoot -CA -ocspCheck Optional

# Create Traffic Policy to SSON to StoreFront. Bind to Gateway.
add vpn trafficAction nFactorSSO http -kcdAccount NONE -userExpression "http.req.user.attribute(1)" -passwdExpression "http.req.user.attribute(2)"
add vpn trafficPolicy nFactorSSO ns_true nFactorSSO
bind vpn vserver gateway.corp.com -policy nFactorSSO -priority 100

Group Extraction, followed by LDAP (Active Directory), or Azure MFA (NPS)

Azure MFA is available as a plug-in for Microsoft Network Policy Server (NPS), which is a Microsoft RADIUS server and a built-in Windows Server Role.

NPS performs both AD authentication and Azure MFA authentication. Citrix Gateway sends the user’s AD password to NPS. NPS verifies AD, and then the NPS Azure MFA plug-in calls the user (or push notification to the user). If both AD and MFA are successful, then NPS sends back RADIUS-Accept.

This sample nFactor configuration will first ask for username only. Depending on the user’s group membership and client IP address, nFactor will either perform RADIUS NPS authentication (multi-factor), or nFactor will do LDAP only (single-factor).

Summary:

  1. First factor Login Schema asks for Username only.
    1. LDAP Group Extraction (with Authentication disabled) reads the user’s groups from AD.
  2. Second factor checks for group membership and sends to one of two different third factors.
  3. If user is in LDAP Group, or Client IP is on internal network, then perform LDAP-only authentication.
    1. Login schema asks for AD password.
    2. LDAP Policy authenticates with LDAP Server (Active Directory).
  4. Otherwise, perform RADIUS (two-factor) authentication.
    1. Login schema asks for AD password.
      • Note: NPS with MFA plugin only needs the AD password. Alternatively, you could use a Login Schema that asks for both LDAP password and RADIUS password.
    2. RADIUS Policy uses the entered AD password to authenticate to Microsoft NPS and Azure MFA.

CLI Commands. Note, these objects are created in the required order, which is backwards from how you would want to configure them.

  1. Add cert for AAA vServer. Link the cert to Intermediate. 
    add ssl certKey WildcardCorpCom -cert WildcardCorpCom.pfx -key WildcardCorpCom.pfx -inform PFX -passcrypt "myPassword"

link ssl certKey WildcardCorpCom Intermediate
  2. Enable AAA feature if not already enabled. 
    enable ns feature AAA
  3. Create first factor LDAP Action (LDAP Server) and LDAP Policy (expression) for Group Extraction. Authentication is disabled. This is the first factor that is bound directly to the AAA vServer. 
    add authentication ldapAction LDAP-Corp-GroupExtract -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword MyPassword -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED

add authentication Policy LDAP-Corp-GroupExtract -rule true -action LDAP-Corp-GroupExtract
  4. Create a third-factor LDAP Action (LDAP Server) and Authentication Policy (expression) for Active Directory Authentication. This is the authentication factor if user is in the LDAP Users group. 
    add authentication ldapAction LDAP-Corp -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword MyPassword -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED

add authentication Policy LDAP-Corp -rule true -action LDAP-Corp
  5. Create a third-factor RADIUS Action (RADIUS Server) and Authentication Policy (expression) for NPS. 
    add authentication radiusAction NPS -serverIP 10.2.2.42 -serverPort 1812 -radKey MySecret

add authentication Policy NPS -rule true -action NPS
  6. Create the second factor NO_AUTHN authentication policies to determine the next factor based on the user’s group membership. NO_AUTHN means don’t authenticate. Instead, these policies will have a Next Factor that points to the Authentication Policies that we created earlier. If the policy expression is true, then go to Next Factor. Next Factor is configured later when binding these policies to the second factor PolicyLabel. Note: the group name is case sensitive and must match the Active Directory group name. 
    add authentication Policy LDAP-Only -rule "http.REQ.USER.IS_MEMBER_OF(\"LDAP\") || client.IP.SRC.IN_SUBNET(10.2.2.0/24)" -action NO_AUTHN

add authentication Policy TwoFactor -rule "client.IP.SRC.IN_SUBNET(10.2.2.0/24).NOT" -action NO_AUTHN
  7. Create first factor Login Schema Profile for username-only group extraction. You can copy the built-in OnlyUsername.xml and modify it with your desired labels. Since this Login Schema Profile is bound to the AAA vServer, it needs a Login Schema Policy (expression). The other two Login Schema Profiles are bound to PolicyLabels and thus don’t need Login Schema Policies. 
    add authentication loginSchema OnlyUsername -authenticationSchema "/nsconfig/loginschema/LoginSchema/OnlyUsername.xml"

add authentication loginSchemaPolicy OnlyUsername -rule true -action OnlyUsername
  8. Create third factor Login Schema Profile for AD Authentication. The .xml file is copied from the built-in PrefillUserFromExpr.xml but with modified labels for AD authentication. The username is pre-filled in from the first factor. 
    add authentication loginSchema LDAPPasswordOnly -authenticationSchema "/nsconfig/loginschema/LDAPPassword.xml"
  9. Create third factor Login Schema Profile for NPS Authentication. The .xml file is copied from the built-in PrefillUserFromExpr.xml but with modified labels for NPS authentication. The username is pre-filled in from the first factor. 
    add authentication loginSchema NPSPasswordOnly -authenticationSchema "/nsconfig/loginschema/NPSPassword.xml"
  10. Create third factor PolicyLabel for Active Directory authentication with Active Directory Login Schema and Active Directory Authentication Policy. 
    add authentication policylabel LDAPPasswordAuth -loginSchema LDAPPasswordOnly

bind authentication policylabel LDAPPasswordAuth -policyName LDAP-Corp -priority 100 -gotoPriorityExpression NEXT
  11. Create third factor PolicyLabel for NPS authentication with NPS Login Schema and NPS Authentication Policy. 
    add authentication policylabel NPSPasswordAuth -loginSchema NPSPasswordOnly

bind authentication policylabel NPSPasswordAuth -policyName NPS -priority 100 -gotoPriorityExpression NEXT
  12. Create second factor PolicyLabel with Policies that choose Next Factor. This PolicyLabel is processed before the two we just created. 
    add authentication policylabel CheckForAuthType -loginSchema LSCHEMA_INT

bind authentication policylabel CheckForAuthType -policyName TwoFactor -priority 90 -gotoPriorityExpression NEXT -nextFactor NPSPasswordAuth

bind authentication policylabel CheckForAuthType -policyName LDAP-Only -priority 100 -gotoPriorityExpression NEXT -nextFactor LDAPPasswordAuth
  13. Create AAA vServer. Bind Login Schema Policy (username only) and Group Extraction Policy. 
    add authentication vserver AAA SSL 10.x.x.218 443
bind authentication vserver AAA -policy OnlyUsername -priority 100 -gotoPriorityExpression END
bind authentication vserver AAA -policy LDAP-Corp-GroupExtract -priority 100 -nextFactor CheckForAuthType -gotoPriorityExpression NEXT
  14. Perform additional steps not detailed here:
    1. For Traffic Management:
      1. Create a Session Policy and bind it to the AAA vServer.
      2. Enable authentication on the Load Balancing or Content Switching vServer.
    2. For Citrix Gateway, create an Authentication Profile, and bind it to the Gateway vServer.
↧
Viewing all 69 articles
Browse latest View live
Search