Jump to content


Photo

Failed Certificate Login Attempts Being Passed to StoreFront After Firmware Upgrade from 10.5 to 11.1?

Started by Joshua Bilsky , 17 March 2017 - 09:57 PM
2 replies to this topic

Joshua Bilsky Members

Joshua Bilsky
  • 149 posts

Posted 17 March 2017 - 09:57 PM

I just upgraded my test VPX environment from NS10.5 61.11.nc to NS11.1 52.13.nc and noticed something strange with smart card (certificate) authentication.

 

On 10.5, if I were to attempt to use an incorrect client certificate to login to the VIP, I would get a generic Netscaler SSL certificate extraction error.  Likewise if I were to login to the VIP using a certificate of an account that was locked out in AD, I would be presented with a generic Netscaler error "You are not allowed to login. Please contact your help desk or system administrator."  In either scenario, the Netscaler terminates the connection attempt at the VIP and nothing is passed to the StoreFront.

 

When I attempt those same scenarios on 11.1, instead of the generic Netscaler white screen error messages, I get passed through to the StoreFront and am presented with a Cannot Complete Your Request error.  Why is this the case and is there something I can do to make 11.1 behave like 10.5 did in regard to certificate authentication?

 

This VIP has Client Certificate Mandatory and has a cert policy configured for primary authentication and an ldap policy configured for secondary authentication.  No changes were made to the configuration after the firmware was upgraded from NS10.5 61.11.nc to NS11.1 52.13.nc.

 

This is what I see in aaad.debug when I attempt to use a digital signature certificate for client authentication.  I get presented with a cannot complete your request error from StoreFront instead of an error from Netscaler.

 

 /home/build/rs_111_52_5_RTM/usr.src/netscaler/aaad/ldap_drv.c[379]: receive_ldap_user_search_event Binding user... 0 entries
Fri Mar 17 17:52:03 2017
 /home/build/rs_111_52_5_RTM/usr.src/netscaler/aaad/ldap_drv.c[384]: receive_ldap_user_search_event ldap_first_entry returned null, user not found
Fri Mar 17 17:52:03 2017
 /home/build/rs_111_52_5_RTM/usr.src/netscaler/aaad/naaad.c[2655]: send_reject_with_code Not trying cascade again
Fri Mar 17 17:52:03 2017
 /home/build/rs_111_52_5_RTM/usr.src/netscaler/aaad/naaad.c[2657]: send_reject_with_code sending reject to kernel for : Anonymous
Fri Mar 17 17:52:03 2017
 /home/build/rs_111_52_5_RTM/usr.src/netscaler/aaad/naaad.c[2661]: send_reject_with_code Rejecting with error code 4009

 

Any insight on this issue would be greatly appreciated.

 

Thanks

Josh

 

 



Joshua Bilsky Members

Joshua Bilsky
  • 149 posts

Posted 20 March 2017 - 06:01 PM

So if I require LDAP authentication on the secondary auth policy, the 4009 anonymous error goes away and I see nothing in the aaad.debug log when I use a bogus certificate.  However the authentication attempt is still passed to the StoreFront.

 

Am I missing something obvious here as to why failed certificate logins are not being terminated at the Netscaler?  Client Authentication is mandatory.  I am prompted for my certificate, select it, and enter the PIN.  If I use my legit smart card logon cert, I get presented with my apps in StoreFront as I would expect.  If I use my digitial signing cert which should fail extraction due to incorrect key usage type, I still get passed to StoreFront and presented with cannot complete your request. 

 

I have no idea what would have changed in 11.1 to change this behavior.



Joshua Bilsky Members

Joshua Bilsky
  • 149 posts

Posted 20 March 2017 - 09:23 PM

As another test, I just downgraded my VPX from 11.1 to the latest version of 11.0 (NS11.0 70.12.nc) and while the aaad.debug still shows error 4009 being returned when I use a bogus certificate, the traffic does not get passed to the StoreFront server.  When I attempt to login with a bogus certificate on 11.0, I get the familiar Netscaler white screen error "You are not allowed to login. Please contact your administrator." which is what I would expect since no valid user was returned from the LDAP query.  There are no errors in the SF logs in this scenario because no passthrough authentication was attempted. 

 

So it appears that only 11.1 has this issue as 11.0 and 10.5 stop authentication attempts from being passed to SF if they fail the LDAP lookup.