Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Instant Citrix Security How-to

You're reading from   Instant Citrix Security How-to A guide to bulletproofing your enterprise environment with the excellent security features in Citrix

Arrow left icon
Product type Paperback
Published in Feb 2013
Publisher Packt
ISBN-13 9781849686723
Length 74 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Carmel Jacob Carmel Jacob
Author Profile Icon Carmel Jacob
Carmel Jacob
Arrow right icon
View More author details
Toc

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:

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at AU $24.99/month. Cancel anytime