Jump to content
Welcome to our new Citrix community!
  • NetScaler TIPs: Moving off deprecated NetScaler ADC features for Gateway

    Guest Sara Austin
    • Validation Status: Validated
      Has Video?: No

    NetScaler TIPs: Moving off deprecated NetScaler ADC features for Gateway

    Submitted August 4, 2021

    Author: Andrew Wang


    Since NetScaler ADC release 12.0 build 41.16, there have been announcements of deprecated features. Even though features such as classic policies, certain themes, and classic EPA have been deprecated since 12.0, they are still supported in releases 12.1 and 13.0.

    For customers that want to futureproof their environment, we recommend planning the move to supported features now. Some aspects of the transition to supported features will be relatively easy, while others, such as moving authentication into a nFactor virtual server, require more configuration.

    This blog post focuses on the deprecated features for Gateway you will need to transition off and details some common pitfalls and how to avoid them.

    Classic Policies

    NetScaler ADC policies are used to control how a feature evaluates data. Classic policies evaluate basic characteristics of traffic and other data, while advanced policy infrastructure (PI) enables you to analyze more data and configure more operations in the policy rule. The deprecation of classic policies was first announced a couple of years ago and you may have seen this warning when configuring policies in recent NetScaler ADC versions:


    Note: Classic Gateway and AAA policies will continue to remain available with no changes to existing functionality until Q2 2023.

    There is a NetScaler ADC proprietary nspepi tool that can be used to convert commands, expressions, and configurations. Alternatively, the expression editor in the NetScaler ADC GUI is a good way to manually rebuild a classic expression into an advanced expression.

    Keep in mind you will want to convert all your classic policies into advanced policies to be fully supported. This includes policies such as LDAP, RADIUS, CERT, session, and syslog.

    One way to double-check that the classic policies are accounted for is to do a search in your running nsconfig for the classic expressions. Some common keywords to use are “REQ.HTTP” and “ns_true.” Note that these two examples will help you to find most, but not necessarily all, of your classic policies. Make sure an advanced policy exists for each of these policies and that the advanced policy is the one that is bound to your virtual servers.

    Advanced Authentication Policies

    Now you’ve converted all your classic policies to advanced policies, we come to our first challenge. If you are using Gateway for ICA proxy or VPN, authentication policies are bound as part of the configuration. Classic authentication policies can be bound to the basic authentication section of the Gateway virtual server but advanced authentication policies cannot be. To use advanced authentication policies, you must configure an authentication virtual server and bind it to an authentication profile on the Gateway virtual server.

    For the single factor use case, it is as simple as creating the authentication virtual server and binding the advanced authentication policy and a login schema to the server. For the multifactor use case, you’ll need to configure nFactor authentication. We’ve supported nFactor for Gateway since release 11.1, so a lot of configuration information already exists on how to set it up. With NetScaler ADC release 13.0 build 36.27, there is a new feature that simplifies nFactor configuration through the GUI called nFactor Visualizer. Because this feature is relatively new, I’ll share a few lessons learned that will help with your deployment.

    With nFactor Visualizer, you first set up an nFactor flow and bind that flow to the authentication virtual server. Let’s look at a common authentication configuration with two-factor authentication using LDAP and RSA. Below are two configuration examples — one is correct, and one isn’t.


    In Flow 1, shown above, a dual authentication login schema is bound to the first factor along with a LDAP advanced authentication policy. The green plus sign links a second-factor flow that has a RADIUS advanced authentication policy. This means that if the LDAP authentication is successful, it will go to the second factor, which is RSA.

    In the nFactor Flow 2 example, both the LDAP and RADIUS are bound together with the login schema. A successful LDAP and RADIUS authentication will also take you to StoreFront. However, behind the scenes, the RSA policy is not actually being checked; only LDAP is. While it may seem like two-factor authentication is working, you are actually only running single-factor. The takeaway here is that for each factor you have, you need a separate flow box for it.

    Similarly, if you are running a Gateway virtual server with PIV authentication, the LDAP group extraction policy should be set up on a different factor than the PIV advanced authentication policy. It will look something like this:

    nFactor Flow 3


    Along with classic policies being deprecated, certain themes are, as well. If you are using Default, Green Bubble, or X1, you might have noticed a warning like the one below:


    We recommend using the RFWebUI theme with nFactor and advanced policy configuration. If you currently use one of the deprecated themes and have customizations configured, those customizations will not carry over to RfWebUI. The customization mechanism is different for RfWebUI and will need to be reconfigured. One difference is that the logon page for RfWebUI is served out of a different location (/var/netscaler/logon/LogonPoint/) than the deprecated themes (/netscaler/ns_gui/vpn/). The files that need to be customized are also different (index.html, strings.en.json and theme.css for RfWebUI).

    Additional Considerations

    As you’re converting policies from classic to advanced, you might notice errors when attempting to bind the advanced policy. In NetScaler's product documentation, you’ll find this disclaimer:

    Note: The NetScaler ADC supports either classic or advanced policy within a feature. You cannot have both types in the same feature.

    This means if you have multiple Gateway virtual servers and have session policies bound on them, you will get an error if you attempt to bind an advanced session policy on one Gateway virtual server and have classic session policies on the other Gateway virtual servers. You will need to first unbind all the classic session policies on the NetScaler ADC before being able to bind any advanced session policies.

    .We recommend using EPA with nFactor instead of Classic EPA. This means any pre-authentication or post-authentication policies that are currently bound directly to the Gateway will need to be removed and configured within the authentication virtual server instead.

    Key Takeaways

    Customers looking to move off deprecated NetScaler ADC features will need to consider the following action items:

    • Convert all classic policies to advanced policies
    • Do a search in the running configuration to make sure no classic expressions are missed
    • Use an authentication virtual server to bind advanced authentication policies to a Gateway virtual server
    • Simplify your nFactor configuration with nFactor Visualizer, a new feature in ADC 13.0
    • Make sure the credential index in the session policy matches up to your LDAP factors
    • Switch older unsupported themes to RfWebUI theme
    • Unbind all classic policies within a feature before binding advanced policies
    • Configure nFactor EPA for any pre-authentication and post-authentication policies

    Remember, the above items cover the deprecated features that are needed for Gateway. If you use other NetScaler ADC features, there might be other features you need to address. As always, if you’re looking for assistance implementing the configuration changes in this blog, reach out to our NetScaler Consulting team.

    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.

    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

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

    Create an account

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

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Create New...