Deploy Storefront Using Natscaler Vpxall About Citrix
Citrix Receiver client software is installed on the user device (iPhone, Android phone, thin client) to allow users, by way of the NetScaler appliance delivering high availability, scale and security, to access their desktops, applications and data through Citrix StoreFront. Mar 09, 2017 Step-by-step instructions on configuring Citrix StoreFront to use the NetScaler Gateway for remote access to the XenApp/XenDesktop environment. Link to article, https://www.cloudedskies.co.uk.
- Deploy Storefront Using Netscaler Vpxall About Citrix Client
- Netscaler Vpx 200
- Deploy Storefront Using Netscaler Vpx All About Citrix Workspace
- Deploy Storefront Using Netscaler Vpx All About Citrix Connection
- Deploy Storefront Using Netscaler Vpx All About Citrix Client
- Citrix Netscaler Vpx Pricing
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
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
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
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.
Deploy Storefront Using Netscaler Vpxall About Citrix Client
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/
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.
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.
Netscaler Vpx 200
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.
2.4. Get the ica file.
a. Client sends the request to NSG to get the ica file.
Deploy Storefront Using Netscaler Vpx All About Citrix Workspace
b. NSG forwards this request to SF.
c. SF gets the VDA information from DDC. Such as IP, port info.
d. DDC responses SF.
Deploy Storefront Using Netscaler Vpx All About Citrix Connection
e. SF contacts STA server to get the STA ticket information.
f. SF generates ica file and sends it back to NSG.
Deploy Storefront Using Netscaler Vpx All About Citrix Client
g. NSG forwards the response to client. The content is the same as step f.
5. Client launch app/desktop
Citrix Netscaler Vpx Pricing
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.