NetScaler Gateway

Author: Saman Salehian, Partner Sales Engineer

Federation and single sign-on

NetScaler Gateway provides federated identity and supports SAML 2.0, OAuth, and OpenID to achieve single sign-on across all applications, whether web, VDI, enterprise, or SaaS applications.

User directory on-premises

NetScaler Gateway provides SSO to SaaS applications such as Office 365 and Salesforce, and it keeps the user directory on-premises. It can be implemented as an IdP or proxy for Microsoft Active Directory Federation Services (AD FS).

Multi-factor (nFactor) authentication

NetScaler Gateway provides nFactor authentication mechanisms and allows granular control over who is accessing the network, what is being accessed, and how and when it is accessed. It supports all the authentication mechanisms, such as RADIUS, TACACS, NTLM, Diameter, SAML 2.0, OAuth 2.0, and OpenID 2.0.

Contextual access control policies

NetScaler Gateway allows granular access control to business applications based on the state of the end-user device, user, user location, and other data. An IT administrator can create, manage, and enforce the policies to access data securely in an application environment. These policies can be implemented for VDI, web, mobile, enterprise, and SaaS applications.

Visibility and Monitoring

NetScaler Application Delivery Management includes Gateway Insight, which provides visibility of the end-to-end user experience for all applications accessed through NetScaler Gateway. It provides information for application support teams to troubleshoot issues regarding authentication failures, including EPA check failures and single sign-on failures.

The security of the two-step verification process lies in its layered approach. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn the user’s password, it is useless without also having possession of the additional authentication method. It works by requiring two or more of the following authentication methods:

• Something you know (typically a password)
• Something you have (a trusted device that is not easily duplicated, like a phone)
• Something you are (biometrics)

Azure Multi-Factor Authentication helps safeguard access to data and applications. It provides an extra layer of security using a second form of authentication. Organizations can use conditional access to make the solution fit their specific needs.

Microsoft Azure MFA deployment methods

There are different methods to leverage Azure MFA as a second factor of authentication. Such methods are briefly explained below with their pros and cons.

Azure MFA server

Microsoft Azure Multi-Factor Authentication server was the original method and it is going to be deprecated. It should not be considered for any new implementation as

• There is no further investment from Microsoft going forward on this method.
• There is no integration with SSPR and Azure MFA Cloud-based.
• There is no seamless migration tool from MFA Server to MFA Cloud-based solution.

Azure MFA Network Policy Server extension

Network Policy Server (NPS) extension for Azure MFA is a supported solution that uses NPS Adapter to connect with Azure MFA Cloud-based. It can be used as the on-premises RADIUS server.

• NPS Adapter (RADIUS) will provide a network location inside/outside MFA Rule or On/Off.
• It is not compatible with Azure AD Conditional Access Policies similar to SAML integration method. Conditional Access policies have much richer and better user experiences.
• Users must be registered in MFA prior to using NPS Adapter. Unlike Azure MFA Cloud-based and Conditional Access, if the user is not registered, then NPS Extension fails to authenticate the user, which generates more calls to the help desk.
• When NPS Adapter invokes MFA, it hits the user's registered default option. There is no visual notification to the user that MFA is required and coming. There is no UI for the user to change MFA methods during a gated process. If the user doesn’t have their default device with them, it will fail. The user must go back to the self-service portal and reset the default option, and then try to connect again.

Microsoft AD FS and Azure MFA

If your organization is federated with Azure AD, but Passwords Hash are not synchronized with Azure AD, then you can use on-premises AD for Lightweight

Directory Access Protocol (LDAP) and enable Azure MFA as part of Access Policies on AD FS relay parties. Starting with Windows Server 2016, you can now configure Azure MFA for primary authentication.

• Azure MFA adapter is built into Windows Server 2016, and there is no need for an additional installation.
• Azure MFA adapter integrates directly with Azure AD and does not require an on-premises Azure MFA server.
• If users are not registered for MFA, they are guided through the process on their next sign-in. It ensures fewer calls to the help desk and a better process for users.
• Users get a visual notification that MFA is required and coming. Users can change the gateway option during a gated process in the UI.

Azure AD and Azure MFA

If your organization is synchronizing Passwords Hash into Azure AD, Azure MFA can be leveraged via Conditional Access policies to challenge users for second-factor authentication.

• This method does not require any additional installations on-premises.
• If users are not registered for MFA, they are guided through the process on the next sign-in. It ensures fewer calls to the help desk and a better process for users.
• Users get a visual notification that MFA is required and coming. Users can change the gateway option during a gated process in the UI.

Azure AD pass-through authentication and Azure MFA

Azure AD pass-through authentication (PTA) permits users to sign in to both on-premises and cloud-based applications using the same passwords. When users sign in using Azure AD, this feature validates users’ passwords directly against on-premises Active Directory. Azure AD PTA is an alternative to Azure AD Password Hash Synchronization, which provides the same benefit of cloud authentication to organizations.

• Azure AD PTA requires a lightweight agent to be installed on-premises.
• Azure AD PTA protects the user accounts by working seamlessly with the Azure AD Conditional Access policies, including Azure MFA.
• Users can complete self-service password management tasks in the cloud.
• On-premises passwords are never stored in the cloud in any form.
• The agent only makes outbound connections from within your network. Therefore, there is no requirement to install the agent in a perimeter network, also known as a DMZ.

Current situation

An environment with the following characteristics requires leveraging Azure MFA as a second factor of authentication:

• On-premises AD with Azure AD Synchronization is configured.
• Azure AD Password Hash Synchronization is disabled.
• Access to O365 applications is required.
• Access to Citrix Virtual Apps and Desktops on-premises is required.
• Access to applications with modern authentication methods (SAML, OAuth) is required.
• Access to applications with legacy authentication methods is required.

Design points

Here are the design points for the proposed solution:

• Access hosted, SaaS, enterprise, and web applications in a single portal, and security is required.
• Users must only be required to enter their credentials once during the authentication process.
• Single sign-on must be provided for all hosted, SaaS, enterprise, and web applications.

Proposed solution

Overview

The proposed solution is based on the following components:

• On-premises NetScaler Gateway
• On-premises Microsoft AD
• On-premises Microsoft AD FS
• On-premises NetScaler ADC as AD FS Proxy
• Microsoft Azure MFA

NetScaler Gateway is leveraging authentication, authorization, and auditing feature (NetScaler ADC AAA) and nFactor authentication mechanisms to authenticate the user with LDAP policy and leverage Access Policy on AD FS Relay Party to trigger Azure MFA validation process. After Azure MFA validates the user, AD FS generates SAML Assertion (SAML response) and redirects the user back to NetScaler Gateway. At that point, the user is authenticated and NetScaler Gateway presents all applications that the user is authorized to use.
 

The solution requires two public DNS records and two public IP addresses:

 

Description	Value
NetScaler Gateway FQDN	access.ctxdemos.com
NetScaler authentication, authorization, and auditing FQDN	aaa.ctxdemos.com

 

The solution uses one public SSL certificate:

Description	Value
Common Name	access.ctxdemos.com
Subject Alternative Name	sts.ctxdemos.com
Subject Alternative Name	aaa.ctxdemos.com

The solution also uses a wildcard SSL certificate issued by internal Microsoft Certificate Authority Services:

Description	Value
Common Name	*.ctxdemos.com

Authentication flow

Sequence diagram

The following sequence diagram shows the authentication flow for the solution:

Authentication steps

The authentication steps are:

1. User navigates to https://access.ctxdemos.com.
2. NetScaler Gateway redirects the user to the first NetScaler ADC AAA VIP (Non-Addressable).
3. First NetScaler ADC AAA VIP uses a no-schema logon, which is configured with a single sign-on. Then it starts processing the advanced authentication policies.
4. The first authentication policy is SAML SP to a non-addressable LB VIP to generate authentication cookies.
5. The helper LB VIP is configured to use the second NetScaler ADC AAA VIP (Addressable) for authentication. So, it redirects the user to the second authentication, authorization, and auditing VIP.
6. Second NetScaler ADC AAA VIP uses the Username Only logon schema, which prompts the user for the user name. Then it starts processing the advanced authentication policies.
7. The first authentication policy is a Group Extraction, which queries the user name in an on-premises AD and validates if the user belongs to the AzureMFACAUsers security group. Once the result of validation is successful, it starts to process the next authentication factor which is the LDAP policy.
8. The LDAP policy uses the UsernameAndPassword login schema and a pre-filled user name field and prompts the user for the AD password.
9. When authentication on the second NetScaler ADC AAA VIP is completed successfully, it goes back to helper LB VIP which generates a SAML response for the first authentication, authorization, and auditing VIP.
10. The first NetScaler ADC AAA VIP starts processing the next factor, which is a Group Extraction to ensure the user’s groups are extracted from AD and stored in the authentication, authorization, and auditing variable to be used later in the process.
11. First NetScaler ADC AAA VIP starts processing the next factor, which is a SAML SP to AD FA Proxy VIP on NetScaler ADC.
12. NetScaler ADC is federated with the AD FS farm. The detailed steps are explained in later sections.
13. AD FS Proxy VIP validates that the authentication cookies (NSC_TMAA and NSC_TMAS) are set. Then it sends the SAML Request to a back end AD FS server (the back-end AD FS servers should be load balanced on internal NetScaler ADC for high availability and resiliency of service).
14. AD FS server processes the SAML request. Because the Access policy on the Relaying Party is set to “Permit all users and require MFA for authentication,” it triggers the Azure MFA authentication process.
15. Azure MFA processes the user name. If it is already registered, it challenges the user with the configured method. If not, it prompts the user to register and set the primary and secondary authentication methods.
16. Once the Azure MFA authentication process is completed successfully, AD FS generates a SAML response for NetScaler Gateway (First NetScaler ADC AAA VIP).
17. First NetScaler ADC AAA VIP receives a SAML response and confirms that the authentication process for the user is completed.
18. NetScaler Gateway sends authentication information to Citrix StoreFront, which enumerates all applications and desktops that the user is authorized to use. Also, it processes the user’s group membership to present published bookmarks on NetScaler Gateway.

Authentication screens

Most of the steps mentioned above are seamless to users as they are occurring internally between various VIPs on the NetScaler ADC. The user experience is shown below:



​​​​​Implementation

Microsoft AD FS

Certificate requirements

Federation servers require the certificates in the following table:
 

Implementation

Microsoft AD FS

Certificate requirements

Federation servers require the certificates in the following table:

 

Certificate Type	Description	What needs to be known before deploying
Secure Sockets Layer (SSL) certificate	This is a standard Secure Sockets Layer (SSL) certificate that is used for securing communications between federation servers and clients.	This certificate must be bound to the default website in the Internet Information Services (IIS) for a Federation Server or a Federation Server Proxy. For a Federation Server Proxy, the binding must be configured in IIS prior to running the Federation Server Proxy Configuration Wizard successfully. Recommendation: Because this certificate must be trusted by clients of AD FS, use a server authentication certificate that is issued by a public (third-party) certification authority (CA). For example, Verisign. Tip: The Subject name of this certificate is used to represent the Federation Service name for each instance of AD FS that you deploy. For this reason, you may want to consider choosing a Subject name on any new CA-issued certificates that best represents the name of your company or organization to partners.
Service communication certificate	This certificate enables WCF message security for securing communications between federation servers.	By default, the SSL certificate is used as the service communications certificate. This can be changed using the AD FS Management console.
Token-signing certificate	This is a standard X509 certificate that is used for securely signing all tokens that the federation server issues.	The token-signing certificate must contain a private key, and it should chain to a trusted root in the Federation Service. By default, AD FS creates a self-signed certificate. However, you can change this later to a CA-issued certificate by using the AD FS Management snap-in, depending on the needs of your organization.
Token-decryption certificate	This is a standard SSL certificate that is used to decrypt any incoming tokens that are encrypted by a partner federation server. It is also published in the federation metadata.	By default, AD FS creates a self-signed certificate. However, you can change this later to a CA-issued certificate by using the AD FS Management snap-in, depending on the needs of your organization.

 

Demo Environment Configuration

Certificate type	Demo Environment Configuration
Secure Sockets Layer (SSL) certificate	Internal certificate issued by internal issuing CA on AD FS server. Public trusted certificate on NetScaler ADC.
Service communication certificate	Internal certificate issued by AHS internal issuing certificate authority.
Token-signing certificate	Auto generated by AD FS service.
Token-decryption certificate	Auto generated by AD FS service.

In the demo environment, a wildcard certificate is enrolled and installed on the server.

Service account requirements

You can either create a service account or leverage Group Managed Service Accounts (gMSA). To use gMSA, you need to create a Key Distribution Service Root Key. So, launch PowerShell and run the following command:
 

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

This command creates a Key Distribution Service Root Key, stored in Active Directory, and it allows you to create a group Managed Service Account (gMSA) as the AD FS service account you create later. Run this command with Domain Admin rights.

DNS record requirements

You need DNS A record for your AD FS Federation Service Name internally and externally. In the demo environment, Internal DNS record is pointing to the AD FS server IP and External DNS record is pointing to the NetScaler Gateway public IP.

Record name	Scope	Type	IP address
sts.ctxdemox.com	Internal	A	22.22.22.6
sts.ctxdemox.com	External	A	40.85.225.175

Add the AD FS role and configure the AD FS farm

Add the AD FS role

To add the AD FS role to Windows Server 2016 launch PowerShell and run the following command:

 

Install-WindowsFeature AD FS-Federation -IncludeManagementTools

Continued in Part 2