Jump to content
Welcome to our new Citrix community!

„No active policy is found in Primary authentication cascade“ after update to 13.0_83.27

Thorsten Kruumlger

Recommended Posts

Hi, I have updated our ADC HA pair from 13.0_67.39 to 13.0_83.27.
Now the following error message appears when logging on to the gateway vServer:
"No active policy is found in primary authentication cascade".

We usually have 2-factor authentication with LDAPS + RADIUS with basic authentication.
I removed the auth policies and created a new LDAPS action and policy (expression: ns_true). I bind the new policy to the gateway vServer as the only one, but the error message still comes. No logon possible.

The funny thing is that logging in to Internet Explorer 11 works without errors!
But Chrome, Edge Chromium and Firefox show the error!
I've also removed the SSL profile and have bound the standard ciphers. But no improvement.

The only thing left for me to do was roll back to 13.0_67.39.


Also interesting:

I have the identical error on a second ADC HA pair in a second independent environment after updating from 13.0_67.39 to 13.0_82.45. Exactly the same error behavior! I also had to roll back these two ADCs.


Does anyone have any idea what could be the cause of the error? Or any ideas what to check or configure?

Thank you for any hints.


2x ADC VPX 200 Advanced with HA (13.0_67.39):
- Basic authentication

Link to comment
Share on other sites

Is your gateway integrated with an authentication vserver?  If so, the authentication policies would need to be on the authe vserver.

Is the authentication policy pointing directly to the domain controller or an LB vserver for ldap on this adc?  If an lb vserver, is the authentication vserver UP or listed as DOWN?  

Check syslog to confirm if the authentication is attempted or look for errors in aaad.debug.


If this is purely a firmware issue and not some other thing, then you may want to contact support. 


There's some notes of ldaps monitor errors for 13.0 but nothing specific to the issue you are seeing.  My initial guess is that if its not a bug due to the policy config, but is affected by the ldap vserver being seen as down then the gateway might not attempt the authentication which results in no authentication attempt.  But the syslog or aaad.debug events may indicate if there is a different problem.


You could also see if doing this in the "advanced" engine via aaa gets around this.  The classic engine should still work on this version...but you are obviously getting some sort of issue.


Can you share the actual policy bindings in case there is something else going on (feel free to obscure ips or other details.):

show ns runningconfig | grep "show vpn vserver" -i




cd /var/log

tail -f ns.log

tail -f ns.log | grep -v CMD_EXEC    # all commands, but audited

tail -f ns.log | grep AAA       # aaa/ authentication stuff

tail -f ns.log | grep VPN        # vpn specific; but usually excludes authentication

## view log while attempt a gateway logon to see if anything useful is displayed



cd /tmp

cat aaad.debug

## then attempt logon and see what events if any are generated.




Link to comment
Share on other sites

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...