Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Notes on DNS servers & NetScaler

I must begin with a link to this forum post where someone explains the various DNS types on a NetScaler. A must-read. 

Now on to a bunch of screenshots and notes from me as I was just looking around with NetScalers and DNS. I have realized over time that my way of picking up stuff is by just doing it. A typical approach of reading about something and then trying it out doesn’t seem to work for me. (a) I get sleepy during reading and (b) that results in me never getting to the trying out stage. Instead, I seem to work better by just trying to begin with, succeed or break stuff in the process, and then go back and read or blog etc. about it. No hubris here that I am one of a kind :) am sure there’s more people who work this way – just that I too am like them. 

A negative with this approach is that I must have a test lab where I can try things out. So there’s the additional effort required from me in terms of having a place where I can just break stuff. That’s probably the only negative thing I can think of about my approach. Oh, and it also takes up additional time when I want to pick up something – because first I have to set the environment up (e.g. when I was trying to pick up NSX last month) and then spend time just doing things and making/ breaking stuff in the process. 

Anyways – end of digression. Back to NetScalers and DNS. 

On a NetScaler, under the Traffic Management > DNS > NameServers is where you define DNS servers. 

 

You create names servers by clicking on the “Add” button. That gives a new screen like thus:

I’ll start off the with the “Local” checkbox because it’s a very important one. Funny how it’s just there as a checkbox but it completely changes everything else! 

If you tick “Local” what it means is that the NetScaler acts as a DNS server responding to queries from clients. 

  • Thus the IP address you specify will be a Virtual IP on the NetScaler, where you can query for DNS replies. 
  • The records you can query are what will be defined on the NetScaler, under the Records section. 
  • The NetScaler can only act as a UDP based nameserver.

If you don’t tick “Local” then the NetScaler acts as a client. It won’t respond to any DNS queries. 

  • Thus the IP address you specify are what the NetScaler will contact for its own DNS queries. 
    • From the forum post I linked to above: NetScaler will monitor this IP address via ping from the NSIP (and not the SNIP).
  • Note: These IP address do not belong to the NetScaler. 
  • The IP addresses + DNS port combo cannot be defined on the NetScaler in the Load Balancing > Services section. You’ll get a “Resource already exists” error in that case. 
  • The IP addresses + DNS port combo can be defined in Service Groups. And can thus be used in load balancing etc. But as pointed out above, they cannot be defined as services. 

When creating a name server it is possible to use an existing DNS virtual server if one is already defined. The caveat with this is that only UDP is allowed. It is not possible to add a TCP or UDP/ TCP entry. In fact, the only options one gets in the drop down menu are UDP only DNS load balancer virtual services. (From the forum post: in this case the NetScaler will monitor the virtual server from its SNIP). 

It’s good to have TCP (or UDP/ TCP) servers in case of larger responses. In fact, when the NetScaler is acting as a load balancer for other DNS servers (this mode is called DNS proxy) it’s pretty much recommended to have TCP as an option too. 

If, say, the NetScaler is defined with only a UDP based DNS server (as in the screenshot below) then queries will fail if the DNS responses are large and require a TCP connection. 

This brings me to one more point. If we are creating a virtual server DNS just for the NetScaler’s internal use, we don’t need to define an IP address for it. The Name Server I have above actually does not have any virtual IP on the NetScaler. 

So – to summarize: 

  • In the Name Servers section we can set the NetScaler to act as a DNS server for a zone it has.
    • This is UDP only. 
    • This is not load balancing. i.e. not a virtual server. 
  • In the Name Servers section we can also point the NetScaler to other DNS servers the NetScaler itself can use. 
    • If an IP address is specified, it can be both UDP and TCP, and the NetScaler monitors it via ping from the NSIP.
    • If a virtual server (see next point) is specified, it is UDP only, and the NetScaler monitors it via ping from the SNIP.
      • The virtual server created for such internal use can be set in non-addressable mode (i.e. not IP address).
  • In the Virtual Servers section it is possible to define a DNS service. The NetScaler will then act as a DNS server. 
    • This is load balancing. The NetScaler doesn’t host any zones. 
    • The NetScaler will cache results though and serve from those if required.
    • The NetScaler does not use this internally. But it can be set to use this internally, if thus defined in the Name Servers section.
    • This is for both UDP and TCP. 
    • This is also known as a DNS proxy. 

I think that’s about the gist of it. I have skipped GSLB for now. Once again, pointing to the useful forum post. It’s a great one! 

Refresher to myself StoreFront and Delivery Controller authentication

In a previous post I had written about the flow of communication between Citrix Storefront and Delivery Controllers during user authentication. Here’s some more based on a Citrix blog post I am reading. 

Here’s what I had written in my previous post:

There’s a couple of steps that happens when a user logs in to access a Citrix solution. First: the StoreFront authenticates the user against AD. Or if the user is accessing remotely, the NetScaler gateway authenticates the user and passes on details to the StoreFront. Then the StoreFront passes on this information to the Delivery Controller so the latter can give a list of resources the user has access to. The Delivery Controllers in turn authenticate the user AD. The Delivery Controller then sends a list of resources the user has access to, to the StoreFront, which sends this on to the user’s Citrix Receiver or Browser. This is when the user sees what is available to them, and can select what they want.

When the user selects what they want, this is information is passed on to the StoreFront, which then passes the info to the Delivery Controller – who then finds an appropriate host that can fulfill the requirement and sends this information to the StoreFront. 

Emphasis mine. The Storefront communicates with the Delivery Controller using the XML Service. 

Here’s a list of authentication methods supported by the Storefront. 

When the Storefront communicates the user authentication information to the Delivery Controller, it may or may not include the password too (sent in clear-text) in this communication. If “User name and password” or “Pass-through from NetScaler” is selected, then the password is included. If “Domain pass-through” or “Smart card” is selected, then the password is not. The blog post doesn’t say anything about these, but I think “SAML Authentication” (used for ADFS) will not include the password, while “HTTP Basic” will. 

The StoreFront and Delivery Controller communicates twice (the two times I emphasized above). The first time is when the user authenticates and the StoreFront sends this information to the Delivery Controller to get a list of resources. The second time is when the user makes a selection and this information is passed on to the Delivery Controller so that an appropriate host can be selected. In both instances the password could be sent from the StoreFront to the Delivery Controller.

Brief notes on the Citrix STA

Wanted to point out this PDF from Citrix on the XenApp/ XenDesktop architecture – especially pages 21, 22 which are on how authentication works. During my Citrix course the instructor had talked about it but like an idiot I didn’t take notes and now I can’t find much info on what he was explaining. 

The part which is of interest to me is the STA (Secure Ticket Authority). 

There’s a couple of steps that happens when a user logs in to access a Citrix solution. First: the StoreFront authenticates the user against AD. Or if the user is accessing remotely, the NetScaler gateway authenticates the user and passes on details to the StoreFront. Then the StoreFront passes on this information to the Delivery Controller so the latter can give a list of resources the user has access to. The Delivery Controllers in turn authenticate the user AD. The Delivery Controller then sends a list of resources the user has access to, to the StoreFront, which sends this on to the user’s Citrix Receiver or Browser. This is when the user sees what is available to them, and can select what they want.

When the user selects what they want, this is information is passed on to the StoreFront, which then passes the info to the Delivery Controller – who then finds an appropriate host that can fulfill the requirement and sends this information to the StoreFront. 

The next step is where the STA comes in. 

In case the user is accessing Citrix locally, the StoreFront can create an ICA file with details of the host and send it over to the user’s Citrix Receiver or Browser and the latter can then directly talk to the VDA agent installed on the host (note the StoreFront & Delivery Controller have no more role to play). But what if the user is accessing remotely? We don’t want to send these sensitive details over the public Internet. So, as a workaround, Citrix creates a “ticket” (which is a randomly generated sequence of 32 uppercase alphabetic or numeric characters) and associates the ticket with the details of the host that the Citrix Receiver or Browser need to contact to access the requested resources. This ticket is what is sent over to Citrix Receiver or Browser in the ICA file, using which it can contact the NetScaler gateway and the NetScaler gateway can validate this and initiate a connection with the VDA on the host on behalf of the user. 

So, as we can see the STA only comes into play in case of remote access. The STA is a part of the Citrix XML Service (once again linking to this excellent post!), which is installed as part of the Delivery Controller (so the STA is a part of the Delivery Controller). It is written as an ISAPI extension (called CtxSta.dll) for the IIS WebServer and runs the /Scripts/CtxSta.dll URL. The STA has an ID called the STA_ID, and this along with the TICKET and an STA_VERSION field are what is put into the ICA file. I am not sure whether the STA requires IIS, or it can run standalone (as I blogged previously the Citrix XML Service can run standalone so I would assume the STA can do the same). The Citrix STA FAQ says IIS is required, but that could be outdated.

The Citrix StoreFront is configured with the STA details in the NetScaler Gateway section (remember you only need to use the STA in case of remote users, for which you would have to configure a NetScaler Gateway). 

Similarly the NetScaler itself is configured with the STA details. 

It is important to keep in mind that there are thus TWO places where the STA details are input, and that the details in both places must be the same. The StoreFront uses its configured details to generate a ticket and put it in the ICA file. And the StoreFront uses its configured details to validate that ticket with an STA and identify what resources it should connect to. If the two details are not identical then you will not be able to launch any resources! (I had this problem at work today which is why I decided to refresh my knowledge about STAs and thought of writing this blog post. If the two details are not identical you will get a “Cannot start App:” error because the ticket the client has cannot be validated or used by the NetScaler). 

Just as an aside to myself – the port used to talk to the VDA is 1494 or 2598. This is the case if the Citrix Receiver or Browser contacts the VDA, or if the NetScaler gateway does so on behalf of these. I like to remember port numbers. :o) 

Also – there is nothing that ties a particular STA generated ticket to the device where the request was made from. That is, in theory a remote user could make a request from Computer A, get the ICA file and run it on Computer B – and NetScaler + STA will happily let the user access resources. A ticket only has a 100 seconds validity, so they’d have to do this switch-over quickly though. ;o) Also, a ticket can only be used once. (Also this and more info are from the very informative Citrix STA FAQ by the way). 

Creating an AD certificate for NetScaler 10.5

This post is based on a post by someone else that I found while I had to do this today. I wanted to configure NetScaler 10.5 with Citrix Storefront 3.9 and found that post useful, but some of the screenshots were different in my case – so thought I’d write it down for my future self. This post is going to be less on writing and more of screenshots as I am feeling very lazy.

So without much further ado –

Login to the NetScaler and create an RSA Key

1-2-3 as below.

Fill in the following fields and click “Create”.

The file name and extension doesn’t matter but we will refer to it later.

Create a Certificate Signing Request (CSR) on the NetScaler

Again, the request file name does not matter. The key filename & password is same as what we used earlier. There’s few more fields to fill – obvious ones like the organization name etc, the mandatory ones have an asterisk – then click “Create”.

Open the CSR

Click the link to view. Then click the link to “save text to a file”.

Login to your AD Certification Authority and submit the request

I am going to use the command line as the CSR doesn’t contain info on what template the CA should use, and that gives an error on the GUI: “0x80094801 – the request contains no certificate template information”.

Using the command line is simple. Open the command prompt and type the following:

This will prompt you for the location of the CSR and also the CA to use etc.

If you get any error about missing templates here, it’s possible you haven’t added the “Web Server” template to your CA templates. You can via this menu –

The command will also prompt for a location to save the generated certificate at. Save it someplace, then go back to the NetScaler.

Login to the NetScaler and install this certificate

Click the Install button as above. Then fill in the details as below. The certificate-key pair name does not matter. The certificate file name is chosen by clicking on “Browse”, then “Local”, and selecting the certificate file that you previously saved. The key file name and password are same as what you typed in the initial screenshot.

Finally, click “Install”.

That’s it! The NetScaler now has a certificate issued by the AD CA.