Using NetScaler Gateway securely, without a password.
Wouldn’t be nice if you could login to NetScaler Gateway without using your AD password? That’s what I do, and it’s arguably much more secure.
Today I’m rebuilding my test lab and thought I’d share details of how my own system is configured.
How does most multi-factor authentication work?
Multi-factor authentication with NetScaler Gateway is great because it solves the basic issue that if someone gets hold of your password, they can remotely login as you. It solves this issue by moving from entering a username and password to entering a username, password, possibly a PIN, and then a one-time passcode from a physical or software token.
It’s a little more work for the user but shoulder surfers and keylogging Internet cafes in Timbuktu (which are often cited as examples of how someone can get a user’s password) won’t be able to login because they don’t have access to the token or perhaps the mobile phone displaying that one-time passcode.
What’s the problem with standard multi-factor authentication?
While its true the evil internet café operator can’t login via NSG (he doesn’t have the second authentication factor), an awful lot of enterprise customers I work with have other platforms without multi-factor deployed, and these all can be used with the AD credential he logged.
Outlook Web Access pretty much never has multi-factor configured for remote laptop users, many firms have some old VPN platform, and off hand I can think of five to ten large enterprise firms who are migrating to cloud based services with no multi-factor on the “cloud” element. All of these, our would be attacker can login to.
Additionally, it’s fairly unlikely the Internet café owner installed the key-logger himself and even more unlikely he installed it knowing your user was coming, the intent will have been to collect a large number of passwords across a range of companies with staff working in the area, and likely to sell this information on.
With this in mind it’s entirely possible those compromised accounts could be used elsewhere as part of another attack or by someone who already has internal access. Compromised AD accounts are bad, even if NSG is secure.
How do we remove the AD password requirement for remote logins?
“RADIUS password return”, also known as “RADIUS password vaulting”, works by having the RADIUS server cache the AD password and return it to NetScaler at login time. This completely removes the need for the user to type their password (until it expires).
The first time the user logs in they will be prompted to enter their username, PIN, and one-time passcode. After this initial authentication step successfully completes, the RADIUS server will issue a challenge for the AD password and the NetScaler will display a screen for the user to enter it, the password is then cached by the server and provided to NetScaler at every subsequent login.
NetScaler has supported this functionality since version 9.x
SMS2 has supported this for well over a year but the feature is difficult to enable without a recent release.
How do we configure NetScaler for RADIUS password return?
The NetScaler configuration is surprisingly easy.
You should create a RADIUS authentication policy and bind it to the NetScaler Gateway vServer as type “Primary”. No other policies are required, unless you want to perform LDAP group extraction (in which case you need another policy for this).
The RADIUS policy is completely standard, on my system it has an expression of “ns_true” and binds to a server configuration that points of local RADIUS load balancer.
The server configuration is also completely standard (server, port, time-out, secret key), with the exception that it has two additional attributes configured. The “Password Vendor Identifier” is set to “46122” and “Password Attribute Type” is set to “5”.
The “Password Vendor Identifier” is a “Private Enterprise Number” assigned for SMS2 by IANA, this will change if you use different multi-factor authentication software.
The “Password Attribute Type” is the RADIUS attribute in which NetScaler should expect to receive the AD password.
Once these two values are set, NetScaler will use the password returned by RADIUS when connecting to StoreFront, and the configuration will continue exactly as if an LDAP policy was used.
What does it look like for the user?
The user sees two login boxes only, just like they’d see without multi-factor authentication. The first login box requests their username and another their PIN + OTP. Obviously your logon screen will be in English unless you’ve modified it.
Note that if you’ve enabled “challenge authentication” in SMS2 the initial login boxes will be for username and PIN, the challenge and a box to enter the OTP will be displayed on a second page immediately after clicking “Log on”.
From this point the user will see StoreFront as usual.
As you can see, the login process with RADIUS password return is actually easier for the user as well as more secure for you. There are of course still two factors, the PIN being something the user knows, and the OTP demonstrating possession of the token.
Is there any SMS2 configuration involved?
Provided that you’re running a recent SMS2 release (my lab is currently running 15110601a), enabling password vaulting is four clicks.
Select “Authentication Options” within the Administration Console.
Within “Engine Options” click “Password Vault”, then click “Save”.
Password vaulting is now enabled.