_{Courtsey Cloud Software Group /NetScaler}

NetScaler Gateway presents all hosted, SaaS, web, enterprise, and mobile applications to users on any device and any browser. It uses nFactor Authentication to authenticate users against on-premises Microsoft AD and leverages Microsoft AD FS for Azure Multi-Factor Authentication (MFA)

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.

People are connecting to organizational resources in increasingly complicated scenarios. People connect from organization-owned, personal, and public devices on and off the corporate network using smartphones, tablets, PCs, and laptops, often on multiple platforms. In this always-connected, multi-device, and multi-platform world, the security of user accounts is more important than ever. 

Passwords, no matter their complexity, used across devices, networks, and platforms are no longer sufficient to ensure the security of the user account, especially when users tend to reuse passwords across accounts. 

Sophisticated phishing and other social engineering attacks can result in usernames and passwords being posted and sold across the dark web. 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 known (typically a password)
• Something the user has (a trusted device that is not easily duplicated, like a phone)
• Something user is (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 into 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: 

The solution uses one public SSL certificate:

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

Authentication flow

Sequence diagram

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

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: 

Demo Environment Configuration

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.

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

Continue in part 2