cugcblogs

Citrix NetScaler, Federated Authentication and Google – Pre Requisites

by Dave Brett, CTP

OK, so let’s get into the detail of how to build your XenDesktop, Google, Federated Authentication and NetScaler Deployment.

In my previous post, I outlined what we are trying to achieve with this and posted a couple of teaser videos about how the solution should operate once complete. If you have not read that already then please do so here:

This will give you a good understanding about what we are building and this in my opinion is crucial before you even start to look at the more details build.

This post will cover the Pre Requisites that you will need in place in order to get your solution working.  There are 2 sections within this post:

Google Required Pre Requisites

These are required in order to get your federated authentication working correctly.  You will have to have these all set up before continuing with the rest of this blog series.

Nice to Have Pre Requisites

These are additional things that I would put in place before publishing this solution to production.  They are not strictly required to get the federated authentication to work but will make your solution highly available and more scalable in the long run.  I am a great believer of building things right from the ground up – it will have you loads of time having to go back and introduce high availability at a later date!

Assumptions

  • URL: citrix.chromesummit.com – Used for regular NetScaler Gateway Access
  • URL: login.chromesummit.com – Used for Federated Authentication NetScaler Gateway Access
  • External IP: You will only have a SINGLE external IP
  • Internal Range: 192.168.0.0/24 (For the rest of this blog I will use the 192.168.0.0/24 subnet as a working example)

Google Required Pre Requisites

External DNS

Assuming your external IP Address is 1.2.3.4 (I know this is not real!) then you will need to point BOTH citrix.chromesummit.com and login.chromesummit.com to that IP Address.  Once done test by pinging both DNS names and ensure they resolve to the SAME IP address.  Please be aware that DNS replication can sometimes take a while so make sure you wait for this to happen before concluding that it’s not worked.

Lab Tip: If (like me) you don’t have a static IP address at home and you want to put this into your home lab then check if your router supports dynamic DNS.  Register an account and set your router to automatically update the dynamic DNS record with your current external IP address.  Then when creating the dns records for external access rather than creating an A Record create a CNAME and point it to the Dynamic DNS record registered with your router.  This way if your external IP address at home changes your external DNS names will still work as expected.

Network Address Translation

You will need to ensure that your external IP address forwards to an address in your DMZ.  So, at this point reserve a free address in your DMZ (For this we will use 192.168.0.50) and NAT all incoming traffic from the external IP address to your DMZ IP address.

e.g. – NAT: 1.2.3.4 à 192.168.0.50

Lab Tip: If you are building this in your own home lab you will more than likely not need to set up the NAT rules.  Instead when defining the firewall rules on your home router you can set a destination IP address on your internal network for this.  This will be the 192.168.0.50 address

Firewall Rules

These will greatly differ from firewall to firewall so the below setup guidelines will work but you may have to speak to your firewall or networking teams to get these rules set up.

Essentially you will need to allow all traffic hitting your firewall with the destination IP 192.168.0.50 on ports 80 and 443 through.  This will mean that from the outside world you can type citrix.chromesummit.com or login.chromesummit.com into a browser and it will end ip hitting your IP address reserved for this solution.

You may ask why forward port 80 as well as 443.  Most users will not want to type in https:// then the domain name.  By forwarding port 80 we can pick up this on the NetScaler with a content switch and automatically forward them to the secure connection.  This will enhance the user experience and also secure your deployment.

Domain Name UPN Suffix

If you consider a Google account, they can be pretty much anything they want with regards to the domain name.  For this example I have a Google account dbretty@chromesummit.com that I want to allow to log into the NetScaler Gateway using FAS.

The issue will be when passing authentication back to the domain my user account will not be allowed to log in as @chromsummit.com is not recognized as a valid UPN Suffix in the lab60.silvertonhcl.com domain.

To get around this we need to manually add the Domain UPN Suffix for the Google Domains we want to allow for login (in this case @chromesummit.com)

Log into a Domain Controller and open up Active Directory Domains and Trusts from Administrative Tools.

Right click on the Active Directory Domains and Trusts node and select Properties.

Then add the Domain UPN Suffix you want to allow for login.

Certification Authority

Make sure you have a Certification Authority in your domain.  Citrix Federated Authentication Services will require this to work and function and like I said earlier it’s better to have all this set up and ready prior to flipping back and forth during your Citrix FAS installation

Domain

This is obvious but for the sake of being thorough I had to put it in – :o)

You will obviously need a Windows Domain for this to even start to work!

StoreFront

You will need a StoreFront Server up and running on at least version 3.6.  This should be configured to allow access to your apps and desktops internally and that has been tested as working.

XenDesktop

This is also an obvious one but you will need a functioning XenDesktop Site of at least version 7.9 with either Apps or Desktops published ready for the users to consume.

NetScaler Gateway / Unified Gateway

You will have to have a NetScaler Gateway or Citrix Unified Gateway up and running before you start to build out the rest of this configuration.

There are some finer points here though so be sure to read and understand this before you continue.

NOTE: BOTH NetScaler Gateway and Unified Gateway can be built initially using the Wizards on the NetScaler.  BUT – be sure to read the rest of this section before running the wizard.  The wizard will get you a base gateway up and running and it will do it quickly – we will be changing some of the settings and adding to the gateway in the later post Configuring NetScaler.

Things you will need before running the wizard

  • Certificate: You will need a public signed certificate.  BE SURE that this certificate can sign both citrix.chromesummit.com and login.chromesummit.com as we will be hitting the same entry point for both URL’s.  You can use a wildcard or SAN certificate for this.
  • StoreFront Details: You will need the details of your StoreFront URL and the web store URL
  • Domain: You need your LDAP credentials that you want to use for your LDAP authentication policy as well as details of the domain controller you want to use for authentication
  • Ticketing: You will need to domain name of at least 1 Secure Ticketing Authority

The Key Point

If you are deploying a NetScaler Gateway only then you can assign ANY DMZ IP address you want to the gateway as we will have to manually build the Content Switch that will handle inbound traffic to go in front of this.  However, if you are building a Citrix Unified Gateway then you have to assign the Unified Gateway IP address to the DMZ IP address you reserved earlier (192.168.0.50) as the wizard will create the Content Switch on this IP address and this in turn will handle all inbound SSL traffic.

For this example, I will build a Citrix Unified Gateway using the wizard and assign the IP address we have reserved in our DMZ.

Once the wizard has been run you should see a Content Switch on your NetScaler (found under Traffic Management – Content Switching – Virtual Servers) and this will have the IP address you reserved earlier

You should also see a non-addressable NetScaler Gateway (found under NetScaler Gateway – Virtual Servers) showing as up and ready to receive connections.

At this point (assuming you have all your pre-requisites in place) you should be able to type in https://citrix.chromesummit.com into a browser and at least see a login page for Unified Gateway.  Don’t try to log in at this point as not a lot will work!

That’s it for the required pre-requisites, but as I said earlier there are some other things that I would recommend having in place before carrying on.  I must state that these are NOT required to get this configuration to work however would be recommended in any production environment.

Nice to Have Pre Requisites

Not wishing to reinvent the wheel on these there are a lot of excellent blog articles out there that will walk you through building most of these.  I will list the things that I think you should have in place and link to the relevant article to get you started and help you along the way!

StoreFront Load Balancer

I would set up at least 2 StoreFront server in a server group and put them behind a Citrix NetScaler Load Balancer.  Then point the DNS name for StoreFront to the load balanced VIP instead of an individual StoreFront Server.  This will increase capacity and resilience.

Carl Stalhood has written a great article on how to set this up and it can be found here:

http://www.carlstalhood.com/storefront-load-balancing-netscaler-11-1/

LDAP Load Balancer

Configure a NetScaler Load Balancer to front the connectivity to 2 or more Domain Controllers in your domain.  This will again enhance high availability and allow you to use a single IP address of the Load Balanced VIP to access more than one Domain Controller

Nicolas Ignoto has documented this and you can find it here:

http://www.citrixguru.com/2016/01/04/lab-part-18-secure-ldap-ldaps-load-balancing-with-citrix-netscaler-11/

Ticketing and Brokering Load Balancers

I normally create a SSL Load Balancer for the both Secure Ticketing and XenDesktop Brokering.  I know that this is not strictly required as the consoles will allow you to enter more than one STA and Broker.  However, I find that managing a single domain name for ticketing and a single domain name for a XenDesktop Site Brokering works well.

If you do need to scale out the brokering or ticketing function you can just add another node to the NetScaler Load Balancer and boom, it’s done – this prevents you needing to add the individual servers into the StoreFront site and also the STA on the NetScaler Unified Gateway.

HTTP to HTTPS Redirects

If you are running a StoreFront vServer then I would put this in to ensure that all connections are secure.  If a user tries to hit the vServer on port 80 you should automatically forward them to port 443.

I personally use a Responder policy for this and I will show you how to create them in the later post NetScaler Config.

That’s it for this post.  Next we will move onto setting up the Citrix Federated Authentication Service and getting into the meat of this Google and FAS implementation.

Thanks,
Dave Brett (@dbretty)

Leave a Reply