Topics

1. Introduction

In this article, we will talk about NetScaler Gateway+StoreFront+XenDesktop workflow. I will separate the workflow into 5 steps.

1. SSL Connection
2. Authentication
3. Get the App/Desktop list.
4. Click one app and get the ica file.
5. Launch app/desktop.

2. Detailed Workflow

In this section, we will analyze the detailed workflow of the previous 5 steps. Here are my environment machines. 

Client: 10.107.197.250
NetScaler: VIP: 10.107.197.243
NSIP: 10.107.197.241
Subnet IP: 10.107.197.242
StoreFront: 10.107.197.236
DDC/STA: 10.107.197.235
VDA: 10.107.197.238

Back to top

2.1. SSL Connection

This is the first step when user type the NetScaler Gateway vServer’s address into browser. We need to focus on the SSL handshake between client and server if any issue happens.

Note: NSG means "NetScaler Gateway" in this article.

a. Client_Hello

b. Server Hello

Server hello is the response of client hello, used to negotiate the protocol version and cipher suite from client hello, these items are very important for subsequent encryption.

c. Certificate

Server sends its certificates to client, so that client can verify if the certificates are trusted or not.

d. Key Exchange & Change Cipher Spec

Most of SSL/TLS issues are happened in above 3 steps. The "Key Exchange" step is used to negotiate the master key and session key for the data encryption. And use "Change cipher Spec" step to enter the data encryption channel.

e. HTTPs data (encrypted HTTP requests and responses)

After handshake, client and server send HTTP requests and responses encrypted by the key negotiated in the SSL/TLS handshake.

How to decrypt these HTTP data at client side? Check this article: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

Back to top

2.2. Authentication

Commonly, customer uses LDAP domain authentication. In this article, I will use dual factor authentication as an example (LDAP+Radius).

LDAP: AD
Radius: freeradius

a. Client type the user credential and send to NSG vServer.

Note: Here I use the NSG’s private key to decrypt the HTTPs data.

b. NSG communicate with LDAP server and Radius server to verify the user’s credential.

b.1. bindRequest is sent to LDAP server to authorize NSG itself and LDAP server respond success. Here the user "administrator@donnie.com" is configured in NetScaler's LDAP policy.

b.2. searchRequest is sent to LDAP server to check the login user’s existence.

b.3. LDAP server responds the searchRequest by searchResEntry, searchResEntry contains some LDAP info such as the login user’s group information.

b.4. NSG sends a new bindRequest to LDAP server to verify the login user’s password.

b.5. NSG verifies the token information with Radius server and server responses Access-Accept.

c. NSG responses client with a normal 302 response and another 200 response to redirect the URL to StoreFront.

d. User click “Login” again in the StoreFront page. A new login request sent to SF. Here user doesn’t need to type his username/password again.

e. NSG communicates with SF to pass SF’s authentication.

e.1. NSG sends the request to SF and SF responds 401 to ask NSG to perform authentication.

e.2. NSG sends the user’s info to SF by using CitrixAGBasic authentication method.

Note: they are base64 encoded, wireshark can decode them automatically.

e.3. SF verifies the user’s username and password by contacting AD server with protocol Kerberos.

e.4. SF returns 200 OK to NSG.

f. NSG returns the same 200 OK to client.

Back to top

2.3. Get the App/Desktop List.

a. Client sends the list request to NSG.

b. NSG forwards this request to SF.

c. SF sends callback message to NSG to get the vServer/Policy information. This is very useful when enable SmartAccess. If SmartAccess is not enabled. The callback address doesn’t need to be configured in SF.

d. SF checks with DDC for the available Apps and Desktops related to this client. Note that the session policy information is here, it’s got from the previous callback request. So that DDC can use it’s Access Policy to determine the matched apps and desktops based on this.

e. DDC responses the available Apps list to SF.

f. SF converts the response into json format and sends it to NSG. Each object is for each app/desktop.

g. NSG sends this response to client. Note that the ica file URL is also in this response.

Back to top

2.4. Get the ica file.

a. Client sends the request to NSG to get the ica file.

b. NSG forwards this request to SF.

c. SF gets the VDA information from DDC. Such as IP, port info.

d. DDC responses SF.

e. SF contacts STA server to get the STA ticket information.

f. SF generates ica file and sends it back to NSG.

g. NSG forwards the response to client. The content is the same as step f.

5. Client launch app/desktop

a. Client sends ICA data to the same NetScaler vServer. This is not http protocol. Note that only Receiver 4.6 or above supports SNI.

b. NSG verifies the STA ticket with STA server.

c. STA server responses valid result and the VDA server’s info(IP+port).

d. NSG connects VDA’s 1494 port for the virtual desktop data.

e. NSG acts as a “proxy” between client and VDA.

Back to top