NetScaler Identity handling capabilities

Overview

Far too often I’m facing an assumption that the NetScaler is “just a load balancer” or the Gateway for Citrix environments. Of course it’s true that NetScaler can do both of the above, but it’s capable of so much more.

We here at Comping have been working on various cases around identity and NetScaler has proven to be quite versatile on the challenges our customers are facing. For some parts this was already discussed in a previous blog post Security basics, part 2 – Who?, but we’ll take it up a notch this time.

---

Multi-factor authentication (MFA)

Whether it’s your personal or business system that has something “worth stealing” you will need to have strong authentication setup.

NetScaler can really help you with this one. In the past we’ve worked a lot with some might call “legacy” MFA configured on-premises using RADIUS protocol, but now most of our customers are using the Microsoft Entra ID with Conditional Access and/or the NetScaler Native OTP. Obviously one thing driving customers to these solutions is cost-savings as many already have a Microsoft 365 subscription that includes the modern authentication capabilities (such as passwordless, FIDO2, push notifications, TOTP, etc…).

The NetScaler Native OTP is used by many of our customers especially for contractor authentication because it’s included basically with all NetScaler licenses (Advanced or Premium editions) and is relatively easy to set up. We’re also seeing more and more deployments of the Native OTP for internal management portals (discussed in Security basics, part 2 – Who? under other points of notice).

Besides the solutions above, we’ve also integrated customer environments with other IdPs like Okta Identity and Google IdP. Some customers have also leveraged the certificate-based authentication (smartcards, machine certs, user certs).

Single sign-on (SSO)

Having the user to log on just once (with MFA) has certainly it’s benefits from the user perspective, but also drives down the cost with less help desk calls and lost working hours.

NetScaler and Citrix products help you to achive SSO in many environments where it might close to impossible to achieve otherwise. Conceptually I would break this down to two separate entities;

Client authentication

However, using an external Identity Provider (IdP) is on the rise for obvious reasons as there are many excellent providers available like Microsoft Entra ID, Google Identity Platform and OKTA to name few. When using one of these the NetScaler Gateway/AAA engine is configured as Service Provider (SP). You might have ran in to terms like Security Assertion Markup Language (SAML) and Open Authorization (OIDC/OAuth2).

A relevant point to understand in regards of SSO, is that with the traditional authentication both the username and password can be “captured” on the NetScaler, whereas with modern federated authentication the password is not available for the NetScaler (in most cases).

Bearing this in mind, the user is authenticated and we know who we are dealing with. We can and we should also authorize the user as part of this process. We’ll handle the authorization in another post (do we grant access to the resource or not?).

Single sign-on

Once we have handled the authentication and authorization we can give the user access to the requested resource. The resource itself often requires authentication / authorization. There are two different resource types we’ll handle here, Citrix virtual desktops and applications and web applications.

Virtualized desktops and apps

When connecting to Citrix Virtual Desktop Agent (VDA), we can single sign-on to the Citrix StoreFront and to the virtualized desktop or application. To be able to do this Citrix has created Federated Authentication Service (FAS) which basically creates a certificate for the user that can be used for single sign-on. This is due to limited ways to authenticate to Windows OS (username + password / certificate). Of course this is evolving as we speak, so new stuff is on the way which will definitely help and simplify the process eventually.

Legacy web applications

Probably worth mentioning that there are also web applications with local authentication and static credentials and sharing these with your end users or contractors might be a bit scary. We can hide these from the end user, store them in NetScaler and use them on the end users behalf (as long as they’re properly authenticated and authorized first).

Modern web applications

Modern web applications support authentication / authorization protocols that are web compatible. Rather than passing on the users whole identity (meaning username and password) like with the legacy ones, you rely on federated authentication using OIDC/OAuth2 and SAML.

Good news! The NetScaler’s AAA engine is also capable of functioning as an IdP for the methods above. Regardless of the client authentication, the NetScaler can cover the “last mile” of authentication to the resource. We have deployed countless environments where the NetScaler acts initially as an SP for some external IdP and finally IdP for the actual resource (SP).

This way we can eliminate many challenges, like:

The inhouse application is configured to use OIDC, but as it’s in-house, there’s limited resources to develop the authentication / authorization capabilites and the security team is reluctant to pass traffic directly to the web server or allowing it to communicate to internet (to verify access tokens for examle).

We can set up NetScaler in between both as a reverse proxy and OIDC/IdP for the application.

The security team requires that all client authentication must be handled with SAML, but our application only supports OIDC/OAuth2.

We’ll configure NetScaler as a SAML SP for the desired IdP and as an OIDC IdP for the application.

—

For me at least it was quite important to understand that you’re able to do “chained federation”, so that you’re able to use something as the initial IdP, but use the SP as IdP for some other resource.

To be honest though; if you are using federated client authentication and your web application uses a legacy authentication method, SSO isn’t possible for the most cases – or it is but you will need to configure the NetScaler to capture the user’s password after logging in to the external IdP.

Other

We’ll what about my VPN then? If I want to SSO to that one?

You just need to configure your VPN as SAML/OIDC SP for your IdP and you’re good to go. If your VPN solution doesn’t support such thing and you’re running NetScaler already, please do understand that the NetScaler itself is capable of running your VPN connections. And it’s also pretty awesome with authentication, so you’d might want to have a look.

We’ve set up NetScaler in parallel to one Palo Alto Global Protect as it was missing some capabilities you can enable on a NetScaler with a flick of a switch (Entra ID as IdP -> NetScaler as SP, NetScaler as IdP -> Global Protect as SP).

Followup

Invite us for a visit!

That’s not all folks – I’ll try to drop a couple of (anonymized) real-life examples in following posts that you can reflect on.