An old topic resurfaced last week. It pertained to updating legacy applications by using NetScaler services rather than changing the application code.

No New Trick for This Old Dog

The customer was telling me that they wanted to publish an application only to pre-authorized users. The only problem was that this legacy application was written for internal consumption only, and, as such, had no authentication logic. There was also no SSLVPN in place. So we talked about the ability of NetScaler to superimpose authentication logic to any virtual server defined in the configuration.

Thus began the discussion. The summary of the configuration and its associated functionality is the subject of today’s BLOG. I felt it was worthy of a BLOG, because I was asked to explain it and – as is typically the case – some considerations apply.

In the Beginning…

For the example in this BLOG I chose to use the BadStore application. One of the basic application vulnerabilities on this site exists in the Guestbook Commenting section. So this seemed to be a good place to impose login requirements, but only this part of the application.

Is this a contrived example? Absolutely. But it illustrates the process well.

The Application Environment

A bit of background follows.

  • The actual BadStore application is cgi script driven. The whole site is basically one URL. The assignment of the appropriate values to the action parameter drives all the application the logic. If the value guestbook is assigned, the guestbook routines are invoked. This is exactly where I wanted to superimpose login. There was no login page here in the native application, however.
  • The BadStore application runs on the server accessed as shop.Mega-Co.com and I wanted it to interact with my Active Directory server for user login processing.
  • My Active Directory runs on the system DC.Mega-co.com in my examples.

NetScaler Gets It Under Control

I am using the NetScaler AAA functionality to superimpose the login process. To get this going, the three basic AAA components that I will configure in the NetScaler consist of the following:

  1. The AAA Virtual server
  2. Connectivity to the Active Directory through NetScaler AAA Authentication Policy and Server definitions
  3. Configuring the “Authentication” parameters within the NetScaler Load Balancing Virtual Server definitions

The actual configuration activities can be configured individually though the Command Line Interface (CLI) or the Graphical User Interface (GUI). Alternatively – as I did – they can be defined though the “AAA – Application Traffic Wizard“.

In any case, this BLOG does not contain a complete step by step runbook, but simply a summary of the configuration highlights as shown below.

This first screenshot shows the creation of the Authentication Server within the NetScaler configuration. This tells the NetScaler how to access my Domain Controller system using an LDAP connection. You will note that I resisted the urge to use the lab-typical Administrator user.



These parameters and the formats of their assigned values will be familiar to those of you that configure the Access Gateway functionality on the NetScaler.

The next image shows the creation of the NetScaler AAA Authentication Policy. In this menu I selected the Authentication Type (LDAP) and the Server name (ADServer) that I used in the previous step (above).


As the last step of defining AAA objects, I created a AAA Virtual Server (VServer) complete with its own unique IP address. As part of the AAA process, users will be redirected temporarily to this VServer. Therefore, this IP address have to be accessible by the user browser, and its FQDN must be DNS registered. The DNS registered name in this example is Ad.Mega-co.com.

In defining this entitiy, I associate or bind it to the AAA-Authentication object defined above.



Turn Me On

To enable authentication for a LoadBalancing VServer (LB VServer), a simple parameter is set. It basically tells the NetScaler that, in order to access this VServer, the user must have authenticated. If the user has not loged in, the user is directed to the AAA Vserver tp login. The authentication point specified matches the name of the AAA VServer entity defined in the previous step, above. This is set in the Advanced tab in the LB VServer object.


But Wait!

The above will cause the user to hit the application, and then be sent to a logon menu immediately. What we wanted to do was enforce authentication for only part of the site – the Guestbook application only.

Since the NetScaler AAA algorithms operate on the complete VServer, I had to split the sites. This is a perfect job for the ContentSwitch (CS) functions within the NetScaler.

The CS functionality lets me define one externally facing VIP (with an externally accessible IP address), and associate it with one or more internal LB VServers that have no externally accessible IP address. In effect, this allows me to forward requests to any of the bound LB VServers, depending unpon the content of the request.

Why is this important to my desired configuration?

I want all traffic except Guestbook traffic to be allowed direct access. I want to superimpose AAA only Guestbook access, remember?

So, I defined two internal LB VServers. One for Guestbook, and the other for all other traffic. And – as you surely suspect – it is the Guestbook LB VServer that gets the Authentication option activated.
Through a ContentSwitch policy, I use the contents of the request to determine to where the ContentSwitch send each request.

  • If the request contains action=Guestbook, send it to authentication land
  • Otherwise send it along without challenge

This is what it looks like in the NetScsaler configuration:




Enable – actually mandate – Authentication for the internal LB VServer (AAAShop.mega-co.com) that will handle the guestbook traffic. Note the lack of IP address in the graphic.

The other internal LB VServer in the NetScaler configuration (Shop.Mega-co.com) does not have authentication mandated.

Now I change the CS VServer settings in order to control the traffic – and thus – the authentication enforcement.



In the above image, note that the target – or destination LBVServer is set to AAAShop.mega-co.com if the user request contains “…action=guestbook”. If the user request does not match this criteria, then the lgic falls through to the default assignment of the Shop.mega-co.com LB VServer.

Note that it is only the ContentSwitch VServer that has the externally accessible IP address. Therefore all other requests come through here.

And the User Sees?

Accessing the site directly works as it did before.


But when the user clicks the link to the protected guestbook, a NetScaler resident login page is displayed. Notice the redirect to the Ad.Mega-co.com site. This is the Authentication VServer defined above. It exists entirely within the NetScaler, and communicates with the defined Active Directory server though an LDAP call.




Note that the above screensho shows that a real certificate would have been nice .

Assuming appropritate credentials, the user is then sent to the originally requested page.


To Summarize

Although this is a fictions case, the rationale for doing this should be clear. This methodology shows how the NetScaler can be used to add authentication servicds to existing applications that are not authentication aware.

I have talked to customers that have found this technology very useful in situations such as externalizing applications and such. So, the next time you have a need to override the behavior of an application, think about doing it in the front-end NetScaler.

As usual, you comments are welcome.

Follow me at Twitter

Or send me email