Issue: “Malformed Assertion sent to NetScaler; Please contact your administrator” when SAML Auth is not 1st Factor

Issue and Background

While working with one of our customers, a use case came up which required users of certain trusted subnets to forego EPA and be sent straight to SAML authentication, while other subnets would be subject to EPA then SAML as normal. In our 12.1-based configuration, EPA needs to precede SAML due to bugs with post-auth EPA that follows a SAML factor anywhere in the flow.

In our scenario, two advanced authentication policies are present on the AAA-TM Server as the first factor as shown below. One policy performs an EPA scan, the other is a non-authenticating (NO_AUTHN) passthrough factor to allow us to exclude clients from the EPA scan.

While both policies have the SAML SP policy as its next factor, and in both scenarios the first factor works properly and we authenticate to SAML IdP normally the passthrough factor flow will result in a malformed assertion error.

In examining the SAML logs via the SAML-tracer add-on, we noticed the POST responses in working and non-working scenarios were completely different, with the non-working assertion containing the message “The Subject NameID value doesn’t match the configured user!”. We also found evidence of the user “Anonymous” being sent over from Citrix ADC to the SAML IdP. The issue does not present itself when EPA was the first factor, only when the NO_AUTHN factor precedes SAML.

Root Cause

After examining traces with the Citrix DevA team and support, the root cause came down to how NO_AUTHN factors in this order affect SAML authentication. When NO_AUTHN is used, the user is set as “Anonymous” when SAML is a next factor. When EPA is the prior factor, user name is not retrieved so the subject field is not being passed over to SAML IdP, which is default behaviour of the appliance.

Resolution

The resolution here is a slightly common one, as one may find in Googling for addressing other errors with IdPs in different scenarios that seem to choke on subject contents. We adjust a “knob” to disable sending the subject with the SAML request. In our case, this avoids Anonymous being sent over, which is what causes the mess.

We do this by dropping to shell from NetScaler CLI and running following.

Nsapimgr command to disable to send subject field:

nsapimgr_wr.sh -ys call=ns_saml_dont_send_subject

Nsapimgr command to re-enable to send subject field:

nsapimgr_wr.sh -ys call= ns_saml_send_subject

Being the default behaviour of the appliance is for this to be enabled, to have this persist across reboots we’ll need to add an entry into the rc.netscaler file on the primary appliance as follows via CLI:

touch /nsconfig/rc.netscaler  
chmod 644 /nsconfig/rc.netscaler  
echo 'nsapimgr_wr.sh -ys call=ns_saml_dont_send_subject' >> /nsconfig/rc.netscaler