Edit September 10th, 2015: Be aware of one thing if you plan to use the native Citrix Receiver to access applications: The workaround described in this article will break authentication for native Receiver. If you need both LDAP and RADIUS authentication, it might be better to remove the checkmark for “Authentication” in the LDAP profile. This makes the Password field disappear, but you can still use LDAP for password change and group extraction.
When configuring user authentication for Netscaler Gateway or other services on Netscaler, I usually rely on only one type of authentication at a time. Since most New customers want’s to use two-factor authentication with SMS One TIme Passcodes (OTP), this mostly means that I configure a RADIUS authentication policy, using SMS Passcode. The challenge rises when they want to be able to change passwords via Netscaler and Storefront, either because it’s required, or that they simply want to. So far I haven’t been able to figure out how to facilitate this via RADIUS, so the only option is to do this via LDAPS (http://support.citrix.com/article/CTX122972, Acccess Gateway 9.2 or later for version 10.x). The caveat with this approach, is that it adds a second password field on the user login page. This is quite alright when you use old-fashion RSA or other two-factor authentication methords that relies on user-held tokens that gives out OTPs, because then the user enters both the password and the OTP at the same time when logging on. SMS Passcode and other SMS-based solutions usually doesn’t send this code until after the user has entered his/her username and passord, rendering the second password Field unusable…and confusing. The solutions that I have seen so far, has involved changing the original source files on the netscaler, like logins.js, to hardcode only one password field regardless of the configuration. I’ve never really liked this approach, because it happens behind the scene, and can be a complication when it comes to upgrading the Netscaler later on. Not my favourite thing… So, I decided to find a better way! I had been looking in to using rewrite and responder for a while to fix fhis, but only came as far as getting to change the text label of the password field. Not quit what I needed. Then I spent som time examining the code in login.js (/netscaler/ns_gui/vpn/login.js), and I realized that they use a cookie to check the number of authentication Methods, one or two. The cookie is named pwcount. The contents, or rather value, of this cookie is assigned to the variable pwc. The this variable is checked, and if the value equals 2, the second password field is visible. My simple solution: create a rewrite policy the overrides the pwcount cookie value, and always sets it to 1. Then this policy is bound to a vserver (or virtual Access Gateway) or globally on the Netscaler.
The rewrite is set up as follows: Create a Rewrite Action, set the type to INSERT_HTTP_HEADER. Header Name is Set-Cookie. The Expression is “pwcount=” + 1 (this sets the value of the pwcounts cookie).
The policy is as follows: Action is Rewrite_PwCount (the one made above). Log Action is not set, Undefined-Result Action is set to – Global-undefined-result-action-. Expression: HTTP.REQ.HEADER(“Cookie”).CONTAINS(“pwcount”).NOT
Bind this as a Rewrite policy on the vserver. NB: On Netscaler 10.x (and maybe older), note that it should be bound as a Responder policy. The change will be effective immediately. If you need to troubleshoot this, I recommend using Firefox and the Firebug addon. That gives you easy access to cookies contents, and also allows you to add cookies or change contents at will to debug and test stuff like this. I have testet this method on Netscaler 10.1 and 10.5. It should work fine on 9.x as well. The thing to look for here, is the cookie reference in login.js. As long as you can change the value of that, you should be fine.