Since Citrix 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 an nFactor virtual server, requires more configuration.

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

Classic Policies

Citrix 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 to configure more operations in the policy rule. The deprecation of classic policies was first announced a couple years ago and you may have seen this warning when configuring policies in recent Citrix 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 Citrix ADC proprietary nspepi tool that can be used to convert commands, expressions, and configurations. Alternatively, the expression editor in the Citrix 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 Citrix 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 Citrix 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 Citrix 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 Citrix Gateway since release 11.1, so a lot of configuration information already exists on how to set it up. With Citrix 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 Citrix 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 Citrix 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

Mobile (Citrix Workspace App) Policies

For the LDAP and RADIUS two-factor authentication use case with mobile devices, there may be some changes needed to your session policies. This is because you only need one flow for mobile and non-mobile connections using nFactor flow. With basic authentication it was separated.

Previously, when configuring Citrix Gateway to use RADIUS and LDAP authentication with mobile devices, LDAP was configured as the primary policy for web connections and the secondary policy for Receiver/Workspace connections. The diagram below gives an example of how two-factor with LDAP and RADIUS was configured on basic authentication:

Due to this configuration, the credential index on the session policy that points to LDAP had to be different for web and mobile. For web connections, the credential index was set to primary, and for Citrix Workspace connections, it was set to secondary. When using nFactor flow and advanced policies (nFactor Flow 1), a single flow can handle both mobile and non-mobile devices. This means LDAP can be the primary policy for both use cases, and RADIUS will be secondary. If you previously had the Citrix Workspace session policy pointing to secondary for the credential index, it will now need to be updated to primary for mobile devices to continue to authenticate successfully to Citrix Gateway.

Themes

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 Citrix’s product documentation, you’ll find this disclaimer:

Note: The Citrix 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 Citrix 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 Citrix 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 Citrix Gateway will need to be removed and configured within the authentication virtual server instead.

Key Takeaways

Customers looking to move off deprecated Citrix 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 Citrix Gateway. If you use other Citrix 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 Citrix 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.