November 24, 2022

Issue and Background

After upgrading firmware on a NetScaler (formerly Citrix ADC, formerly NetScaler ¯\_(ツ)_/¯ ) SDX FIPS appliance (FIPS being the key consideration) from an earlier version of 13.1 to a build at or above 13.1 b27.59, authentication flows that use RADIUS was failing.

Specifically, ahead of where users would get their RADIUS token prompt in the observed use case, they received a “No active policy is found in Primary authentication cascade. Please contact your help desk” message. In this particular case this issue occurred after the LDAPS factor and around the group extraction / selection factor that sent users to one RADIUS platform over another.

This is, as one might appreciate, a major issue for FIPS appliance customers trying to upgrade to later releases to address the recent CVEs covered in CTX463706.

## UPDATE MARCH 2023 – NetScaler Firmware 13.1 b42.47 has re-introduced RADIUS over UDP support. If you are not in a position (technical limitations, etc.) to transition to RADSEC (which also may need a RADIUS proxy) ##

Root Cause and Resolution

This one required a support case as it was assumed initially to be a bug however through log reviews the smoking gun was found in this line:

Nov 10 20:58:48 <local0.err> 10.100.80.52 11/11/2022:01:58:48 GMT HOSTNAME-NSVPX02 0-PPE-0 : default SSLVPN Message 2647 0 : “not a valid transport mode for RADIUS in FIPS mode”

Citrix included in the 13.1 b27.59 build and up, a more compliant code for FIPS 140-3 standards to disallow RADIUS over UDP on NetScaler FIPS appliances and in the given use case, RADIUS over UDP was still used.

The good news is, one of the two RADIUS platforms, FortiAuth supported RADSEC (RADIUS over TLS), unfortunately, the other, PingFederate, does not. It appears no traction was made with Ping despite their allegedly working on this back several years ago. For that nFactor flow, the customer will likely need to transition to SAML for the second factor.

Recommendation: Check whether or not your RADIUS servers support RADSEC, how to configure it, and what new (if any) port is necessary. For example, FortiAuth uses TCP 2083. If the solution does NOT support RADSEC you may need to switch to an alternative authentication mechanism off those authentication servers (perhaps SAML), or perhaps remain on the 13.0 track which at present, does not appear to have this functionality let alone forces it.

Citrix’s instructions for configuring RADIUS over TLS are found here. Note that this option only appears AFTER upgrading to build 27.59 or higher.

Strange how this was not mentioned in the release details of 27.59. Yet it is mentioned clearly in the configuration article for RADIUS over TCP or TLS. (UPDATE MAR 2023 – STATEMENT SINCE REMOVED) There does not appear to be a similar page at present on 13.0 so that release track may be unaffected by this change.

As this particular issue is a little obscure, it is our hope this post helps others expedite getting to their root cause when performing FIPS appliance firmware updates to later 13.1 versions.

Michael Shuster

Michael is Ferroque's founder and a noted Citrix authority, overseeing operations and service delivery while keeping a hand in the technical cookie jar. He is a passionate advocate for end-user infrastructure technology, with a rich history designing and engineering solutions on Citrix, NetScaler, VMware, and Microsoft tech stacks.