For most Citrix Virtual Apps and Desktop environments, a key piece of the end-to-end architecture is the Citrix ADC, formally Citrix NetScaler. Citrix Gateway is one of the many features on the Citrix ADC appliances that provide secure external access to a Citrix or Horizon environment. If you are using the ADC for Citrix Gateway, you are barely scratching the service of what this appliance is truly capable of.
The ADC can deliver applications over the internet or private networks while combining application-level security, traffic management, and optimization into a single, integrated appliance. It sits in front of the applications, improving throughput, scalability, security, and enhancing the request/response flow.
Essentially, just placing an ADC on the network in front of applications allows you to offload and reuse existing TCP connections; when properly configured, users will instantly see an improvement in accessing applications right out of the box.
But for many organizations, the Citrix Gateway may be the only reason the ADC is even on the network. If this is the sole use of this very versatile appliance, the ROI is grossly underutilized.
This blog post outlines some features that can often go together with Citrix Gateway and some you may not know about.
Let’s start with the most commonly used feature on the Citrix ADC. If you are using Citrix Gateway with a Citrix Virtual Apps & Desktops environment, chances are you are already using load balancing for Citrix StoreFront. The Citrix Gateway wizard completes this setup so that connections through the Citrix Gateway can reach multiple Citrix StoreFront servers.
Although not configured by the Citrix Gateway, other Citrix Virtual Apps and Desktop components can also be load balanced, such as the XML Brokers, Provisioning Servers, and the Desktop Delivery Controllers (DDCs).
It is also common and recommended to load balance access to authentication servers such as LDAP and RADIUS. Generally, anything that is crucial to the end-to-end flow of accessing applications should have redundancy.
You might be thinking, “Wait a minute, isn’t Unified Gateway and Citrix Gateway basically the same thing?” Well, no, not at all. At its core, Unified Gateway is Content Switching with a preconfigured policy to pass access to Citrix Gateway. It is the Content Switching that gives Unified Gateway its often-under-utilized capabilities.
You use Unified Gateway if you need to provide secure access to applications through a single URL while providing a single sign-on to all those applications. For instance, a single URL and public IP address can provide access to not only Citrix Gateway but access to Outlook Web Access and SharePoint.
Other categories of applications commonly accessible through a Unified Gateway are intranet applications, clientless applications, SaaS applications, Citrix WorkSpace published applications, and preconfigured applications, such as load-balanced applications through the Citrix ADC.
A Unified Gateway is helpful if you have multiple Citrix Gateways on the same ADC appliance or even scattered among multiple ADC appliances and want to make them all accessible through a single access point.
You may need multiple Citrix Gateways in an environment where authentication methods might vary from one Citrix Gateway to another, such as one Citrix Gateway using LDAP and one using SAML. A Unified Gateway can determine the conditions where one Citrix Gateway virtual server, such as different authentication type, is selected over the other. This makes extraordinarily complex environments much easier to configure and frees up IP addresses since the Unified Gateway needs only one IP no matter how many applications are behind it.
For the authentication use case, there is another way to accomplish this type of flexibility, and that’s with a feature known as nFactor.
If multiple multi-factor authentication types are desired, nFactor is a feature that allows you to conditionally choose which type of factor, or which multiple factors to present during the authentication process.
Most organizations do not often need this degree of separation of policies to implement multi-factor authentication. However, if there is a use case where not everyone will use the same type of authentication, or authentication needs to be separated based on geographic location or business case use, then nFactor is the solution.
With nFactor, you can conditionally (i.e., with policies) direct the authentication request through multiple proofs of identity to gain access. For instance, you could have one authentication method tied to a specific group of users versus a different authentication method tied to another group of users.
With Citrix Gateway alone, this is not possible because the group extraction occurs after the user authenticates. The group the user is a member of is unable to be determined during the authentication process.
The nFactor feature is extremely powerful and flexible. It allows the creation of conditional authentication flows for any scenario. Suppose you want to block certain users or devices from authentication entirely, or you want to restrict the level of access to certain users or devices after they have authenticated, nFactor allows all these scenarios.
Another great use for nFactor is when there is a business need for end-point analysis, such as determining device security standards including anti-virus and patch level compliance.
With Citrix Gateway alone, end-point analysis policies can only be applied either prior to the user authenticating or post-authentication as an additional condition to apply a particular session policy.
If the end-point analysis is done pre-authentication, that affects everyone that accesses the Citrix Gateway, including mobile devices that cannot perform end-point analysis at all, because the end-point client is not supported on mobile devices. A better solution is to conditionally filter out the mobile connections via nFactor and allow those devices to have an authentication experience that does not include end-point scanning, while other devices that support the end-point client prompt the user for the scan.
Just like more commonly used enterprise class VPNs – like Cisco AnyConnect, FortiGate, and BIG-IP – the Citrix Gateway that fronts your Citrix Apps and Desktops environment can be a fully enabled enterprise-class Secure Sockets Layer Virtual Private Network (SSL VPN).
An SSL VPN provides a secure connection for remote users of applications and allows them to work as if they were sitting in the office, including accessing network resources such as file shares, web sites, and intranet applications.
When Citrix Gateway is used to access Citrix Virtual Apps and Desktops, this can be configured as a secure selective access mechanism. In this mode, it is called an ICA Proxy configuration. But you can also configure additional policies that open the full feature set of Citrix Gateway. You can configure the Gateway to be an SSL VPN Gateway or a combination of both ICA Proxy and SSL VPN.
Two features that Citrix Gateway provides that allow you to change ICA connection behavior are SmartAccess and SmartControl and each is configured differently.
SmartAccess is where you use conditional based authentication, such as an end-point analysis check or other conditions, to determine which published resources a user has access to. Take for example a single user account that needs different published apps while working inside the office than when they are working at home. You can ensure when that user is working from home, they do not have access to the sensitive applications, even though their account and the Citrix Gateway access point is the same.
With SmartAccess, any policy that a Citrix Virtual App of Desktop environment has can be the basis of a selective access condition, such as device drive mapping, printer mapping, and clipboard access. SmartAccess requires a Citrix Gateway virtual server, along with a specific session policy that Citrix Virtual Apps and Desktops polices can use as a filter to make the determination whether a user should have access to the resource.
SmartControl provides similar capabilities, but instead is configured with ICA policies directly on the Citrix Gateway. The combination of an expression, which defines the condition, and a profile, which defines the action to take if the condition is confirmed, can be applied to the Citrix Gateway virtual server, individual users, groups, or globally affecting all the Citrix Gateway virtual servers configured.
You do not need Citrix Virtual Apps and Desktops to give users access to a machine on the network; you could use the RDP Proxy functionality of Citrix Gateway.
With RDP Proxy configured, a user can securely connect through a clientless VPN connection or ICA Proxy mode and launch an RDP session using their RDP client. Though not as commonly used to give end-users access to internal machines, this is a great way to give administrators a back door to a jump server where admin tools can be accessed if, for some reason, Citrix Apps and Desktops were not available.
Using the nFactor feature, you can create a custom login schema with a “Forgot Password” link that will allow users to change their password based on answering preconfigured questions.
Upon logging in the first time, the user is prompted to enroll. They then specify the questions and answers to questions they will be asked when prompted to reset their password. If a user forgets their password, they will need to answer two of the enrolled questions successfully.
The user could also request a one-time password (OTP) to be sent to an alternate email address if they do not have access to corporate email. This is a great feature to add to an existing Citrix Gateway because forgotten passwords tend to be among the most burdensome helpdesk calls for most organizations. Giving a user the ability to reset their password is a great quality of life improvement for both users and admins.
If you have just configured a Citrix Gateway virtual server with the default configuration, you are likely missing some especially important security enhancements. An easy way to test your Citrix Gateway is to go to the SSL Labs website and run a test. You will get a letter grade and recommendations on what to do to receive an A+ rating from SSL Labs. If your site returns anything but an A+ rating, it is advisable to follow the recommendations and keep testing until an A+ rating is achieved.
The most common reason a rating is below A+ is because SSLv3 is enabled, and Secure Renegotiation has not been configured. You will also need to replace the default ciphers with more secure ciphers. Generally, your ciphers should all be SHA2 unless you need to enable support for older clients, such as Windows 7 or older browsers.
HTTP Strict Transport Security (HSTS), outlined in RFC 6797, is designed to protect websites against various attacks, including SSL stripping, cookie hijacking, and man-in-the-middle attacks that can intercept requests and redirect users to a malicious destination.
HSTS makes sure that sites only respond to HTTPS requests and does not allow users to override the warning that HTTPS is not being used. HSTS is supported and built into Citrix ADC 12.0 and above by creating a custom SSL profile.
The Citrix ADC Gateway is a powerful tool for improving security and reducing support requests with self-service password resets. However, many organizations are only using one or two of these features.
Want to know more about these features or the dozens of capabilities we did not cover here? Call Whitehat at 888.406.8719, send us an email or chat with us today. From simple guidance to full plans to implement these features in your environment, we would love to help.