Jump to content
  • Guest
    Get Started with NetScaler Automation using Ansible
    NetScaler provides Ansible modules to support configuration of different NetScaler use cases, from load balancing to web application firewall policies. NetScaler automation through Ansible enables simplicity and agility, helping IT admins to maintain distributed IT infrastructure and even migrate across different environments.
    In this tutorial, we will go through Ansible installation and configure our first basic use-case of setting up load balancing vserver on NetScaler:
    Pre-requisite : NetScaler is installed, its NSIP, VIP and SNIP configured and ready to receive user traffic.
    Setting up pre-requisite for Ansible Download the virtual environment (It will also install python3 in your environment)sudo apt-get install virtualenvwrapper
    Edit the .bashrc file last line with “---"
    source /usr/share/virtualenvwrapper/virtualenvwrapper.sh
    After editing it, reload the startup file by running
    source ~/.bashrc
    Now create a virtual env
    mkvirtualenv -p `which python3` venv_python3 
    Install Ansible and NetScaler Ansible modules Go to virtual environment and install ansible and NetScaler collections workon venv_python3
    Install Ansible
    pip install ansible
    Install NetScaler collections for Ansible
    ansible-galaxy collection install git+https://github.com/citrix/citrix-adc-ansible-modules.git#/ansible-collections/adc
    Clone NetScaler GitHub Repo
    git clone https://github.com/citrix/citrix-adc-ansible-modules
    Install Python Nitro API SDK as shown below
    (venv_python3) nsroot@autsvr1:~/automation-repos/ansible-ctxadc/citrix-adc-ansible-modules/$ pip install  deps/nitro-python-1.0_kamet.tar.gz 
    Define NetScaler configurations in  Ansible Playbook Navigate to /citrix-adc-ansible-modules/samples/folder where you find lot of sample playbooks to get started. Create a new playbook – my_lb_vserver.yaml with the content as below:
    ---- hosts: citrix_adc  vars:    max_clients: 5  remote_user: root  gather_facts: False  collections:    - citrix.adc  tasks:    - name: Set service 1      delegate_to: localhost      citrix_adc_service:        nsip: "{{ nsip }}"        nitro_user: "{{ nitro_user }}"        nitro_pass: "{{ nitro_pass }}"        validate_certs: "{{ validate_certs }}"        state: present        name: ans-service-1        servicetype: HTTP        ipaddress: 10.217.107.86        port: 80    - name: Set service 2      delegate_to: localhost      citrix_adc_service:        nsip: "{{ nsip }}"        nitro_user: "{{ nitro_user }}"        nitro_pass: "{{ nitro_pass }}"        validate_certs: "{{ validate_certs }}"        state: present        name: ans-service-2        servicetype: HTTP        ipaddress: 10.217.107.87        port: 80    - name: lb vserver 1      delegate_to: localhost      citrix_adc_lb_vserver:        nsip: "{{ nsip }}"        nitro_user: "{{ nitro_user }}"        nitro_pass: "{{ nitro_pass }}"        validate_certs: "{{ validate_certs }}"        state: present        name: ans-lb-vserver-1        servicetype: HTTP        timeout: 12        ipv46: 10.217.107.100        port: 80        servicebindings:            - servicename: ans-service-1              weight: "1"            - servicename: ans-service-2              weight: "1"        disabled: noIn above playbook, we are creating simple HTTP load balancing vserver named ans-lb-vserver-1 that will load balance user traffic across group of your backend services named ans-service-1 and ans-service-2.
    You can configure the ipv46 of ans-lb-vserver-1 to the IP where you want to receive client traffic and define the ip of your backend app services in the ipaddress of ans-service-1 and ans-service-2.
     
    Now create an inventory file such as here with your NetScaler credentials as follows:
    [citrix_adc]myadc_1 nsip=10.78.60.200 nitro_user=adcusername nitro_pass=adcpassword validate_certs=no 
    Run Ansible Commands to apply configuration to NetScaler Within the virtual environment, run the ansible-playbook commands as follows:ansible-playbook -i vpx_inventory.txt  my_lb_vserver.yaml

    We will get above response where all the 3 tasks in playbook are executed successfully and lb vserver 1 configuration is updated.
    To delete configurations you need to edit the state variable in playbook to absent state : absent for each resources that you want to delete. And then run the above ansible-playbook command again.
    That’s the power of using Ansible with NetScaler, where various NetScaler configurations are defined as code in playbooks and executed as set of tasks with just one ansible commands. Explore various example playbooks here and build your desired NetScaler config easily.
     

    Steven Wright
    Tech Paper: Networking SSL / TLS Best Practices
    February 21, 2023
    Author:  Steven Wright
     
    Overview
    This Tech Paper aims to convey what someone skilled in ADC would configure as a generic implementation to receive an A+ grade at Qualys SSL Labs.
    Qualys SSL Labs performs a robust series of tests and provides a scorecard that you can use to improve your configuration. The scan is free and only takes about a minute to complete.
    Qualys actively develops SSL Labs. Tests are likely to change as new protocols are created and vulnerabilities found. It is good practice to test sites regularly to make sure that any new vulnerabilities are not exposed.
     
    NOTE: Talk to your security team about your deployment. Security experts say SSL Labs A+ is a good general target, but it may not fit the needs of your organization. Configuration Items that Need to be Validated
    Certificates - Is the full chain provided and trusted? Is the signature algorithm secure? Protocols, Keys and Cipher Support - Which SSL and TLS protocol versions are supported? Which cipher suites are preferred and in what order? Do the provided cipher suites support forward secrecy? TLS Handshake Simulation - Determines which protocol and cipher are negotiated by several different clients and browsers Protocol Details - Is Secure Renegotiation supported? Is strict transport security (HSTS) supported? Known Vulnerabilities - Is the server vulnerable to attacks such as POODLE, BEAST, or TLS downgrade? Once SSL Labs completes testing, it presents a letter grade along with a point scale for each of 4 categories:
    1 Certificate
    2 Protocol Support
    3 Key Exchange
    4 Cipher Strength
    Each of the categories receives a numerical score that SSL Labs then averages into a total. Some special cases and configurations that SSL Labs recommends against, such as having SSLv3 enabled, can limit your final grade. You can find complete documentation on how SSL Labs grades servers here.
    Implementation Concerns
    SSL Profiles
    This article uses SSL Profiles. When first enabled, SSL Profiles sets all SSL virtual servers to use the default profile.
    SSL profiles take precedence over global and per virtual server SSL parameters.
    Client support
    Some of the configuration steps in this article can cause connectivity issues with old clients and browsers. For example, Internet Explorer 11 on Windows 7 and 8.1 only supports older cipher suites and, other older browsers may lack support for TLS1.2 and ECC ciphers entirely. In cases where support is missing, the client can experience error messages and an inability to display the site.
    SSL Labs have a “Test your browser” button on its front page to help determine your needs.
    Citrix Receiver/Workspace app Cipher Support for Gateway deployments
    Review the following articles regarding client cipher support when deploying a gateway virtual server for virtual apps and desktops:
    CTX234227 and CTX232266 for Citrix Receiver CTX250104 for Workspace app Note: See the Firmware Notes section for required builds and other notes regarding specific ADC firmware
    Basic Steps - GUI
    Take the following steps to ensure a high score on the SSL Labs test.
    Ensure that the ADC is running a recent firmware release - 13.0 build 71 or later is recommended to take advantage of TLS1.3 hardware acceleration
    Ensure that the certificate chain is complete and trusted
    Root CAs do not always directly sign certificates. Instead, a root CA often uses an intermediary to sign a certificate Install the intermediate certificate on the ADC. Link it to the server certificate you bound to the virtual server Intermediate certificates are provided by the vendor that provides the server certificate, often in a ‘certificate bundle’. They can usually be found on the vendor’s public site You may need to install and link multiple intermediate certificates. For the server certificate to function, the ADC must send a complete chain. A complete chain ends with a certificate signed by one of the client’s trusted root CAs As the client already has the trusted root CA, you don’t need to install and link it on the ADC To install an intermediate certificate, go to: Traffic Management > SSL > Certificates > CA Certificates and choose Install (Note: earlier builds of Citrix ADC do not have the ‘CA Certificates’ option in the GUI) Link an intermediate by selecting the certificate and choosing link from the action menu If the correct intermediate certificate is installed, it is automatically populated in the linking menu


    Create a custom cipher group that provides Forward Secrecy (FS) Go to Traffic Management > SSL > Cipher Groups and choose Add Name the cipher group “SSL_Labs_Cipher_Group_Q4_2021” Click Add then expand the ALL section - select the following cipher suites: TLS1.3-AES256-GCM-SHA384 TLS1.3-AES128-GCM-SHA256 TLS1.3-CHACHA20-POLY1305-SHA256 TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 TLS1.2-ECDHE-ECDSA-AES256-SHA384 TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 Click the > right arrow to move the ciphers from the Available column to the Configured column Click Create
    Enable SSL Profiles Navigate to Traffic Management > SSL > Change advanced SSL settings, scroll down, and select Enable Default Profile.

    SSL Profiles sets all SSL virtual servers to use the default profile when first enabled. As existing per virtual server SSL settings are removed, the ADC will prompt you to confirm.

    Create an SSL Profile Navigate to System > Profiles > SSL Profile, and select Add
    Name the profile “SSL_Labs_Profile_Q4_2021” Scroll to Deny SSL Renegotiation and select NONSECURE to allow only clients that support RFC 5746 to renegotiate Scroll to HSTS, tick HSTS, and specify a Max Age of 157680000 seconds Scroll to Protocol and select only TLSv12 and TLSv13  Scroll to the end of the form and select OK Scroll to SSL Ciphers, select the pencil icon to edit, then click Remove All Click Add and add the cipher group we created earlier  Scroll to the end of the form and select Done Bind the SSL Profile to the SSL virtual server On the selected virtual server, select the pencil icon to edit the bound SSL Profile Select the SSL Profile we created from the drop-down list Click OK Basic Steps - CLI
    Take the following steps to ensure a high score on the SSL Labs test.
    In the CLI examples below, the name of the SSL virtual server is listed as Ex-vServer - it can be replaced with the name of the SSL virtual server in your environment.
    Create a custom cipher group that prefers ECDHE and ECDSA cipher suites add ssl cipher SSL_Labs_Cipher_Group_Q4_2021bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.3-AES256-GCM-SHA384bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.3-AES128-GCM-SHA256bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.2-ECDHE-ECDSA-AES256-SHA384bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384   Enable SSL Profiles set ssl parameter -defaultProfile ENABLED   Create an SSL Profile add ssl profile SSL_Labs_Profile_Q4_2021 -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED -tls13 ENABLED -denySSLReneg NONSECURE -HSTS ENABLE -maxage 157680000   Unbind the default cipher group from the SSL Profile and bind the custom group unbind ssl profile SSL_Labs_Profile_Q4_2021 -cipherName DEFAULTbind ssl profile SSL_Labs_Profile_Q4_2021 -cipherName SSL_Labs_Cipher_Group_Q4_2021   Bind the SSL Profile to the SSL virtual server set ssl vserver "Ex-vServer" -sslProfile SSL_Labs_Profile_Q4_2021    
    More Settings
    SHA1 Certificates
    Certificates that are signed with SHA1 are considered weak, and prevents a high grade in the SSL Labs test. If any certificates are SHA1 signed, they should be replaced with an SHA256 certificate and installed on the ADC.
    DNS CAA
    DNS Certification Authority Authorization (CAA) allows CAs to validate if they are authorized to issue certificates for a domain and provide a contact if something goes wrong.
    DNS CAA is not required for an A+ at SSL Labs and is an optional step. You can find out more about DNS CAA here.
    Legacy client support
    The ECDHE ciphers we use in this guide replace the older slower DHE ciphers. If you have legacy clients that you cannot upgrade, you may have no choice but to enable DHE.
    Enable DHE cipher suites in the GUI
    Go to Traffic Management > SSL and select Create Diffie-Hellman (DH) key
    Name the Diffie-Hellman key “DH_Key_Name_Here.key”
    Enter the parameter size (Bits). Must be between 512 and 2048
    Choose the Diffie-Hellman generator (2 or 5)
    Select Create Depending on the key size selected, this could take quite some time to complete
     
    NOTE: Do not navigate past this screen until it completes
    Navigate to System > Profiles > SSL Profile
    Select the SSL_Labs_Profile_Q4_2021 profile and choose Edit
    Select the pencil icon
    Scroll down to the Enable DH Param check box and select it
    Choose the DH key you just created

    Scroll down and select Okay
    Bind a DHE cipher suite to the cipher group that we created earlier
    Navigate to Traffic Management > SSL > Cipher Groups
    Select the TLS1.2-DHE-RSA-AES256-GCM-SHA384 cipher

    Click the arrow to add it to the Cipher Group
    Enable DHE ciper suites in the CLI
    Create and bind a DH key to the SSL Profile (CLI) create ssl dhparam DH_Key_Name_Here.key 2048 -gen 2set ssl profile SSL_Labs_Profile_Q4_2021 -dh ENABLED -dhFile DH_Key_Name_Here.key   Bind a DHE cipher suite to the cipher group that we created earlier bind ssl cipher SSL_Labs_Cipher_Group_Q4_2021 -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384   Firmware Notes
    Citrix enabled TLS1.2 as a default in firmware version 10.5 build 57
    The ROBOT vulnerability was addressed in builds 12.0 build 53, 11.1 build 56, 11.0 build 71 and 10.5 build 67 - more details are available here
    The HSTS (Strict Transport Security) flag became available in 12.0 build 35 - prior builds required a rewrite policy to insert the HSTS header. You cannot use both as the ADC to insert 2 headers which is not allowed.
    Support for TLS1.2 was added to the VPX appliances in 10.5 build 57. It was available in earlier builds for appliances with dedicated SSL hardware
    Support for TLS1.3 was added in 12.1 build 49.23 - it must be enabled in the vServer SSL Parameters or added to an enhanced SSL Profile, and TLS1.3 ciphers (listed) must be bound. TLS1.3 is not supported on legacy SSL profiles
    ECC certificate support was added to the VPX appliances in 12.0 build 57. It was available in earlier builds for appliances with dedicated SSL hardware
    The Zombie POODLE vulnerability was addressed in builds 12.1 build 50.31, 12.0 build 60.9, 11.1 build 60.14, 11.0 build 72.17, and 10.5 build 69.5. This vulnerability only affects MPX\SDX appliances with Nitrox SSL hardware. MPX\SDX appliances with Coleto Creek are not vulnerable. Disabling CBC-based cipher suites also mitigates this vulnerability. See CTX article for more information
    The cipher list has been modified to address CBC weaknesses, thus removing 0xc028 and 0x39 ciphers
    Citrix added TLS1.3 hardware acceleration in 13.0 build 71

    Konstantinos Kaltsas
    How to speed up NetScaler Baseconfig with Terraform modules
    Submitted May 26, 2023Author: Arne Marien, Lead Consultant, Provectus Technologies GmbH
     
    At Provectus Technologies, we offer a NetScaler as a Service model that is fundamentally based on the GitOps concept.  To make the service efficient, scalable and to reduce errors, the NetScaler configurations are fully managed through Terraform. To be able to maintain the Terraform code for such a growing environment, we developed some Terraform modules for different use cases.
     
    Using Terraform modules for NetScaler configuration can provide several benefits:
     
    Reusability
    Terraform modules can be reused across different projects, environments, and teams. By creating reusable modules for NetScaler configurations, you can save time and effort by avoiding the need to recreate configurations from scratch every time.
     
    Consistency
    Terraform modules can ensure consistency in NetScaler configurations across different environments and stages. By using the same modules for different environments, you can ensure that your NetScaler configurations are consistent, reducing the risk of errors and making it easier to stage your changes.
     
    Collaboration
    Terraform modules can help for collaboration among teams working on NetScaler configurations. By creating modules that can be easily shared and reused, teams can work together more efficiently, reducing the need for duplicative work and improving overall productivity.
    Maintainability
    Terraform modules can make it easier to maintain NetScaler configurations over time. By breaking configurations down into modules, it becomes easier to update and modify configurations as needed. This can help reduce the time and effort required to maintain NetScaler configurations.
     
    A Module can be structured in the following Terraform files:
    main.tf variables.tf output.tf  
    The main.tf contains the description of all resources that are necessary for a baseconfig. The variables.tf describes the variables that are required to create the resources. These must be passed when invoking the module. The output.tf contains the output of any resources after the execution of the module.
     
    A first example
    Baseconfig Sub-Module
    The main.tf contains the Terraform provider name and version required for the module to work and the two resources we want to add using this module.
     
    main.tf>terraform {  required_version = ">= 1.3.0"  required_providers {    citrixadc = {      source  = "citrix/citrixadc"      version = ">= 1.30.0"    }  }} resource "citrixadc_nsip" "nsip" {  for_each                    = { for ip in var.nsip : ip.ipaddress => ip }  ipaddress                   = each.value.ipaddress  netmask                     = each.value.netmask  type                        = each.value.type  mgmtaccess                  = each.value.mgmtaccess} resource "citrixadc_route" "route" {  for_each = { for route in var.route : route.network => route }  network  = each.value.network  netmask  = each.value.netmask  gateway  = each.value.gateway  depends_on = [    citrixadc_nsip.nsip  ]}
     
    The variables.tf specifies the variables required by the resources, that must be provided when the module is called. All optional attributes are provided with the optional(<type>, <default-value>) function and do not have to be provided to the module. The specification of default or optional values makes the module easier to use and more robust.
     
    variables.tf>variable "nsip" { description = "List of NSIPs" type = list(object({ ipaddress = string netmask = string type = optional(string, null) mgmtaccess = optional(string, null) }))} variable "route" { description = "Adds routes" type = list(object({ network = string netmask = string gateway = string }))}
    Root-Module
    To invoke the module, root module is required. This root-module contains the information of the environments and refers to all sub-modules which are required for the configuration.
     
    The main.tf of the root module specifies the provider configuration including the Terraform backend for managing the Terraform state, as well as the submodules. The source must refer to the sub-module. This can be in the same file system but can also refer to a Git repository.
     
    Note: The NetScaler credentials required for the provider should only be set for local tests in the root module itself and should never be committed to a repository. The credentials should always be set as environment variables.
    main.tf>provider "citrixadc" {  insecure_skip_verify = true  endpoint = "https://<ns-ip>"  username = "<username>"  password = "<password>"} terraform {  backend "local" {}  required_providers {    citrixadc = {      source = "citrix/citrixadc"    }  }} module "baseconfig" {  source         = "<path-to-my-module>"  nsip           = var.nsip  route          = var.route}
    The variables.tf of the root module contains the information for an environment. The structure of the variables must match the specifications from the sub-module and contain at least the required variables. All optional values do not have to be passed mandatory.
     
    variables.tf>variable "nsip" {  description = "Adds NSIPs"  type        = list(any)  default = [    {      ipaddress = "10.1.0.10"      netmask   = "255.255.255.0"type      = "SNIP"    },    {      ipaddress  = "10.2.0.10"      netmask    = "255.255.255.0"      mgmtaccess = "ENABLED"      gui        = "SECUREONLY"      type       = "SNIP"    }  ]} variable "route" {  description = "Adds routes"  type        = list(any)  default = [{    network = "172.1.0.0"    netmask = "255.255.255.0"    gateway = "10.1.0.1"  }]}
    Folder Structure
    With a growing environment and multiple modules, the directory structure is very important. A good structure may look like the following:
     
    .└── terraform    ├── environments    │   ├── dev    │   │   └── baseconfig    │   │       ├── main.tf    │   │       └── variables.tf    │   └── prod    └── modules        └── netscaler            ├── baseconfig            │   ├── main.tf            │   ├── outputs.tf            │   └── variables.tf            ├── csvserver            └── lbvserver
    Different environments such as DMZ and LAN as well as stages such as DEV and PROD can be mapped in environments. Modules contains the sub-modules such as baseconfig, which are invoked by the root-modules in environments.
     
    Module execution
    Now we have everything for our first Terraform module in a clear structure. To run Terraform now, we only have to execute the known commands in the directory of the root module. Make sure that the source path points to the baseconfig module. Otherwise, an error will occur during initialization.
     
    module "baseconfig" {  source            = "./../../../modules/netscaler/baseconfig/"  nsip              = var.nsip  route             = var.route}
    When the path is correct, the baseconfig can be executed via the commands terraform init, terraform plan, terraform apply.
     
    Module Versioning
    There are some good reasons why Terraform code should be located in a Git repository. One of them is the ability to have multiple versions of the code available. Terraform modules can grow over time, as there are maybe more requirered resources or other changes. To avoid that adjustments to modules immediately affect all environments, there is the possibility to refer to a certain version of my sub-module in the root module. This means that I can use version 1.1 with some changes in the DEV Stage, but still use version 1.0 in PROD.
    To do this, we first need to add our module to a Git repository.
     
    ~git initgit add .git commit -m "Initial commit of my module"git remote add origin "<Git repo remote URL>"git push origin main
     
    Afterwards we can set a tag to this specific version of the module.
     
    ~git tag -a v1.0 -m "Module Version 1.0"git push --follow-tags
    Now the current state of the baseconfig module is marked as version 1.0. To use exactly this version, the source in the root module must be adjusted. This differs depending on the service used. For a generic Git repository, this works like this:
     
    module "baseconfig" {  source = "git::https://example.com/network.git//modules/baseconfig?ref=tags/1.0"  nsip   = var.nsip  route  = var.route}
     
     
    What's next?
    There are more modules
    This was the first example of how Terraform modules can significantly simplify NetScaler configuration. Especially in growing environments this allows to build always the same consistent configurations. This does not only apply to base configurations. Services such as load balancing, content switching, or Gateway with Advanced Authentication can also be built as modules. Thinking even further, the underlying infrastructure, such as a NetScaler in Azure or AWS, can also be created automated and reusable via module.
     
    How to get started with NetScaler Automation Toolkit?
    1. Visit the hands-on labs for Terraform with NetScaler to get your self familiar with NetScaler Automation Toolkit. 
    Basic Load Balancing Configuration using Terraform Basic Content Switching Configuration using Terrafor Basic Rewrite / Responder Policies Configuration using Terraform Basic Application Protection Configuration (WAF) using Terraform 2. Setup your private lab by following NetScaler's Get Started guides for Terraform.
     
    Get Started with NetScaler Automation Toolkit using Terraform  
    3. Follow the Beginners Guide to get comfortable with common commands.
     
    Beginners guide to automating ADC with terraform on GitHub  
    4. Be part of the Community. Pick a common NetScaler use-case / configuration, create a Terraform template and publish it on NetScaler Community.
     
    Additional resources for NetScaler Automation Toolkit?
    Visit the following links to get more details on using Terraform with NetScaler.
    ADC Terraform Provider on Terraform Registry ADC Terraform Provider on GitHub ADM Terraform Provider on GitHub SDX Terraform Provider on GitHub BLX Terraform Provider on GitHub Terraform Templates to Provision VPX on GitHub About the Author
    Arne Marien is a Consultant focusing on Application Delivery and especially on NetScaler working at Provectus Technologies GmbH . Provectus is a founder-managed IT service provider based in Munich. The business enabler has empowered Corporate and medium-sized companies to meet the requirements of digitalization, since 2001. The core approach involves cloud technologies, digital workplace, and process optimization. More than 110 experts operate under constant compliance, stability, availability & unlimited security.

    NetScaler Cyber Threat Intelligence
    NetScaler WAF mitigates risk from new MOVEit SQLi vulnerabilities
     
    NetScaler has new signatures available for its integrated Web App Firewall to help customers mitigate two more vulnerabilities which were reported for MOVEit Transfer web application that could allow an unauthenticated attacker to gain unauthorized access to MOVEit Transfer's database.
    The vulnerability CVE-2023-35036 affect MOVEit Tranfer versions before 2021.0.7 (13.0.7), 2021.1.5 (13.1.5), 2022.0.5 (14.0.5), 2022.1.6 (14.1.6), and 2023.0.2 (15.0.2) and CVE-2023-35708 affects 2021.0.8 (13.0.8), 2021.1.6 (13.1.6), 2022.0.6 (14.0.6), 2022.1.7 (14.1.7), and 2023.0.3 (15.0.3). They both are related to SQL injection vulnerabilities that could allow an unauthenticated attacker to gain unauthorized access to MOVEit Transfer’s database. 
    The CVE-2023-35036 vulnerability is classified as critical with a CVSS of 9.1 (published on June 11, 2023), while CVE-2023-35708 (published on June 16, 2023) is awaiting classification. Customers should apply the latest NetScaler WAF signature file to help mitigate the exploitation of these vulnerabilities in their environments. NetScaler recommends WAF Signatures version 107 for CVE-2023-35036 and CVE-2023-35708.
    Mitigating both vulnerabilities
    The vendor (Progress Software) recommends that users of MOVEit Transfer immediately adhere to their published mitigation measures and incrementally apply the appropriate patches to the software to prevent exploitation of this SQLi vulnerability. 
     NetScaler customers can quickly implement the following recommendations to help reduce risk and lower exposure associated with this vulnerability. If you are using any of the affected MOVEit Transfer versions, NetScaler strongly recommends that you download WAF Signatures version 107 or later of the signature file and apply it to your NetScaler Web App Firewall deployments as an additional layer of protection for your applications.  Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: software versions 11.1 and 12.0 are end of life and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    Signature rule
    CVE ID
    Description
    998689
    CVE-2023-35036
    WEB-MISC Progress MOVEit Transfer Multiple Versions - Unauthenticated SQL Injection Vulnerability (CVE-2023-35036)
    998688
    CVE-2023-35708
    WEB-MISC Progress MOVEit Transfer Multiple Versions - Unauthenticated SQL Injection Vulnerability (CVE-2023-35708)
     
    If you already use NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 107 or later and then follow these steps.
    Search your signatures for CVE-2023-35036 and CVE-2023-35708 Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks from CVE-2023-34362.
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 
     
     

    Guest
    Convert NetScaler ADC Perpetual Licenses to the Pooled Capacity Model
    Contributed By: Zheng Wang, Neeharika Kambhalur, Stanley Nitkowski
    This document covers the NetScaler ADC use cases for implementing and configuring the Pooled Capacity model on the NetScaler ADC appliances.
    Audience
    This document summarizes the Citrix pooled capacity implementation and configuration for Solutions and Sales Architects, Engineering and Design teams, NetScaler ADC Administrators, and Consultants.
    The Challenge
    Citrix Pooled capacity has several different methods to convert legacy perpetual license use cases to the Citrix pooled capacity model. This document consolidates the conversion and implementation process in a single document and references online documentation for reference to specific topics and content.
    Business Advantages of Citrix Pooled Capacity Licensing
    The NetScaler ADC pooled capacity allows you to share bandwidth or instance licenses across different ADC form factors. For virtual CPU subscription-based instances, you can share virtual CPU license across instances. Use this pooled capacity for the instances that are in the data center or public clouds. When an instance no longer requires the resources, it checks the allocated capacity back into the common pool. Reuse the released capacity to other ADC instances that need resources.
    You can use pooled licensing to maximize the bandwidth utilization by ensuring the necessary bandwidth allocation to an instance and not more than is needed. Increase or decrease the bandwidth allocated to an instance at run time without affecting the traffic. With the pooled capacity licenses, you can automate the instance provisioning.
    NetScaler ADC Pooled Capacity Documentation
    NetScaler ADC Virtual CPU and Bandwidth Documentation
    The Solution – Citrix Pooled Capacity Licensing

    Minimum order quantities required for HW ADCs and SW ADCs to qualify for Pooled Capacity Subscriptions for Pooled Capacity bandwidth and instances are available for 1, 3 or 5-year terms Qualified HW ADC models can be upgraded/converted from perpetual licenses to Pooled Capacity Citrix ADM is required as a licensing server for Pooled Capacity
    How NetScaler ADC pooled capacity licensing works NetScaler ADC pooled capacity has the following components:
    NetScaler ADC instances, which can be categorized into: Zero-capacity hardware Standalone VPX instances or CPX instances Bandwidth pool Instance pool Citrix ADM configured as a license server
    Technology Components
    License files
    License allocation must be completed through the citrix.com website to fulfill and download the required license files for both perpetual and pooled licensing models. The two main requirements for pooled licensing that must be completed for providing NetScaler ADC appliances are license allocation and license download.
    Manage Licenses Documentation
    Allocate Licenses
    When you allocate licenses, you apportion purchased licenses by product and License Server so you can split them among multiple environments or use cases. For example, your organization might own 1,000 licenses for the same product. You might want to use 800 in 1 location and 200 in another location. You can allocate 800 licenses to a License Server in the first location today, and allocate the remaining 200 later to a different License Server.
    Platform License
    Allows for pooled capacity mode on the platform. Required to use pooled capacity and is the first license installed.
    Capacity Licenses
    Instance Licenses
    The instance pool defines the number of VPX instances or CPX instances that can be managed through NetScaler ADC pooled capacity or the number of VPX instances in an SDX-Z instance. When checked out from the pool, a license unlocks the MPX-Z, SDX-Z, VPX, and CPX instance’s resources, including CPUs/PEs, SSL cores, packets per second, and bandwidth.
    Pooled Capacity License Documentation
    Bandwidth License
    The bandwidth pool is the total bandwidth that can be shared by NetScaler ADC instances, both physical and virtual. The bandwidth pool comprises separate pools for each software edition (Standard, Enterprise, and Platinum). A given NetScaler ADC instance cannot have bandwidth from different pools checked out concurrently. The bandwidth pool from which it can check out bandwidth depends on its software edition for which it is licensed.
    License Combinations
    Platform# LicensesLicense TypesSDX3Z-platform, Instance, BandwidthMPX2Z-platform, BandwidthVPX2Instance, BandwidthBLX2Instance, BandwidthvCPU1vCPU license (VPX, BLX, CPX platforms)CPX2Instance, BandwidthNetScaler ADC Platforms
    The NetScaler ADC comes in several form factors and all require an entitlement license to function. Following is a summary of the NetScaler ADC platforms.
    MPX - Purpose built for cloud scale and performance for SSL needs.
    SDX - Fully isolated, multitenant support for application workloads and groups
    VPX - Deploy on your preferred hypervisor and achieve high SSL performance with no hardware acceleration.
    CPX - Supporting containerized applications within different environments, such as Kubernetes and OpenShift.
    BLX - Run software-based application delivery and load balancing functionality as a Linux process, without a hypervisor or container overhead, on your choice of hardware.
    NetScaler ADC Platform Documentation
    Management Components
    Citrix Application Delivery Manger Service
    Citrix ADM service is a cloud-based solution that helps you manage, monitor, orchestrate, automate, and troubleshoot your NetScaler ADC SDX appliances. It also provides analytical insights and curated machine learning based recommendations for your applications health, performance, and security. For more information, see Citrix ADM service.
    Citrix Application Delivery Manager on-premises
    Citrix ADM Software virtual appliances can be deployed in several deployment modes and provide the flexibility to integrate within your existing Citrix networking design. The following are some of the deployment scenarios implemented by using ADM Software appliances.
    Single Server High Availability (Recommended) Disaster Recovery Mode ADM Agent Deployment (for adding remote Sites) Citrix ADM Documentation
    Pooled Capacity Provisioning with ADM
    Configure pooled capacity
    You can configure Citrix ADM as a license server for ADC instances. You can perform the following tasks using Citrix ADM as a license server:
    Upload the pooled capacity license files (bandwidth pool or instance Pool) to the license server. Allocate licenses from the license pool to NetScaler ADC instances on demand. Check out the licenses from NetScaler ADC instances (MPX-Z /SDX-Z/VPX/CPX/BLX) based on the minimum and maximum capacity of the instance. Configure pooled capacity for NetScaler ADC FIPS instances to check in or check out licenses. Configure ADM as License Server
    Citrix Application Delivery Management (ADM) requires a verified Citrix ADM license to manage and monitor the NetScaler ADC instances.
    The following are the license types supported for Citrix ADM for Service: License typeEntitled toVirtual server10 virtual servers and 5 GB storage per licenseStorage5 GB per licenseExpress licenseCitrix ADM Express account is a default account to manage ADM resourcesCitrix ADM License Documentation

    Note: Configure a License Server to pool and allocate the licenses to the pooled-capacity enabled instances. Otherwise, check out licenses from the pooled capacity enabled ADC instance.
    You can configure the ADM as a License Server for the pooled capacity. With this configuration, you can allocate licenses to a NetScaler ADC instance in two ways:
    An ADC instance sends a check-out request to Citrix ADM to obtain its bandwidth and instance licenses. The licenses are allocated to the ADC instance through ADM.
    Note: You can view the pooled capacity in Citrix ADM only if the pooled licenses are added to the ADM.
    The following are the operating modes of the instances that are using the pooled capacity:
    Optimum: Instance is running with proper license capacity. Capacity mismatch: Instance is running with a capacity less than the amount configured in Citrix ADM for pooled licenses. Grace: Instance is running on grace license. Grace & Mismatch: Instance is running on grace but the capacity is less than the amount configured. Not available: Instance is not registered with ADM for management, or NITRO communication from ADM to the instances is not working. Not allocated: License is not allocated in the instance. Install license files on ADM
    In Citrix ADM, navigate to Networks > Licenses.
    In the License Files section, select Add License File and select one of the following options:
    Upload license files from a local computer. If a license file is already present on your local computer, you can upload it to ADM. Use license access code. Specify the license access code for the license that you have purchased from Citrix and select Get Licenses. Then click Finish.
    Note:
    At any time, you can add more licenses to ADM from the License Settings.
    Allocate pooled capacity licenses from ADM

    Prerequisite: Before you can manage your instance’s pool licenses through ADM, you must register the >instance with ADM.
    Log in to NetScaler ADC GUI.
    Navigate to System > Licenses > Manage Licenses.
    Click Add New License.
    Select Use remote licensing and select the remote licensing mode from the list.
    In Server Name/IP address, Specify the host name or IP address of Citrix ADM which you have configured as a License Server.
    Check the Register with Citrix ADM check box and click Continue.


    Note:
    If you have not registered the instance with ADM, you can check out licenses from ADM, but you cannot allocate from ADM to the pooled capacity enabled instance.
    In the user name and password fields on the previous screen, enter your ADM credentials.
    Select the license edition and specify the required bandwidth.
    Click Get Licenses.
    After the instance is registered with the License Server, allocate the licenses from Citrix ADM as follows:
    Log in to Citrix ADM.
    Navigate to Networks > Licenses > Bandwidth Licenses > Pooled Capacity. If you want to allocate licenses to ADC FIPS instances, navigate to Networks > Licenses > Bandwidth Licenses > FIPS Pooled Capacity.
    Click the license pool that you want to manage.
    Select an ADC instance from the list of available instances by clicking the > button.

    The License status column displays corresponding license allocation status messages.
    If you want to change or release a license allocation, click Change allocation or Release allocation.
    A pop-up window with the available licenses in the License Server appears.
    You can choose the bandwidth or instance allocation to the instance by setting the Allocate list options. After making your selections, click Allocate.
    You can also change the allocated license edition from the list options in the Change
    License Allocation window:

    Pooled Capacity Visibility with ADM Licensing Server

    ADM Licensing Operations and Grace Periods
    ADM is used as the licensing server for pooled capacity.
    A single centralized ADM serves all licensing requests. If multiple licensing servers are needed for any reasons, it is best to divide bandwidth and instances as part of the order.
    ADM licensing supports an active-standby HA ADM pair over a local LAN (not between remote sites).
    No reboot is required when increasing or decreasing capacity.
    There is a heartbeat message exchanged between ADC and ADM for health monitoring.
    License Server behavior scenarios
    ADM license server stops responding. The license Server is not responding. NetScaler ADC continues to operate with the current capacity for 30 days. After 30 days, if the connectivity to the license server is not restored, the NetScaler ADC loses its current capacity and stops processing traffic.
    NetScaler ADC pooled-capacity enabled instance stops responding. If the NetScaler ADC pooled-capacity enabled instance stops responding and the license server is in a healthy state, the license server checks in all the NetScaler ADC instance’s licenses after 10 minutes. When the instance reboots, it sends a request to check out all the licenses from the licensing server.
    Both the license server and NetScaler ADC pooled-capacity enabled instance stop responding. If both the license server and the NetScaler ADC pooled-capacity enabled instance restarts and reestablishes the connection, the license server checks-in all its licenses after 10 minutes, and the NetScaler ADC pooled capacity enabled instances automatically check out the licenses after the reboot is completed.
    The NetScaler ADC pooled-capacity enabled instance shuts down gracefully. During a graceful shutdown, you can choose to check the licenses in or keep the licenses that were allocated before the graceful shutdown. If you choose to check the licenses in, the NetScaler ADC pooled-capacity enabled instance is unlicensed after it restarts. If you choose to keep the licenses, they are checked in to the licensing server when the instance shuts down. After the instance restarts, it reestablishes the connection with the licensing server and checks out the licenses as specified in the saved configuration. If the system reboots and the check-out fails due to no capacity available in the pool, the NetScaler ADC checks the inventory of Citrix Application Delivery Management (ADM) pool licenses and will check out any available capacity. An SNMP alarm is raised to notify this condition to the user if the NetScaler ADC is not running with full capacity as per configuration. If no capacity is available in the bandwidth pool, the pool capacity enabled instance becomes unlicensed.
    Network loses connectivity error:
    ERROR MESSAGE (SYSLOG)License Server is not responding.
    If the license server and NetScaler ADC pooled-capacity enabled instances are in healthy states but network connectivity is lost, the instances continue to operate with their current capacity for 30 days. After 30 days, if the connectivity to the license server is not restored, the instances lose their capacity and stop processing traffic, and the license server checks-in all its licenses. After the license server reestablishes connectivity with the NetScaler ADC instances, the instances check the licenses out again.
    How to delete a license
    Under Networks -> LicensesSelect the license and click “Delete” the license anytimeADM automatically checks out the requested license for ADC from the new pool available

    Useful links for Pooled Capacity
    License Server Behavior Documentation
    Pooled Capacity data sheet
    Pooled Capacity HA Licensing
    Converting Perpetual MPX Platform to the Pooled Model
    Configure pooled capacity on ADC MPX-Z instances
    MPX-Z is the pooled-capacity enabled ADC MPX appliance. MPX-Z supports bandwidth pooling for Premium, Advanced, or Standard edition licenses.
    MPX-Z requires platform licenses before it can connect to the License Server. You can install the MPX-Z platform license by either uploading the license file from a local computer or using the instance’s hardware serial number, or the License Access Code from System > Licenses section of the instance’s GUI. If you remove the MPX-Z platform license, the pooled-capacity feature is disabled and all the checked-out licenses are checked in to the License Server.
    You can dynamically modify the bandwidth of an MPX-Z instance without a restart. A restart is required only if you want to change the license edition.
    License Conversion Documentation

    Example of the MPX-Z License for Pooled on the MPX platform

    NOTE When you restart the instance, it automatically checks out the pooled licenses required for >its configured capacity.
    Allocate pool licenses to ADC MPX-Z or ADC VPX instances from NetScaler ADC to allocate your licenses:
    Navigate to System > Licenses > Manage Licenses, click Add New License, and select Use Pooled Licensing.
    Enter the details of the License Server in the Server Name/IP Address field.
    If you want to manage your instance’s pool licenses through ADM, select the Register with Citrix ADM check box and enter the ADM credentials.
    Select the license edition and the required bandwidth, click Get Licenses.
    You can change or release the license allocation by selecting Change allocation or Release allocation.
    If you click Change allocation, a pop-up window shows the licenses available on the License Server.


    Note:
    A restart is not required if you change the bandwidth allocation, but a warm restart is required if you change the license edition.
    You can allocate bandwidth or instances to the instance from the Allocate list. Then click Get Licenses.
    You can choose the license edition and the bandwidth required from the drop-down lists in the pop-up window.

    Note:
    Bandwidth allocation must be a multiple of the minimum bandwidth unit.
    MPX Conversion Impacts
    Only certain selected MPX/SDX platforms are qualified for upgrade to pooled capacity.
    For some older platforms, the upgrade from perpetual to pool is a one-off offering. Renewal of pooled subscription on the original HW is not supported after the upgrade subscription term expires
    Supported Platforms for conversionRenewal allowed after conversion term expires?14xxx/25xxxYes15xxx/26xxxYes89xxYes22xxx/24xxxNo8005/8015No11515–11542No Minimal order quantity applies (same as MPX/SDX new purchase)
    AMER: 4 units and 40 Gbps Rest of world: 2 units and 20 Gbps You only need one SKU for upgrade/conversion. The SKU includes all the following:
    Zero-capacity Hardware license (perpetual) Gold hardware maintenance for zero-capacity hardware for the duration Convert the existing bandwidth in the perpetual model to Pooled Convert the existing instance (if SDX) in the perpetual model to Pooled Transition from MPX/SDX Pool to Cloud or SW ADCs
    Pooled bandwidth and instances on ADM can be used in any place (on-premises or cloud), for any form factors (MPX/SDX/VPX/CPX/BLX).
    Each MPX/SDX appliance has a system requirement for minimum bandwidth and minimum instances (if SDX) to operate, for example:
    MPX 14000z requires 20 Gbps minimum. If the MPX has more than the minimum, the amount above the minimum can be used in the cloud.
    As part of the Q3 2019 release, we have reduced the SDX system requirement for minimum bandwidth and minimum instances by half.
    The updated table on minimum system requirement on bandwidth and instances can be found here
    Bandwidth Increase
    MPX Conversion Reboot Scenarios
    Any change in Edition (Standard, Advanced, Premium) requires an appliance reboot.
    Converting Perpetual SDX Platform to the Pooled Model
    Applying the SDX Platform licenses
    SDX-Z requires platform licenses before it can connect to the License Server. You can install the SDX-Z platform license by either uploading the license file from a local computer or using the instance’s hardware serial number, or the License Access Code from System > Licenses section of the SVM GUI. If you remove the SDX-Z platform license, the pooled-capacity feature is disabled and all the checked-out licenses are checked in to the License Server.
    SDX Licensing Overview
    Applying the SDX Pooled License
    A NetScaler ADC SDX appliance with perpetual license can be upgraded to NetScaler ADC Pooled Capacity license. Upgrading to NetScaler ADC Pooled Capacity license enables you to allocate licenses from the license pool to NetScaler ADC appliances on demand. You can also configure the ADC Pooled Capacity license for NetScaler ADC instances configured in high availability mode.
    Supported pooled capacity for ADC instances

    IMPORTANT For upgrading the SDX appliance to NetScaler ADC Pooled Capacity license, you need to upload the >SDX-Z license to the appliance.
    Log into the SDX appliance using the SVM console and navigate to Configuration>System > Licenses. Select add license file.

    Select upload license file from local computer.

    Browse to the SDX-Z license to unlock pooled capacity.

    Select the SDX-Z license that was downloaded from the license portal.

    Add the license file and complete the ADM agent values.

    Upgrade a Perpetual to Pooled License Documentation
    Applying the SDX Bandwidth and Instance License in ADM license

    NOTE: SDX Bandwidth and Instance licensees are managed and configured in the ADM section of this document.
    Converting Perpetual VPX Platform to the Pooled Model
    Configure pooled capacity on ADC VPX instances

    VPX Conversion from Perpetual to vCPU A pooled-capacity enabled ADC VPX instance can check out licenses from a bandwidth pool (Premium/Advanced/Standard editions). You can use the ADC GUI to check out licenses from the License Server.


    You can dynamically modify the bandwidth of a VPX instance without a restart. A restart is required only if you want to change the license edition or convert a perpetual license to vCPU licenses.

    Note
    When you restart the instance, it will automatically check-out the pooled licenses required for its configured capacity.
    SDX Conversion Impacts from Perpetual to Pooled
    You can dynamically modify the bandwidth of an SDX-Z instance without a restart. A restart is required only if you want to change the license edition.
    SDX Conversion Reboot Scenarios
    Single Bundle upgrades require a reboot of the SDX appliance.
    Conversion from Perpetual to Pooled does not require a reboot.
    A VPX on SDX gets a license from the SDX SVM.
    Reboot Scenario Summary
    VPX requires 1 warm reboot for conversion from perpetual to pooled.
    MPX requires 2 reboots, a warm reboot for license conversion, and full reboot for edition changes.
    SDX does not require reboot for conversion from perpetual to pooled.
    Bandwidth and Instance Pooled Behavior
    You can dynamically modify the bandwidth of an -Z license instance without a restart. A restart is required only if you want to change the license edition.
    Increase or decrease the bandwidth allocated to an instance at run time without affecting the traffic.
    Change allocation or Release allocation action The bandwidth change takes effect after the ADC warm restart.

    NetScaler ADC HA with pooled capacity works the same way as NetScaler ADC HA with a perpetual license. Each NetScaler ADC appliance in a HA pair needs its own and similar license. Pooled capacity licenses are bound to the primary Citrix ADM Node. If that node goes down, all the instances which received capacity from it move into a grace period. It is necessary for the original primary Citrix ADM node to be brought back into service so the NetScaler ADC instance return to the normal state. VPX and CPX license entitlement
    All VPX models up to 100 Gbps throughput are supported.
    CPX single core/Multi-core are supported.
    vCPU pool for SW ADCs only In the virtual CPU-usage-based licensing feature, the license specifies the number of CPUs that a particular NetScaler ADC VPX is entitled to. So, the NetScaler ADC VPX can check out licenses for only the number of virtual CPUs running on it from the license server. NetScaler ADC VPX checks out licenses depending on the number of CPUs running in the system. NetScaler ADC VPX does not consider the idle CPUs while checking out the licenses.
    vCPU Licensing Documentation
    BLX Pooled Bandwidth
    BLX ModelMinimum MemoryvCPUsThroughputSupported Linux DistributionNon-DPDK4 GB1–81–12 GbpsCentOS, Oracle Linux, Ubuntu Linux,Red Hat Linux    DPDK (Beta)4 GB1–81–100 GbpsCentOS, Oracle Linux, Ubuntu Linux,Red Hat Linux    BLX Product Documentation
    FAQ's and Troubleshooting Pooled Licenses
    Renewing Pooled License for Existing Customers
    Pooled customer is Expired and wants to add a license to ADM. No reboot required. Pooled License Upgrade Process
    Pooled Capacity licenses take precedent and the instance come back with Pooled Capacity licensing.
    Upgrading or Converting to pooled license, the Citrix account shows the perpetual as inactive and pooled as active.
    Redundancy Concerns for Pooled Capacity
    Multi-Pool Behavior
    The appliance establishes a heartbeat connection with the license server and poll it periodically. If the connection is lost, a 30-day grace period goes into effect at the licensed capacity. There is no impact to ADC functionality within the grace period. After 30 days, the ADC will perform a warm reboot & be unlicensed.
    ADM merges 2 capacity pools into one if the expiry date is the same. If the expiry date is not then they are considered as 2 different pools.
    Timeout Issues to Address

    See the ADM Licensing Operations and Grace Periods Section.
    Exposed SNMP Traps from NetScaler ADC
    Pooled License Alarms
    * Configure POOLED-LICENSE-CHECKOUT-FAILURE Alarm* Configure POOLED-LICENSE-ONGRACE Alarm* Configure POOLED-LICENSE-PARTIAL Alarm
    Troubleshooting with Citrix NSCONMSG
    * allnic_err_rl_cpu_pkt_drops : aggregate (all nics) packet drops after CPU limit was reached* allnic_err_rl_pps_pkt_drops : aggregate packet drops system wide after pps limit* allnic_err_rl_rate_pkt_drops : aggregate rate drops system wide* allnic_err_rl_pkt_drops :  Cumulative rate limiting drops due to rate, pps and cpu* rl_tot_ssl_rl_enforced : # of times SSL RL was applied (on new SSL connections)* rl_tot_ssl_rl_data_limited : # of times SSL throughput limit was reached* rl_tot_ssl_rl_sess_limited : # of times SSL TPS limit was reached
    Troubleshooting with Citrix ADM Event Filters
    When you choose the Run Command Action event action, you can create a command or a script that can be run on Citrix ADM for events matching a particular filter criterion.
    You can also set the following parameters for the Run Command Action script:
    Parameter / Description
    $source - This parameter corresponds to the source IP address of the received event.$category - This parameter corresponds to the type of traps defined under the category of the filter$entity - This parameter corresponds to the entity instances or counters for which an event has been generated. It can include the counter names for all threshold-related events, entity names for all entity-related events, and certificate names for all certificate-related events.$severity - This parameter corresponds to the severity of the event.$failureobj - The failure object affects the way an event is processed and ensures that the failure object reflects the exact problem as notified. This can be used to track down problems quickly and to identify the reason for failure, instead of simply reporting raw events.

    Note:
    During command execution, these parameters are replaced with actual values

    Brian Huhn 2
    The intent of this article is to provide clarity on license expiry behavior for various NetScaler licensing models. The following licensing models will be addressed:
     
    -       NetScaler pooled capacity licensing
    -       NetScaler fixed throughput term licensing (NEW)
    -       NetScaler perpetual licensing

    Before discussing these scenarios, know that NetScaler always encourages customers to renew their license before it expires. The best way for customers to avoid all of these license expiration scenarios is to renew and apply the license before it expires.
    NetScaler pooled capacity licensing
     Firstly, the recent changes to NetScaler’s licensing programs have not had any effect on pooled capacity license expiry behavior, and it will remain the same as it has been since the program was launched.
     
    When a pooled capacity license is nearing expiration, the customer, sales rep, and partner (if applicable) will all receive advance notification of when this license will expire. This should provide ample time to purchase and upload a new license.
     
    The expiry date shown in the NetScaler ADM user interface is the final expiry date. However, NetScalers that are licensed with a pooled capacity license will automatically receive a 30 day period of continued functionality past its initial purchase term. These extra 30 days are automatically accounted for in the expiration date, and functionality will not continue past that date. Throughout the 30 days of extra time (leading up to the expiry date), the NetScaler will retain identical functionality. This is true even if the NetScaler is rebooted. If a new license is not applied before the expiry date, the NetScaler will stop processing traffic until a new license is applied. 
     Some have referred to this 30 day period as a “grace period”, but this is not the case. The 30 day period following a license’s expiration date is not the same as “the grace period”. A grace period only occurs when a NetScaler licensed with pooled capacity loses connectivity to NetScaler ADM while the license is still active. The grace period is also a 30 day window where the NetScaler will continue to function as normal. If the NetScaler is in this grace period (due to loss of connectivity to the management plane) and the NetScaler is rebooted, there will not be any impact to the NetScaler’s functionality and it will continue to operate in this grace period. 
     The difference between the expiry window and the grace period is this – during a disconnect grace period, if connectivity is not restored to NetScaler ADM within 30 days, the NetScaler will stop processing traffic, even if the NetScaler license has not expired. Once connectivity is restored, the NetScaler will recognize the active license and return to full functionality.
     
    Corner case scenarios to consider regarding license functionality:
    -   If connectivity is lost to NetScaler ADM, the NetScaler will enter a 30 day grace period. But be warned, if NetScaler connects to the management plane again and the license is missing (very unlikely but possible if someone is messing around with their management license) then the grace will terminate and the NetScaler will enter express mode.
    -   If the license has not expired, but the grace period was started due to lack of management plane connectivity, the grace period will not terminate upon a reboot.
     
    For more information regarding pooled capacity licensing troubleshooting, follow this link or reach out to your NetScaler sales rep or partner.
     NetScaler fixed throughput term licensing
    This is a new licensing model for NetScaler and it does not feature the use of NetScaler ADM. Because of this, the licensing expiry behavior is not the same as pooled capacity.
     
    However, they do share the following similarity. When a license is nearing expiration, the customer, sales rep, and partner (if applicable) will all receive advance notification of when this license will expire. This should provide ample time to purchase and upload a new license.
     
    If a NetScaler fixed throughput term license expires, the NetScaler will continue to function indefinitely until it is rebooted. Upon reboot, the NetScaler will stop processing traffic. At this stage, the only way to restore functionality is to apply a new license.
     
     
    NetScaler perpetual licensing
    The recent changes to NetScaler’s licensing programs have had no effect on Perpetual renewals and the corresponding hardware maintenance.
     The NetScaler perpetual license does not expire. However, hardware maintenance is required for perpetual licensing, and does expire on a termed basis. If hardware maintenance is not renewed, the customer will no longer be able to receive support.

     

    Isha Khurana
    Today I am excited to announce the general availability (GA) of the NetScaler App Delivery and Security service (ADS service) support for Azure workloads.  App Delivery and Security service is the industry’s first intent-based, continuously optimising, self-healing, internet-aware application delivery service and this GA marks the anchor for App Delivery and Security service service to support hybrid multi-cloud workloads across on-premises/private clouds, and also AWS and Azure clouds.
    App Delivery and Security (ADS) service embarked its journey on 5th April 2022 when the service was generally available for AWS cloud workloads and Multi-Site/Internet facing Apps. Since then the customers resonate with the value it creates. I would like to take this as an opportunity to share below testimonial from the customer: 
    “Within a week of App Delivery and Security service's deployment, customer observed a DDoS attack that did not reach data center because it is scrubbed by App Delivery and Security service”
     
    Over the one-year of App Delivery and Security service journey, customers leveraged the ADS service and shared their requirements. The NetScaler team has added a lot of features and supports multiple deployment architectures based on customer requirements. For more info on the list of new features below explore this  link.
     
    Get started with App Delivery and Security service with your hybrid multi cloud workloads ( AWS, Azure) today by logging into your cloud.citrix.com account and click "Request Trial" on App Delivery and Security tile.
     

     
     
    Disclaimer: The development, release and timing of any features or functionality described for our products remains at our sole discretion and are subject to change without notice or consultation. The information provided is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making purchasing decisions or incorporated into any contract.

    NetScaler Cyber Threat Intelligence
    NetScaler WAF mitigates risk from MOVEit SQLi vulnerability 
     
     
    NetScaler has new signatures available for its integrated Web App Firewall to help customers mitigate the recent authentication bypass vulnerability in multiple versions of MOVEit Transfer’s database (versions prior to 2021.0.6 (13.0.6), 2021.1.4 (13.1.4), 2022.0.4 (14.0.4), 2022.1.5 (14.1.5), and 2023.0.1 (15.0.1)). The vulnerability CVE-2023-34362 affects all versions (e.g., 2020.0 and 2019x) before the five explicitly mentioned versions, including older unsupported versions. 
    The new signatures protect customers from the recent CVE-2023-34362 vulnerability found in versions of Progress Software's MOVEit Transfer's database that encompasses multiple attack vectors privilege escalation, SQLi injection, Remote Code Execution.  
    The vulnerability is classed as critical. Customers should apply the latest NetScaler WAF signature file to help mitigate exploitation of this vulnerability in their environments.You can download the signatures and apply them immediately.  
     
    Mitigating CVE-2023-34362
    The NIST database has details about the vulnerability:
     
    In Progress MOVEit Transfer before 2021.0.6 (13.0.6), 2021.1.4 (13.1.4), 2022.0.4 (14.0.4), 2022.1.5 (14.1.5), and 2023.0.1 (15.0.1), a SQL injection vulnerability has been found in the MOVEit Transfer web application that could allow an unauthenticated attacker to gain access to MOVEit Transfer's database. Depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an attacker may be able to infer information about the structure and contents of the database, and execute SQL statements that alter or delete database elements. NOTE: this is exploited in the wild in May and June 2023; exploitation of unpatched systems can occur via HTTP or HTTPS. All versions (e.g., 2020.0 and 2019x) before the five explicitly mentioned versions are affected, including older unsupported versions.
     
     
     
    The vendor (Progress Software) recommends that users of MOVEit Transfer immediately adhere to their published mitigation measures and apply the appropriate patch to the software in order to prevent exploitation of this SQLi vulnerability. 
    NetScaler customers can quickly implement the  following recommendations to help reduce risk and lower exposure associated with this vulnerability. If you are using any of the affected MOVEit Transfer  versions, NetScaler strongly recommends that you download the version 106 or later of the signature file and apply it to your NetScaler Web App Firewall deployments as an additional layer of protection for your applications.  Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: software versions 11.1 and 12.0 are end of life and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
     
     
      Signature rule
      CVE ID
      Description
      998690
      CVE-2023-34362
      WEB-MISC Progress MOVEit Transfer Multiple Versions - SQL Injection Vulnerability (CVE-2023-34362)
     
     
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 106 or later and then follow these steps.
     
    Search your signatures for CVE-2023-34362 LogString Select the results with ID  Choose “Enable Rules” and click OK NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
     
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
     
     
    Modifications to NetScaler Web App Firewall Policy:
     
    add policy patset exception_list # (Example: bind policy patset exception_list “/exception_url”)   
    Prepend the existing WAF policy with:
     
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^  
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks from CVE-2023-34362.
     
    Additional Information
     
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
     
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
     
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 
     
     

    Konstantinos Kaltsas
    Simplified Content Switching with Terraform
    Submitted Dec 12, 2023Author: Bhalchandra Chaudhari

    Continuing to our Parent-Child Terraform deployment, in the last blog, we saw the SSL offloading feature with simplified Terraform re-usable modules, which helps to keep your common configuration intact within the NetScaler infrastructure itself.  Today, we will see a similar use case for the layer 7 type load balancing feature of NetScaler, i.e., Content Switching, simplified with terraform modules. Content Switching enables the NetScaler ADC appliance to direct requests sent to the same Web host to different servers with different content. Find more details about the “Terraform Parent-Child” deployment in the mentioned SSL offloading article.
    Below is the Content Switching load balancing created using Terraform parent-child deployment
    Child Modules prepared to call in root/parent module:
    SSL certificate key-pair
    SSL cipher group for frontend traffic
    SSL cipher group for backend traffic
    SSL CS virtual server configuration and parameters set.
    HTTP CS virtual server configuration for secure redirection
    Require target load balancing set up.
    Content Switching actions and policies.
    Responder for HTTP to HTTPS redirection
    Parent/Root modules:
    Application-specific module, e.g., corpservices.example.com
    The directory structure for this deployment is as below
     
    ├───citrixadc - Citrix ADC terraform provider files├───commonmodules - child/shared module main directory│ ├───cipher_svc - child (shared) module backend cipher group│ ├───cipher_vs - child (shared) module frontend cipher group│ ├───lbservice - child (configuration) module load balancing services│ ├───responder_httpTohttps - child (shared) module for responder│ └───sslcertkeypair - child (shared) module SSL certificate keypair ├───contentswitching - feature parent directory/module │ └───corporate.example.com - application root/parent directory/module│ ├───TargetLB1 - child (configuration) module load balancing services│ ├───TargetLB2 - child (configuration) module load balancing services│ └───TargetLB3 - child (configuration) module load balancing services└───sslcerts - SSL files (cert and key) directory
     
    Each module contains its terraform files to prepare the configuration plan and helps the root module execute the configuration depending on variable attributes/parameter values.
    The child or shared modules have their own configuration plan. The respective shared module values are provided as references in the application root module so that the required shared configuration should not get destroyed/changed if there is any change in application attributes/parameters. The necessary states are maintained separately.

    Below is the terraform structure depicts each main directory module and sub-directory (child module) with respective terraform files:
     
    │ .gitignore│ secret.tfvars│├───citrixadc├───commonmodules│ ├───cipher_svc│ │ │ .terraform.lock.hcl│ │ │ output.tf│ │ │ provider.tf│ │ │ README.md│ │ │ resources.tf│ │ │ terraform.tfstate│ │ │ terraform.tfstate.backup│ │ │ variables.tf│ ││ ├───cipher_vs│ │ │ .terraform.lock.hcl│ │ │ output.tf│ │ │ provider.tf│ │ │ README.md│ │ │ resources.tf│ │ │ terraform.tfstate│ │ │ terraform.tfstate.backup│ │ │ variables copy.tf│ │ │ variables.tf│ ││ ├───lbservice│ │ output.tf│ │ README.md│ │ resources.tf│ │ variables.tf│ ││ ├───responder_httpTohttps│ │ │ .terraform.lock.hcl│ │ │ output.tf│ │ │ provider.tf│ │ │ resources.tf│ │ │ terraform.tfstate│ │ │ terraform.tfstate.backup│ │ │ terraform.tfvars│ │ │ variables.tf│ ││ └───sslcertkeypair│ │ .terraform.lock.hcl│ │ output.tf│ │ provider.tf│ │ README.md│ │ resources.tf│ │ terraform.tfstate│ │ terraform.tfvars│ │ variables.tf│├───contentswitching│ │ README.md│ ││ └───corporate.example.com│ │ .terraform.lock.hcl│ │ provider.tf│ │ README.md│ │ resources.tf│ │ terraform.tfstate│ │ terraform.tfstate.backup│ │ terraform.tfvars│ │ variables.tf│ ││ ├───TargetLB1│ │ │ .terraform.lock.hcl│ │ │ provider.tf│ │ │ resources.tf│ │ │ terraform.tfstate│ │ │ terraform.tfstate.backup│ │ │ terraform.tfvars│ │ │ variables.tf│ ││ ├───TargetLB2│ │ │ .terraform.lock.hcl│ │ │ provider.tf│ │ │ resources.tf│ │ │ terraform.tfstate│ │ │ terraform.tfstate.backup│ │ │ terraform.tfvars│ │ │ variables.tf│ ││ └───TargetLB3│ │ .terraform.lock.hcl│ │ provider.tf│ │ resources.tf│ │ terraform.tfstate│ │ terraform.tfstate.backup│ │ terraform.tfvars│ │ variables.tf│ ││ └───sslcerts bkclab.cer.cert bkclab.cer.key terracert.cert terracert.key
     
    You can find the required terraform files of all modules here , where the resource block of each child module is called using data resource to configure load balancing entity.
     
    Execution
    As states are maintained separately, each child module except “lbservice” runs individually to refer to the output value of each in the parent application module. Similarly, the target LBs are executed to keep the web application content requests separate. 
    On running terraform init, terraform plan, and terraform apply, the module creates all the required entities and bindings between them, as shown below.
     
    PS C:\Users\bkchaudhari\article\contentswitching\corporate.example.com> terraform initInitializing modules... Initializing the backend... Initializing provider plugins...- terraform.io/builtin/terraform is built in to Terraform- Finding latest version of citrix/citrixadc...- Installing citrix/citrixadc v1.32.0...- Installed citrix/citrixadc v1.32.0 PS C:\Users\bhalchandrac\ssloffload\example.com> terraform plan -var-file="../../secret.tfvars" Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Intentionally I skipped the plan output, to reduce the article size. Terraform will create 23 resources to configure content switching. PS C:\Users\bhalchandrac\article\example.com> terraform apply -var-file="../../secret.tfvars" Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create……….………………Terraform will perform the following actions:Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes citrixadc_csaction.tf_csaction3: Creating...module.loadbalancingservices.citrixadc_server.tf_server["testservermain01"]: Creating...citrixadc_csaction.tf_csaction2: Creating...citrixadc_csaction.tf_csaction1: Creating...module.loadbalancingservices.citrixadc_server.tf_server["testservermain02"]: Creating...citrixadc_csvserver.tf_csvserverssl: Creating...citrixadc_csvserver.tf_csvserverhttp: Creating...citrixadc_lbvserver.tf_lbvserverhttp: Creating...citrixadc_csaction.tf_csaction3: Creation complete after 0s [id=csact.webapp3]citrixadc_cspolicy.tf_cspolicy3: Creating...citrixadc_csaction.tf_csaction2: Creation complete after 0s [id=csact.webapp2]citrixadc_cspolicy.tf_cspolicy2: Creating...citrixadc_csaction.tf_csaction1: Creation complete after 0s [id=csact.webapp1]citrixadc_cspolicy.tf_cspolicy1: Creating...module.loadbalancingservices.citrixadc_server.tf_server["testservermain01"]: Creation complete after 0s [id=testservermain01]module.loadbalancingservices.citrixadc_server.tf_server["testservermain02"]: Creation complete after 0s [id=testservermain02]module.loadbalancingservices.citrixadc_service.tf_service["testservermain02"]: Creating...module.loadbalancingservices.citrixadc_service.tf_service["testservermain01"]: Creating...citrixadc_cspolicy.tf_cspolicy3: Creation complete after 1s [id=cspol.webapp3]citrixadc_cspolicy.tf_cspolicy2: Creation complete after 1s [id=cspol.webapp2]citrixadc_cspolicy.tf_cspolicy1: Creation complete after 1s [id=cspol.webapp1]module.loadbalancingservices.citrixadc_service.tf_service["testservermain02"]: Creation complete after 1s [id=testservermain02-443]citrixadc_lbvserver.tf_lbvserverhttp: Creation complete after 1s [id=corpwebapp.corporate.com:443]citrixadc_csvserver.tf_csvserverhttp: Creation complete after 1s [id=corpservices.example.com:80]citrixadc_csvserver_responderpolicy_binding.tf_bind: Creating...module.loadbalancingservices.citrixadc_service.tf_service["testservermain01"]: Creation complete after 1s [id=testservermain01-443]citrixadc_lbvserver_service_binding.tf_bindinghttp["testservermain02"]: Creating...citrixadc_lbvserver_service_binding.tf_bindinghttp["testservermain01"]: Creating...citrixadc_csvserver_responderpolicy_binding.tf_bind: Creation complete after 0s [id=corpservices.example.com:80,httptohttps_pol]citrixadc_csvserver.tf_csvserverssl: Creation complete after 1s [id=corpservices.example.com:443]citrixadc_lbvserver_service_binding.tf_bindinghttp["testservermain01"]: Creation complete after 0s [id=corpwebapp.corporate.com:443,testservermain01-443]citrixadc_sslvserver.tf_cssslvserver: Creating...citrixadc_csvserver_cspolicy_binding.tf_cspolbind1: Creating...citrixadc_sslvserver_sslciphersuite_binding.tf_cssslvserver_sslciphersuite_binding: Creating...citrixadc_csvserver_cspolicy_binding.tf_cspolbind3: Creating...citrixadc_lbvserver_service_binding.tf_bindinghttp["testservermain02"]: Creation complete after 0s [id=corpwebapp.corporate.com:443,testservermain02-443]citrixadc_csvserver_cspolicy_binding.tf_cspolbind2: Creating...citrixadc_sslvserver_sslcertkey_binding.cert_bindingcs: Creating...citrixadc_csvserver.tf_defaulttargetbinding: Creating...citrixadc_csvserver_cspolicy_binding.tf_cspolbind1: Creation complete after 1s [id=corpservices.example.com:443,cspol.webapp1]citrixadc_csvserver_cspolicy_binding.tf_cspolbind3: Creation complete after 1s [id=corpservices.example.com:443,cspol.webapp3]citrixadc_sslvserver_sslciphersuite_binding.tf_cssslvserver_sslciphersuite_binding: Creation complete after 1s [id=corpservices.example.com:443,CorporateExternal]citrixadc_csvserver_cspolicy_binding.tf_cspolbind2: Creation complete after 1s [id=corpservices.example.com:443,cspol.webapp2]citrixadc_sslvserver_sslcertkey_binding.cert_bindingcs: Creation complete after 1s [id=corpservices.example.com:443,terracert]citrixadc_sslvserver.tf_cssslvserver: Creation complete after 1s [id=corpservices.example.com:443]citrixadc_csvserver.tf_defaulttargetbinding: Creation complete after 1s [id=corpservices.example.com:443] Apply complete! Resources: 23 added, 0 changed, 0 destroyed. Outputs: csaction1 = "csact.webapp1"csaction2 = "csact.webapp2"csaction3 = "csact.webapp3"cspolicy1 = "cspol.webapp1"cspolicy1binding = "corpservices.example.com:443,cspol.webapp1"cspolicy2 = "cspol.webapp2"cspolicy2binding = "corpservices.example.com:443,cspol.webapp2"cspolicy3 = "cspol.webapp3"cspolicy3binding = "corpservices.example.com:443,cspol.webapp3"cssslvserver_certbinding = "corpservices.example.com:443,terracert"cssslvserver_cipherbinding = "corpservices.example.com:443,CorporateExternal"csvserverhttp = "corpservices.example.com:80"csvserverssl = "corpservices.example.com:443"lbservices = [ "testservermain01-443", "testservermain02-443",]lbvserverhttp = "corpwebapp.corporate.com:443"
     
    The module creates all the required entities and binding between them.
    Note: This module does not show the destroy function of content-switching entities. The parent module can be destroyed entirely at once; however, the target load balancing virtual cannot be destroyed if it has a CS action attached. To remove or change the target LB, unset the target LB from the action and then change/destroy the configuration.

    Conclusion
     
    You can use the NetScaler and Terraform solutions for new content switching or adding settings to existing content switching, or to customize a deployment to fit with the application content access that you want to provide to end users as they need. NetScaler Terraform modules enable an infrastructure-as-code approach and seamlessly integrate with your automation environment using reusable modules.

     
    What's next?
    How to get started with NetScaler Automation Toolkit?
    (You can find all NetScaler Automation Toolkit details in our Automation Toolkit GitHub repository ) 
    1. Visit the hands-on labs for Terraform with NetScaler to familiarize yourself with NetScaler Automation Toolkit.
     
    Basic Load Balancing Configuration using Terraform Basic Content Switching Configuration using Terrafor Basic Rewrite / Responder Policies Configuration using Terraform Basic Application Protection Configuration (WAF) using Terraform 2. Set up your private lab by following NetScaler's Get Started guides for Terraform.
     
    Get Started with NetScaler Automation Toolkit using Terraform  
    3. Follow the Beginners Guide to get comfortable with common commands.
     
    Beginners guide to automating ADC with terraform on GitHub  
    4. Be part of the Community. Pick a common NetScaler use case/configuration, create a Terraform template, and publish it on the NetScaler Community.
     
    Additional resources for NetScaler Automation Toolkit?
    Visit the following links to get more details on using Terraform with NetScaler.
    ADC Terraform Provider on Terraform Registry ADC Terraform Provider on GitHub ADM Terraform Provider on GitHub SDX Terraform Provider on GitHub BLX Terraform Provider on GitHub Terraform Templates to Provision VPX on GitHub

    Guest
    PoC Guide: nFactor for NetScaler Gateway Authentication with Native OTP
    November 28, 2022
    Author:  Matthew Brooks, Alyssa Ramella
    Special thanks:  Himanshu Shukla Introduction
    Implementing multifactor authentication is one of the best ways to verify identity, and improve security posture. Native (time-based) One Time Password (OTP) is a convenient way to implement another factor using readily available authenticator applications. It allows users to enter validation codes from their authenticator application, into a gateway form, to authenticate.
    NetScaler Gateway supports Native OTP, and can provide authentication for various services including web services, VPN, and Citrix Virtual Apps and Desktops. In this POC Guide we demonstrate using it for authentication in a Citrix Virtual Apps and Desktops environment.
    Conceptual Architecture


    Overview
    This guide demonstrates how to implement a Proof of Concept environment using two factor authentication with NetScaler Gateway. It uses LDAP to validate Active Directory credentials as the first factor, and Native OTP as the second factor.
    It makes assumptions about the completed installation, and configuration of the following components:
    NetScaler Gateway installed, licensed, and configured with an externally reachable virtual server bound to a wildcard certificate NetScaler Gateway integrated with a Citrix Virtual Apps and Desktops environment which uses LDAP for authentication Endpoint with Citrix Workspace app installed A supported Authenticator app, that supports Time Based OTP, installed (including Microsoft Authenticator, Google Authenticator, or Citrix SSO) Active Directory (AD) is available in the environment Refer to Citrix Documentation for the latest product version, and license requirements: Native OTP AuthenticationnFactor
    LDAP Policies
    First we create two LDAP policies which we reference later when we are building our nFactor flow.
    Native OTP Registration
    This LDAP registration policy is used to exchange, and store the key used to generate the time based OTP code.
    Log in to the NetScaler ADC UI Navigate to Security > AAA-Application Traffic > Policies > Authentication > Advanced Policies > Policy Click Add Enter polldap_notpmanage for the policy name, and change the Action Type to LDAP. Click Add under Action Populate the following fields: Name - enter actldap_notpmanage Server Name / IP address - select an FQDN or IP address for AD server/(s). We enter 192.0.2.50 Clear Authentication This setting along with the OTP Secret below indicate the policy will set, rather than get, object attributes Base DN - enter the path to the AD user container. We enter DC=workspaces, DC=wwco, DC=net Administrator Bind DN - enter the admin/service account to query AD to authenticate users. We enter workspacessrv@workspaces.wwco.net Confirm / Administrator Password - enter / confirm the admin / service account password Click Test Network Connectivity to ensure connection Server Logon Name Attribute - in the second field below this field enter userPrincipalName OTP Secret - Enter userParameters This is the User’s LDAP object that will get updated with the key that`s used with hash to generate the time based OTP code Select Create ​​​​​​ 
          8. Enter the expression true, and click OK
     

    Native OTP Authentication
    This LDAP authentication policy is used to do the first factor authentication.
    Navigate to Security > AAA-Application Traffic > Policies > Authentication > Advanced Policies > Policy Click Add Enter polldap_notpauth for the policy name, and change the Action Type to LDAP. Click Add under Action Populate the following fields: Name - enter actldap_notpauth Server Name / IP address - select an FQDN or IP address for AD server/(s). We enter 192.0.2.50 Base DN - enter the path to the AD user container. We enter DC=workspaces, DC=wwco, DC=net Administrator Bind DN - enter the admin/service account to query AD to authenticate users. We enter workspacessrv@workspaces.wwco.net Confirm / Administrator Password - enter / confirm the admin / service account password Click Test Network Connectivity to ensure connection Server Logon Name Attribute - in the second field below this field enter userPrincipalName Select Create  
         7. Enter the expression true, and click OK
     
     

    For more information see LDAP authentication policies
    Login Schemas
    Login Schemas are used when data needs to be gathered on behalf of a policy.
    Native OTP lSchema - Single Authentication
    This registration login schema corresponds to the LDAP registration policy.
    Navigate to Security > AAA-Application Traffic > Login Schema Select the Profile tab Click Add under Profile, and name it prolschema_notpsingle Click the pencil icon next to noschema Click Login Schema, and scroll down to select SingleAuthManageOTP.xml, and select the blue Select in the right corner. Click Create Native OTP lSchema - Dual Authentication
    This registration login schema corresponds to the dual factor authentication where the user enters both their password, and the OTP passcode.
    Under the Profile tab click Add again Enter the name pollschema_notpdual Click Add under Profile, and also name it prolschema_notpdual Click the pencil icon next to noschema Click Login Schema, and scroll down to select DualAuth.xml, and select the blue Select in the right corner. Click More In the field Password Credential Index enter 1 Click Create Native OTP AAA Virtual Server - Visualizer Flow
    Next navigate to Security > AAA - Application Traffic > nFactor Visualizer > nFactor Flows Click Add Click the + sign to create the initial factor. This factor will not take action, rather handle directing incoming traffic to registration or authentication factor flows. Enter factor0-notp, and click Create Registration Flow
    Select Add Policy Select Add next to Select Policy Enter name polfactor0-notpmanage Set the Action Type to NO_AUTHN Paste in HTTP.REQ.COOKIE.VALUE(“NSC_TASS”).EQ(“manageotp”) for the expression OR build it with Expression builder
    You can optionally limit registration to endpoints on the internal network by adding a source IP address criteria such as http.req.cookie.value("NSC_TASS").eq("manageotp") && client.IP.SRC.IN_SUBNET(10.0.0.0/8)
    Click Create, followed by Add  
     
    Select the green + to the right of the polfactor0-notpmanage policy you just created Enter factor1-notpmanage, and click Create
    In the new factor box, select Add Schema Select prolschema_notpsingle, and click Ok Select Add Policy From the drop-down list under Select Policy select polldap_notpauth, and click Add Select the green + to the right of the polldap_notpauth policy Enter factor2-notpmanage, and click Create
    In the new factor box, select Add Policy From the drop-down list under Select Policy select polldap_notpmanage, and click Add ​​​​​​​ Authentication Flow
    Now in the initial factor box we created factor0-notp, select the blue + Select Add next to Select Policy Enter name polfactor0-notpauth Set the Action Type to NO_AUTHN Enter true for the expression Click Create, followed by Add Notice that the policy priority has increased to 110 meaning it will be executed only if the above policy polfactor0-notpmanage at 100 is not a match.
    Select the green + to the right of the polfactor0-notpauth policy you just created Enter factor1-notpauth, and click Create In the new factor box, select Add Schema Select prolschema_notpdual, and click Ok Select Add Policy From the drop-down list under Select Policy select polldap_notpauth, and click Add Select the green + to the right of the polldap_notpauth policy you just created Enter OTPCheck, and click Create Select Add Policy From the drop-down list under Select Policy select polldap_notpmanage, and click Add Select Done ​​​​​​​
    Native OTP AAA Virtual Server
    This AAA Virtual Server is where the policies and schema are bound with the appropriate priority.
    Navigate to Traffic Management > SSL> Certificates > All Certificates to verify you have your domain certificate installed. In this POC example we used a wildcard certificate corresponding to our Active Directory domain. See NetScaler ADC SSL certificates for more information. Next navigate to Security > AAA - Application Traffic > Virtual Servers, and select Add Enter the following fields: Name - a unique value. We enter nativeotp_authvserver IP Address Type - Non Addressable Click Ok Select No Server Certificate, select the arrow under Select Server Certificate, select the domain certificate, click Select, Bind, and Continue Under Advanced Authentication Policies, select No Nfactor Flow Select the right arrow under Select nFactor Flow, select factor0_notp, click Select, click Bind
    Click Continue, followed by Done
    Traffic Policy
    Now we create a traffic policy to relay the LDAP password to StoreFront, instead of the OTP passcode.
    Navigate to NetScaler Gateway > Virtual Servers > Policies > Traffic Select the Traffic Profiles Tab, and click Add Enter the name notp_trafficprofile Select HTTP In the SSO Password Expression enter http.REQ.USER.ATTRIBUTE(1) Click Create​​​​​​​
    Now click the Traffic Policies Tab In the Request Profile field, select the notp_trafficprofile Traffic Profile you just created. Enter the name nOTP_TrafficPolicy In the Express box enter true Click Create Gateway Virtual Server
    The Gateway Virtual Server is bound to the Native OTP AAA Virtual Server to provide authentication for Citrix Virtual Apps and Desktops.
    Navigate to NetScaler Gateway > Virtual Servers Select your current Gateway, and click Edit Select Authentication Profile from the Advanced Settings panel on the right hand side Select Add Enter a profile name. We enter nativeotp_authprofile Under Policy select the arrow, and select the Native OTP AAA Virtual Server nativeotp_authvserver Click Create Select Policies from the Advanced Settings panel on the right hand side Select the + sign to Add Under Choose Policy select Traffic, and under Choose Type select Request. The select Continue Click the right arrow, select notp_trafficpolicy, and select OK Click Done, and save the running configuration ​​​​​​​ 
    ​​​​​​​ User Endpoint
    Now we test Native OTP by authenticating into our Citrix Virtual Apps and Desktops environment.
    Registration with Citrix SSO app
    First the user registers their device for Native OTP using the Citrix SSO app.
    Open a browser, and navigate to the domain FQDN managed by the NetScaler Gateway with /manageotp appended to the end of the FQDN. We use https://gateway.workspaces.wwco.net/manageotp After your browser is redirected to a login screen enter user UPN, and password ​​​​​​​ On the next screen select Add Device, enter a name. We use iPhone7_nOTP ​​​​​​​ Select Go, and a QR code appears ​​​​​​​
    On your mobile device open your Citrix SSO app or other authenticator app such as Microsoft or Google’s (available for download from app stores) Select Add New Token Select Scan QR Code ​​​​​​​Select Aim your camera at the QR Code, and once it`s captured select Add ​​​​​​​
    Select Save to store the token ​​​​​​​ The Token is now active, and begins displaying OTP codes at 30 second intervals ​​​​​​​
    Select Done and you see confirmation that the device was added successfully ​​​​​​​ Citrix Virtual Apps and Desktops Authentication, Publication, and Launch
    Then the user enters their UserPrincipalName, Password, and the OTP Passcode from the Citrix SSO app to access their virtual apps, and desktops.
    Open a browser, and navigate to the domain FQDN managed by the NetScaler Gateway. We use https://gateway.workspaces.wwco.net After your browser is redirected to a login screen enter user UserPrincipalName, and password Open the Citrix SSO app enter the OTP code in the passcode field for the iPhone7_nOTP device entry ​​​​​​​ Verify the users virtual apps, and desktops are enumerated, and launch once logged in ​​​​​​​
    Troubleshooting
    Here we look at a couple common troubleshooting areas for Native OTP.
    NTP Errors
    Upon login with your OTP code the page may post a message advising you to verify NTP synchronization. The NetScaler ADC’s time must be sync in order to generate the correct time based OTP. If you have not implemented NTP follow these steps:
    Set the time manually on your NetScaler ADC to the current time. This will speed up the synchronization that would otherwise take a longer period time Add NTP Server/s If you still get an NTP error upon submitting the OTP code see Time Display on NetScaler Does Not Sync Using NTP Authentication ErrorsCannot complete your request. - if this error message occurs after successful authentication it likely indicates an error passing user credentials to StoreFront. Verify the Dual Authentication schema and Traffic Policy settings. ​​​​​​​
    Try again or contact your help desk - this error message often indicates a LDAP login failure. ​​​​​​​If you have verified the password is correct verify the Administrator bind password has been set. You may have had an existing LDAP authentication policy, and created the manage policy by selecting it, followed by selecting add. This step saves time by populating existing settings like the Base DN, and you may see the Administrator password field appears to be populated, but you MUST reenter the password. ​​​​​​​Summary
    With Citrix Workspace, and NetScaler Gateway, Enterprises can improve their security posture by implementing multifactor authentication without making the user experience complex. Users can gain access to their Citrix Virtual Apps and Desktops, by entering their domain user name, and password, and then simply confirming their identity by entering a One Time Password from their registered authenticator app.
    References
    For more information refer to:
    Native OTP Authentication – find more details regarding Native OTP implementation, and use cases.
     
     
       

×
×
  • Create New...