Many of our customers use NetScaler to securely load balance their StoreFront implementations. To make their environment fully STIG-compliant, there are several considerations that go above and beyond standard Citrix-recommended load balancing practices.

In one of my previous articles — Implementing Citrix StoreFront LTSR with DISA STIGs on Server 2012 R2 — I outlined the installation and configurations steps necessary to make your StoreFront server STIG-compliant. In this post, I will discuss how to use NetScaler to properly load balance Citrix StoreFront when it has been secured with DISA STIGs.

Overview

To start, let’s look at why there are special considerations when load balancing StoreFront with IIS STIG requirements. The two main vulnerabilities that we need to address are:

• IIS 8.5 Site V-76807: Each IIS 8.5 website must be assigned a default host header.
• IIS 8.5 Site V-76787 and Server V-76685:  An IIS 8.5 web server behind a load balancer or proxy server, must produce log records containing the source client IP and destination information.

There are two basic ways that you can approach these IIS vulnerabilities with NetScaler:

1. Authenticate with smart card at NetScaler Gateway using SSL load balancing.
2. Authenticate with smart card directly at StoreFront using SSL_Bridge load balancing.

By authenticating at NetScaler Gateway, the V-76807 and V-76787/V-76685 vulnerabilities can be addressed. This should be the preferred method of authenticating to StoreFront if you are trying to abide by as many STIG requirements as possible.

If you are unable to use NetScaler Gateway for authentication, you are still able to utilize SSL_Bridge load balancing. However, you will have security findings for V-76787 and V-76685 as this type of load balancing cannot insert client IP headers into packets.

To begin, I’ll discuss how to setup special StoreFront monitors to be compatible with V-76807 and which monitors can be used in both authentication scenarios. Then I’ll address each authentication scenario separately.

Monitoring STIGed StoreFront
In standard environments, we would always recommend using our standard StoreFront Monitor that automatically tests various StoreFront service components to ensure they are fully operational. However, due to IIS Site STIG V-7-6807 we’ll have to create our own custom ones.

A couple notes on this before we look at the configurations:

• Custom monitors are being used in lieu of our standard StoreFront Monitor as it uses the IP address instead of the hostname of the StoreFront servers when performing its monitor checks. This is impossible due to IIS Site STIG V-76807 which requires that HTTP HOST headers are sent for the FQDN and not an IP address. If you attempt to utilize this with a STIGed StoreFront server, the monitor will show as DOWN.
• These monitors only account for a single StoreFront Store. If you wish to monitor additional Stores, then you will need to create another set of customer Monitors to do so with the appropriate Store name.
• The Protocols and Token service paths here are only for newer versions of StoreFront that use individual authentication services for each Store. In previous versions the authentication service was shared using these paths instead: /Citrix/Authentication/Auth/v1/protocols and /Citrix/Authentication/Auth/v1/token. These paths are subject to change in future versions of StoreFront!
• This configuration allows for your monitors to traverse over your SNIP data network. If you utilized our default StoreFront monitors, they are always sourced from the NSIP management IP. This is undesirable if you want to separate data and management traffic. Creating custom monitors will force this out of the SNIP instead. For more information on this, see my article Separating NetScaler Data and Management Traffic for DISA STIGs.

Here are the components and configurations that are needed under the NetScaler Load Balancing feature. Replace “STORE” with your StoreFront Store name, and “BASEFQDN” with the Base URL host FQDN for your load balanced virtual server (for example desktops.customer.com). Only include the host name for this FQDN and not the preceding https://.

Notice that we are adding “HOST: BASEFQDN” to each requests HTTP headers to deal with the V-76807 STIG requirements at StoreFront.

If you are using Receiver for Web, then add this additional custom monitor to check the base Web URL landing page:

Just bind these monitors to your StoreFront server Service Groups or Services and ensure that any of the custom strings above are accurate. If you’ve configured it correctly, you will see that your StoreFront services show as UP! These monitors can be used with both authentication methods below.

Load Balancing for Authentication at NetScaler Gateway

It is possible to address V-76685 by having users perform smart card authentication at NetScaler Gateway. This is due to NetScaler Gateway natively adding a X-FORWARDED-FOR Header to the HTTP information sent to StoreFront. This HTTP Header can then be logged in IIS on the StoreFront servers as required by V-76787/V-76685.

To accomplish this, you’ll need to stand up a Gateway Virtual Server on NetScaler. The trick here will be to set this NetScaler Gateway for Authentication Only inside of StoreFront under Manage NetScaler Gateways.

This will allow you to authenticate at NetScaler but still create direct ICA/HDX connections from internal clients to your XenDesktop or XenApp environment.

For additional information on how to configure NetScaler Gateway and StoreFront with smart card authentication, check out the following articles:

• Configuring Smart Card Authentication
• Configuring NetScaler Gateway Single Sign-On with Smart Card PIN-Prompt
• Using CAC and PIV with NetScaler Gateway and StoreFront
• Reducing PIN Prompts with NetScaler Gateway and Smart Cards

Now on to the basic NetScaler configurations:

This is not inclusive of all the configurations that are required for this to work, so make sure to review the linked articles above if you are having issues.

To allow IIS to track the X-FORWARDED-FOR header, perform the following on your StoreFront servers:
• Open IIS Manager
• Select the Default Web Site and then Logging
• Under Log File, open Select Fields… then Add Field…
• Enter the following into the Add Custom Field window and Apply afterwards

Load Balancing for Authentication at STIGed StoreFront
If it’s not possible for users to authenticate at NetScaler in your environment, it is still possible to load balance STIGed StoreFront servers. However, you will not be able to fully address V-76787/V-76685 as we must use a load balancing server type of SSL_Bridge. This is due to client certificate/smart card authentication happening during the initial SSL handshake. This process cannot be broken for NetScaler to insert client IP header information into the HTTP packets. In this scenario, V-76787 and V-76685 will be security findings.

Another limitation of this method is the inability to use the COOKIEINSERT load balancing persistency method. We generally recommend this method of creating persistence if possible, but in this case we will need to use SOURCEIP as the persistency method. Here are the configurations:

Other Configurations
There are a few other considerations when load balancing StoreFront servers that have been secured that I want to call out:

• Make sure to disable SSLv3 and TLSv1 on your NetScaler Virtual Servers and/or your backend/frontend SSL profiles. See CTX205258 for information on SSL Profiles, and
• Update your NetScaler devices to at least 11.0 65.35 due to issues with IIS server. See CTX205578 for more information.

Summary

These configurations should allow you to properly monitor and load balance StoreFront LTSR when configured for IIS 8.5 Server and Site STIGs. If you have any questions regarding these configurations let me know in the comments.

Nick Czabaranek
Lead Architect US Public Sector Consulting Services