NetScaler Gateway, StoreFront and XenDesktop Integration Communication Workflow

Topics

1. Introduction

2. Detailed Workflow

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.

Back to top

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.

User-added image

a. Client_Hello

Client_Hello is the first packet of the TLS handshake, we can check the following items in it:

i. SNI

ii. Cipher Suits

iii. Protocol

User-added image

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.

User-added image

c. Certificate

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

User-added image

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.

User-added image

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.

User-added image

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

User-added image

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

User-added image

User-added image

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.

User-added image

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

User-added image

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

User-added image

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

User-added image

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

User-added image

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

User-added image

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.

User-added image

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.

User-added image

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

User-added image

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.

User-added image

e.4. SF returns 200 OK to NSG.

User-added image

f. NSG returns the same 200 OK to client.

Back to top

2.3. Get the App/Desktop List.

User-added image

a. Client sends the list request to NSG.

User-added image
b. NSG forwards this request to SF.

User-added image

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.

User-added image

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.

User-added image

e. DDC responses the available Apps list to SF.

User-added image

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

User-added image

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

User-added image

Back to top

2.4. Get the ica file.

User-added image

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

User-added image

b. NSG forwards this request to SF.

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

User-added image

d. DDC responses SF.

User-added image

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

User-added image

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

User-added image

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

User-added image

5. Client launch app/desktop

User-added image

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.

User-added image

b. NSG verifies the STA ticket with STA server.

User-added image

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

User-added image

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

User-added image

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

Back to top

Related:

Leave a Reply