Project Silverton – Citrix XenDesktop, NetScaler, FAS and Google – Part 7

Project Silverton – Citrix XenDesktop, NetScaler, FAS and Google – Part 7

Project Silverton – Citrix XenDesktop, NetScaler, FAS and Google – Part 7

This post has already been read 2234 times!

We can now move onto Part 7 and the final part of this series, The Nice Bits

The previous parts in this series can be found by using the below links.

Part 1 – Summary of NetScaler, XenDesktop, FAS and Google

Part 2 – Pre-Reqs

Part 3 – Google oAuth Setup

Part 4 – Citrix Federated Authentication Services

Part 5 – NetScaler Configuration

Part 6 – StoreFront Configuration

The purpose of this last post if to streamline the user experience and make sure that everything works exactly as you want it to.  I will cover 2 additional NetScaler Configurations that I think are essential when deploying any publicly facing web service.

  • Security
  • HTTP to HTTPS redirection

Harden Your NetScaler Unified Gateway and Content Switch

The following steps will need to be taken on BOTH your non-addressable NetScaler Gateway vServer AND your SSL Content Switch

Disable SSL 3 and Create Diffie-Hellman Key

First create a Diffie-Hellman key by going to Traffic Management and SSL.  On the right you will see the option to create a Diffie-Hellman Key.  Click that and give the key a new file name on the NetScaler and set the DH Parameter Size to 2048

03-dh-key

Next open up your new NetScaler Gateway and edit the SSL Parameters for the gateway

Check to enable the DH Param, select your new key, set the refresh to 1000 and disable SSLv3

04-ssl-params

Certificates

 

Another thing is to ensure that your public certificate assigned to the gateway has the full chain presented on the NetScaler WITHOUT the Root CA.  Head over to Traffic Management – SSL – Certificates – Server Certificates

Right click on your public certificate and click on link

If you have uploaded your intermediary certificates to the NetScaler you can link them here.  Do this for all intermediate certificates but don’t link right back to the root

06-cert-linking

SSL Renegotiation

Open the Advanced SSL Settings from Traffic Management – SSL

Change the Deny SSL Renegotiation to NONSECURE

07-ssl-reneg

Cipher Suite

Assign the following Ciphers to the NetScaler Gateway and remove the Default Group

  • TLS1-ECDHE-RSA-AES256-SHA
  • TLS1-ECDHE-RSA-AES128-SHA
  • TLS1-DHE-RSA-AES-256-CBC-SHA
  • TLS1-DHE-RSA-AES-128-CBC-SHA
  • TLS1-AES-256-CBC-SHA
  • TLS1-AES-128-CBC-SHA
  • SSL3-DES-CBC3-SHA

08-ssl-ciphers

Secure Transport Session Header

You will now create the Secure Transport Session header to be put into your NetScaler Gateway sessions to abide by SSL Labs best practice

Navigate to Rewrite Actions and create a new action

38-rewrite-action

Fill out the details as shown below

Then create a Rewrite Policy

40-rewrite-policy

and fill out as shown below binding it to your new Rewrite Action

Once you have created this bind it to your NetScaler Gateway

Thats it – test your Gateway from SSL Labs and you should not receive a pretty decent rating.

10-ssl-test-2

NOTE: This procedure can and should where applicable be followed on all SSL vServers that you create on the NetScaler even if it is for brokering XenDesktop, StoreFront or Ticketing.

HTTP to HTTPS Redirection

One of the most annoying things I come across is when people don’t redirect HTTP to HTTPS on any secure web platform.  Its such a basic thing that makes all the difference to the end user.  I want to be able to type in citrix.chromesummit.com instead of https://citrix.chromesummit.com!

There are LOADS of different ways to do this using a NetScaler but in this article I am going to use a Content Switch running on the SAME IP address as my SSL Content Switch and a Responder Policy to redirect ALL inbound port 80 traffic to the port 443 Content Switch that is configured to handle my entry point.  This is NOT always the best way to do this as sometimes you may want to allow port 80 inbound for some reason, in this case you would need to use Content Switching Policies and vServers to do the job.

Head over to App Expert – Responder – Actions and click to create a new action

Create an action with the following expression

"https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE

Make sure the response code is 302

Next head over to App Expert – Responder – Policies and click to create a new policy

Create a new Policy with the following

HTTP.REQ.IS_VALID

and bind it to the action you have just created

Next head over to Traffic Management – Content Switching – Virtual Servers and create a new Server.  Give it a name, THE SAME IP ADDRESS as your existing Content Switch for login.chromesummit.com and citrix.chromesummit.com and select the protocol HTTP and port 80

Open up the Virtual Server and bind your Responder Policy to it.

Thats it.  Your new Content Switch is now listening on port 80 and will throw everything that hits it to the SSL Content Switch on the same IP address.

The great thing about this is that you can re-use the Responder policy for any other vServers that you have created for example StoreFront.  Create a new vServer on port 80 – bind it to an always up service and attach the same responder policy.  Boom, all port 80 traffic for storefront will now hit port 443 automatically.

And that is a wrap.  I hope you enjoyed the blog series and it has provided a good step by step guide in configuring Citrix XenDesktop, NetScaler, Federated Authentication and Google Accounts.

On a side note – if you google oAuth providers and just look at the list that is available – just imagine what NetScaler, FAS and oAuth could do for you next.

Once again I want to that Rick Dehlinger for giving me the chance to help out with Project Silverton and I am sure that there will be loads of great community content coming soon from it.

Thanks,

Dave Brett (@dbretty)

Leave a Reply

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