Netscaler ADC. Web publishing with AD authentication. How it looks

Web publishing with Netscale ADC

The web publishing is consist by the next subsystems:
1. Content Switching;
2. AAA (Authentication, Authorization, and Auditing);
3. Load Balancing;
4. AppFirewall.

Users connects to the system from the Internet.
In my case I used AD as auth store and user authentication occurs using the user name in the next format “SamAccountName” and “UserPrincipalName”

The following functional server roles are also used:
1. NTP (time sync)
2. DNS (name resolving)
3. AD (authentication store servers)

Content switching.

The Citrix NetScaler Content Switching module allows you to accept user connections to a single CS virtual server and then distribute
traffic between different LB virtual servers depending on the contents of the packets. If we consider the traffic “http”, it is convenient to analyze the header “http” and distribute the traffic depending on the values of the header attributes.

more about contents switching by the link or in the next posts.


AAA (Authentication, Authorization, and Auditing).

Authentication should be devided on areas:
When user connect to Netscaler “User -> NS” area and when Netscaler authenticates by the user on servers “NS -> Server” area.
In my case I used FBA and Basic in the “user-ns” area and fba, basic, kerberos on “ns-server” side. AAA will seen in the next time.
For example how it works with FBA-Kerberos scheme:


1.    The client makes a GET request to the LB vServer (в нашей случае подключение происходит к виртуальному серверу CS и затем запрос передается виртуальному серверу LB).
2.    The LB vServer is configured with Form-based authentication. It therefore sends a 302 redirect to tell the client to go to the AAA vServer FQDN (в нашем случае
3.    The client contacts the AAA vServer FQDN, which is configured with an LDAP policy. The client enters their username and password in the fields provided. This is submitted as a POST request to the AAA vServer.
4.    The NetScaler contacts the AD to validate the users credentials.
5.    The AD replies with a bind response success if the credentials are valid.
6.    The AAA vServer sends a 302 response to the client redirecting them back to the LB vServer FQDN along with an authentication cookie.
7.    The client sends another GET request to the LB vServer along with the cookie. The LB vServer contacts the AAA vServer to validate the cookie.
8.    The NetScaler sends a GET request to the web server which is configured with Negotiate authentication.
9.    The web server returns a 401 Unauthorized and offers Negotiate or NTLM authentication.
10.    At this point the NetScaler authenticates to the KDC, impersonating the client by sending their username and password that they submitted at login. This is when the SSO Session policy is used which is configured with a ‘dummy’ KCD account that does not have a delegated user.
11.    The NetScaler makes two ticket requests, impersonating the client; one for the http service on the web server and the other for the realm.
12.    When the NetScaler receives the ticket, it makes another GET request and sends the ticket to the web server.
13.    The web server replies with a 200 OK and this is sent back to the client, allowing them to access the web server.

more about AAA by the link or in the next posts 

Load Balancing.

The balancing subsystem performs the following tasks:
1. Receive user requests from the Content Switching component.
2. Provides user authentication by redirecting users to the corresponding AAA virtual server.
3. Forwards the user request after successful authentication to the corresponding LB service.
4. Provides intelligent balancing of connections to domain controllers.
more about loadbalancing by the link or in the next posts:


Citrix NetScaler AppFirewall provides application protection at the L7 level of the OSI model.
Citrix NetScaler AppFirewall can provide both a positive, negative, and hybrid security model.
A negative model is described by the principle “What is not forbidden is allowed”,
usually it is a set of security policies and signatures that contain descriptions of known attacks.
The positive model is described by the principle “What is not allowed is forbidden”.
The positive security model is based on URLs, parameters and methods.
Evaluating each of the security models, we can conclude that using only one of these models has significant drawbacks:
for a negative model it is a low level of security, for a positive one – possible problems with the availability of a web resource.
But the combination of both models, i.e. hybrid model allows to obtain an acceptable level of both security and resource availability.
more about appfirewall by the link or int the next posts:

Leave a Reply

Your email address will not be published. Required fields are marked *