Triple A (Must know)

The first thought that comes to mind when somebody says AAA? Batteries? Credit Ratings? No, it is the user authentication, authorization, and auditing feature, and it is all about having Netscaler/access gateway to manage access controls rather than an admin managing the access controls separately for each app. This recipe shows how NetScaler controls the access for the XenApp farms on your private network.

Getting ready

To configure AAA on NetScaler, you need to start by creating an SSL certificate-key pair and bind it to the AAA vserver (the certificate request and the key can be generated on NetScaler and submitted to the Certificate Authority, also knows as CA, to receive the cert-key pair). The AAA vserver should then be associated with any traffic-management vserver (load balancing [LB] or content switching [CS]). DNS needs to be configured to assign hostnames to both the AAA vserver and the traffic management vserver; please note that both the hostnames should be in the same domain, while creating the cert-key pair uses the appropriate domain in the subject name. (Self-signed certificates will not work for AAA, as they are used for testing purpose only.) The procedure of configuring a cert-key request and binding it to a vserver and the DNS configuration will be shown in detail in the following sections of this chapter.

The AAA functionality can be used for simple traffic management as well as for virtual private network (VPN) functionality!

How to do it...

Triple A comes across as an important feature of the Citrix Netscaler, as it can be used from a simple load balancing environment to VPN, coupled with a wide range of external authentication types. In this section, we shall see how to set up a AAA vserver from scratch that can be bound to a LB or Content Switching vserver:

1. Create a cert-key pair by configuring the certificate signing request on NetScaler. Go to SSL, click on Certificate Signing Request (CSR), and follow the instructions to generate a CSR. Similarly, you can create the RSA key. After generating the CSR and key, both need to be submitted to the CA, which in turn will produce the cert-key pair. The cert-key pair then needs to be loaded on the NetScaler box through SCP/FTP and so on.

2. Configure the AAA vserver and bind the cert-key pair to it. In the AAA vserver, the Authentication tab is where the external authentication profile and policy needs to be configured. We can use any flavor of LDAP or RADIUS. Further more, you can add a session policy to increase/decrease the timeouts and the Single sign-on (SSO) functionality to the web applications.

   Note

   With SSO, a user has to log in just once and he would have access to multiple different applications and systems. The user credentials will be internally stored and these credentials will be granted to the applications that request them.

   To add the SSO functionality, run the following commands:

   >add tm sessionAction <sso_act > -SSO ON -ssoCredential PRIMARY -ssoDomain aaa.test.com>add tm sessionPolicy <sson-act_pol> ns_true sson>bind authentication vserver AAA-vip -policy sson-pol -priority 1
   Done
   

3. The AAA vserver is then bound to the LB or CS server. The LB/CS vserver should be on HTTP and on the Advanced tab of the traffic management server. The authentication vserver needs to be bound and the domain name of the AAA vserver should be specified. The following screenshot shows the CLI output of the LB vserver after the configuration and binding of the the AAA vservers:

   

How it works...

A step-by-step working of the client to server authentication through Netscaler will be shown using HTTP headers (an HTTP header trace taken on the IE browser was used for the setup here):

1. The client sends an HTTP request to the LB vserver, the LB vserver sends a 302 redirect to the AAA vserver.

   In this case, we can see that www.a.abc.com and www.abc.com belong to the same domain name.

   The following code is the output of an HTTP header trace taken during the authentication phase (a simple HTTP header trace or a Mozilla header tool that can be downloaded for capturing the HTTP headers):

   GET / HTTP/1.1
   Host: a.abc.com
   User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   Accept-Language: en-gb,en;q=0.5
   Accept-Encoding: gzip, deflate
   Connection: keep-alive
   
   HTTP/1.1 200 OK
   Content-Length:681
   Cache-control: no-cache, no-store
   Pragma: no-cache
   Content-Type: text/html
   

2. The AAA vserver then sends a page to the client for getting the authentication credentials:

   HTTP Header trace:

   POST /cgi/tm HTTP/1.1
   Accept: image/jpeg,*/*
   Accept-Language: en-US
   User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; 
   Content-Type: application/x-www-form-urlencoded
   Accept-Encoding: gzip, deflate
   Host: abc.com
   Content-Length: 55
   Connection: Keep-Alive
   Cache-Control: no-cache
   Referer: 
   HTTP/1.1 302 Object Moved
   Location: /vpn/tmindex.html
   Set-Cookie: NSC_TASS=03110d1ceac81fd1f5317e3415d75c58;Secure;HttpOnly;Path=/
   Set-Cookie: NSC_TEMP=xyz;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 
   Set-Cookie: NSC_TEMP=xyz;Path=/;Domain=apac.lab;expires=Wednesday, 09-Nov
   Connection: close
   Content-Length: 536
   Cache-control: no-cache, no-store
   Pragma: no-cache
   Content-Type: text/html
   
   GET /vpn/tmindex.html HTTP/1.1
   Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
   Accept-Language: en-AU
   User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; 
   Cookie: NSC_TMAA=802662f5eb2a319f29b9af61086313f3; NSC_TMAS=b8e51a409ec3c39541378edb91e80d50; NSC_TASS=03110d1ceac81fd1f5317e3415d75c58
   Accept-Encoding: gzip, deflate
   Host: abc.com
   Connection: Keep-Alive
   Cache-Control: no-cache
   Referer: 
   
   HTTP/1.1 200 OK
   Date: Sat, 22 Sep 2012 08:39:45 GMT
   Server: Apache
   Last-Modified: Tue, 11 Sep 2012 22:48:07 GMT
   ETag: "40f8-16ae-4c974de21f7c0"
   Accept-Ranges: bytes
   Content-Length: 5806
   Keep-Alive: timeout=15, max=100
   Connection: Keep-Alive
   Content-Type: text/html
   Cache-Control: no-cache
   

After the authentication is successful, the client gets redirected back to the LB vserver. This time, the AAA sends a cookie to the client so that the subsequent requests from the client would contain the same cookie. NetScaler looks at the cookies and directs the request to the appropriate backend service (according to the LB method configured). At any point in time, the following screenshot shows the CLI command, which when entered will show the number of active users connected:

The following diagram is a pictorial representation of the authentication request between the LB and AAA vserver:

There's more...

This section will throw some light on debugging the external authentication issue.

Note

The ns-server certificate present on NetScaler is used only for secure management access of NetScaler. The management access can be restricted to HTTPS (secure) only, or both HTTP and HTTPS. Similarly, you can add either MIP or SNIP for a GUI secure access.

Tips and troubleshooting

There are a few common issues that could be listed for for AAA:

• The certificate has to be trusted; if you are connecting with a security exception, AAA will not work. Another important note would be to check for certificate expiry.

• The NSC_TMAA cookie should be preserved by the browser for successive transactions by the client in either the same or different browsers. This can be verified by taking an ethereal or wireshark capture on the client machine.

• When there are multiple applications that need to be accessed in the same session and each of them open a new connection, the client might face an issue of authenticating multiple times. The same holds true if the browser is not able to preserve the cookie. In such conditions, there is an option on NetScaler to enable persistent cookies. This setting is available globally or can be restricted to only certain traffic policies that are be bound to the AAA vserver.

The following is a CLI command to enable persistent cookie setting on NetScaler for AAA traffic:

>set tm sessionParameter -SSO ON -httpOnlyCookie NO -persistentCookie ENABLED -persistentCookieValidity 30 [GLOBAL SETTING]

The following is a CLI command to enable a debug for AAA(CLI):

>shell
#cd /tmp
#cat aaad.debug [This command would enable aaad debug,to stop its press Ctrl+Z]

The following screenshot shows the debug logs for a successful authentication: