AAA Traffic Module Validated Reference Design

Citrix ADC summary

Citrix ADC is an all-in-one application delivery controller that makes applications run up to five times better, reduces application ownership costs, optimizes the user experience, and ensures that applications are always available by using:

  • Advanced L4-7 load balancing and traffic management

  • Proven application acceleration such as HTTP compression and caching

  • An integrated application firewall for application security

  • Server offloading to significantly reduce costs and consolidate servers

As an undisputed leader of service and application delivery, Citrix ADC is deployed in thousands of networks around the world to optimize, secure, and control the delivery of all enterprise and cloud services. Deployed directly in front of web and database servers, Citrix ADC combines high-speed load balancing and content switching, http compression, content caching, SSL acceleration, application flow visibility, and a powerful application firewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplified with end-to-end monitoring that transforms network data into actionable business intelligence. Citrix ADC allows policies to be defined and managed using a simple declarative policy engine with no programming expertise required.

Citrix ADC AAA-TM module

Traffic management

AAA provides security for a distributed Internet environment by allowing any client with the proper credentials to connect securely to protected application servers from anywhere on the Internet. This feature incorporates the three security features of authentication, authorization, and auditing. Authentication enables the Citrix ADC to verify the client’s credentials, either locally or with a third-party authentication server. It allows only approved users to access protected servers. Authorization enables the ADC to verify which content on a protected server it should allow each user to access. Auditing enables the ADC to keep a record of each user’s activity on a protected server.

Citrix Gateway

Enterprises can now achieve federation and single sign-on across enterprise, Web, SaaS, and on-premises virtual applications and desktops via Citrix Gateway. Citrix Gateway leverages its Authentication, Authorization, and Auditing (AAA) features with content switching to enable users to access all their authorized enterprise applications through a single gateway and URL. Organizations deploying Citrix ADC today for their Virtual Apps and Desktops infrastructure can easily expand its functionality for single sign-on across enterprise legacy, Web, virtual and public, private, and hybrid cloud applications. Customers using third-party single sign-on and application delivery solutions and gateways can deploy a single solution for all their single sign-on needs by consolidating on Citrix Gateway.

Authentication mechanisms include LDAP, RADIUS, SAML, Kerberos, Certificate based Authentication, and more.

Whatever authentication mechanism is configured on a Citrix Gateway virtual server before the upgrade is used automatically used when the Citrix Gateway virtual server is placed behind the Unified Gateway virtual server.

There are no additional configuration steps involved, other than assigning a non-addressable IP address ( to Citrix Gateway virtual server.

Authentication overview

To understand how AAA works in a distributed environment, consider an organization with an intranet that its employees access in the office, at home, and when traveling. The content on the intranet is confidential and requires secure access. Any user who wants to access the intranet must have a valid user name and password. To meet these requirements, the ADC does the following:

  • Redirects the user to the login page if the user accesses the intranet without having logged in.

  • Collects the user’s credentials, delivers them to the authentication server, and caches them in a directory that is accessible through LDAP.

  • Verifies that the user is authorized to access specific intranet content before delivering the user’s request to the application server.

  • Maintains a session timeout after which users must authenticate again to regain access to the intranet. (You can configure the timeout.)

  • Logs the user accesses, including invalid login attempts, in an audit log.

Authentication requires that several entities: the client, the Citrix ADC appliance, the external authentication server if one is used, and the application server, respond to each other when prompted by performing a complex series of tasks in the correct order.

When an authenticated client requests a resource, the ADC, before sending the request to the application server, checks the user and group policies associated with the client account, to verify that the client is authorized to access that resource. The ADC handles all authorization on protected application servers. You do not need to do any special configuration of your protected application servers.

Password changes

AAA-TM handles password changes for users by using the protocol-specific method for the authentication server. For most protocols, neither the user nor the administrator needs to do anything different than they would without AAA-TM. Even when an LDAP authentication server is in use, and that server is part of a distributed network of LDAP servers with a single designated domain administration server, password changes are usually handled seamlessly. When an authenticated client of an LDAP server changes his or her password, the client sends a credential modify request to AAA-TM, which forwards it to the LDAP server. If the user’s LDAP server is also the domain administration server, that server responds appropriately and AAA-TM then performs the requested password change. Otherwise, the LDAP server sends AAA-TM an LDAP_REFERRAL response to the domain administration server. AAA-TM follows the referral to the indicated domain administration server, authenticates to that server, and performs the password change on that server.


When configuring AAA-TM with an LDAP authentication server, the system administrator must keep the following conditions and limitations in mind:

  • AAA-TM assumes that the domain administration server in the referral accepts the same bind credentials as the original server.
  • AAA-TM only follows LDAP referrals for password change operations. In other cases, AAA-TM refuses to follow the referral.
  • AAA-TM only follows one level of LDAP referrals. If the second LDAP server also returns a referral, AAA- TM refuses to follow the second referral.

Audit / logging support

The ADC supports auditing of all states and status information, so you can see the details of what each user did while logged on, in chronological order. To provide this information, the appliance logs each event, as it occurs, either to a designated audit log file on the appliance or to a syslog server. Auditing requires configuring the appliance and any syslog server that you use.

Limitations and usage guidelines

Authentication Matrix:


One public IP for AAA-TM deployments on Citrix ADC

Citrix ADC supports AAA framework for Traffic Management (TM) virtual servers (henceforth called vserver) by leveraging various AAA features supported by authentication subsystem. The server used for authentication is called “authentication vserver” or AAA vserver.

Citrix ADC can consolidate the above picture to one public endpoint by having authentication vserver slide adjacent to TM vserver so that there is one public end point, and in turn one certificate. This is depicted in the following diagram:


Windows hosted applications by Citrix Virtual Apps and Desktops

You can deploy Citrix Gateway at the perimeter of your organization’s internal network (or intranet) to provide a secure single point of access to the servers, applications, and other network resources that reside in the internal network. All remote users must connect to Citrix Gateway before they can access any resources in the internal network.

Citrix Gateway is most commonly installed in the following locations in a network:

  • In the network DMZ

  • In a secure network that does not have a DMZ

You can also deploy Citrix Gateway with Citrix Virtual Apps, Virtual Desktops, StoreFront, and Endpoint Management Server to users to access their Windows, web, mobile, and SaaS applications.

If your deployment includes Citrix Virtual Apps, StoreFront, or Virtual Desktops, you can deploy Citrix Gateway in a single-hop or double-hop DMZ configuration. A double-hop deployment is not supported with earlier versions of Virtual Desktops or Virtual Apps.

SAML 2.0 SaaS applications

Security Assertion Markup Language (SAML) is an XML-based authentication mechanism that provides single sign-on capability and is defined by the OASIS Security Services Technical Committee.

Why SAML? Consider a scenario in which a service provider (LargeProvider) hosts a number of applications for a customer (BigCompany). BigCompany has users that must seamlessly access these applications. In a traditional setup, LargeProvider would need to maintain a database of users of BigCompany. This raises some concerns for each of the following stakeholders:

  • LargeProvider must ensure security of user data.

  • BigCompany must validate the users and keep the user data up-to-date, not just in its own database, but also in the user database maintained by LargeProvider. For example, a user removed from the BigCompany database must also be removed from the LargeProvider database.

  • A user has to log on individually to each of the hosted applications.

The SAML authentication mechanism provides an alternative approach. The following deployment diagram shows how SAML works:


The concerns raised by traditional authentication mechanisms are resolved as follows:

  • LargeProvider does not have to maintain a database for BigCompany users. Freed from identity management, Large Provider can concentrate on providing better services.

  • BigCompany does not bear the burden of making sure the LargeProvider user database is kept in sync with its own user database.

  • A user can log on once, to one application hosted on LargeProvider, and be automatically logged on to the other applications that are hosted there.

The Citrix ADC appliance can be deployed as a SAML Service Provider (SP) and a SAML Identity Provider (IdP). Read through the relevant topics to understand the configurations that must be performed on the Citrix ADC appliance.

ADFS Hybrid cloud integration

AD FS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. When a user needs to access a Web application from one of its federation partners, the user’s own organization is responsible for authenticating the user and providing identity information in the form of “claims” to the partner that hosts the Web application. The hosting partner uses its trust policy to map the incoming claims to claims that are understood by its Web application, which uses the claims to make authorization decisions.

Active Directory Federation Services (AD FS) makes it possible for local users and federated users to use claims-based single sign-on (SSO) to Web sites and services. You can use AD FS to enable your organization to collaborate securely across Active Directory domains with other external organizations by using identity federation. This reduces the need for duplicate accounts, management of multiple logons, and other credential management issues that can occur when you establish cross-organizational trusts.

ADFS proxy mode

The AD FS 2.0 Proxy is a service that brokers a connection between external users and your internal AD FS 2.0 server. It acts as a reverse proxy and typically resides in your organization’s perimeter network (aka DMZ). As far as the users are concerned, they do not know they are talking to an AD FS proxy server, as the federation services are accessed by the same URLs. The proxy server handles three primary functions.

  • Assertion provider: The proxy accepts token requests from users and passes the information over SSL (default port 443) to the internal AD FS server. It receives the token from the internal AD FS server and passes it back to the user.

  • Assertion consumer: The proxy accepts tokens from users and passes them over SSL (default port 443) to the internal AD FS server for processing.

  • Metadata provider: The proxy will also respond to requests for Federation Metadata.

The AD FS 2.0 Proxy is not a requirement for using AD FS. It is an additional feature. The reason you would install an AD FS 2.0 Proxy is you do not want to expose the actual AD FS 2.0 server to the Internet. AD FS 2.0 servers are domain joined resources, while the AD FS 2.0 Proxy does not have that requirement. If all your users and applications are internal to your network, you do not need to use an AD FS 2.0 Proxy. If there is a requirement to expose your federation service to the Internet, it is a best practice to use an AD FS 2.0 Proxy.

See the following link for more information on Understanding the AD FS 2.0 Proxy.


The federated partner’s Identity Provider (IP) sends claims that reflect its users’ identity, groups, and attribute data. Therefore, your organization no longer needs to revoke, change, or reset the credentials for the partner’s users, since the credentials are managed by the partner organization. Additionally, if a partnership needs to be terminated, it can be performed with a single trust policy change. Without AD FS, individual accounts for each partner user would need to be deactivated. Configuring as the identity provider enables reusing existing accounts managed by existing Active Directory objects for authentication. It eliminates the need for either building complex account synchronization mechanisms or developing custom code that performs the tasks of accepting end user credentials, validating them against the credentials store and managing the identities.

Citrix ADC nFactor (Multifactor) authentication

nFactor gives a fresh perspective to authentication, streamlines the authentication flow, and provides great flexibility during authentication.

Multi-factor authentication enhances the security of an application by requiring users to provide multiple proofs of identify to gain access. The Citrix ADC appliance provides an extensible and flexible approach to configuring multi-factor authentication. This approach is called nFactor authentication.

With nFactor authentication you can:

  • Configure any number of authentication factors.

  • Base the selection of the next factor on the result of executing the previous factor.

  • Customize the login interface. For example, you can customize the label names, error messages, and help text. o Extract user group information without doing authentication.

  • Configure pass-through for an authentication factor. This means that no explicit login interaction is required for that factor.

  • Configure the order in which different types of authentication are applied. Any of the authentication mechanisms that are supported on the Citrix ADC appliance can be configured as any factor of the nFactor authentication setup.

These factors are executed in the order in which they are configured.

  • Configure the Citrix ADC to proceed to an authentication factor that must be executed when authentication fails.

To do so, you configure another authentication policy with the exact same condition, but with the next highest priority and with the action set to “NO_AUTH”.

You must also configure the next factor, which must specify the alternative authentication mechanism to apply.

Customer enterprise applications

Adaptive Multi-Factor Authentication (MFA) for tighter security

Enterprises have several stakeholders using their applications and data. Employees partners, vendors, and several others who need to access to apps and data from various locations and using various devices. Enterprises needed a way to authenticate different group of users in different ways. While different Gateways can be used for different groups of users, the maintenance and consistency in experience will be impacted with this approach.

  • SSO: Citrix ADC supports all SSO protocols – SAML, Kerberos, KCD, form-based, 401/NTLM. Citrix ADC supports SAML protocol and can play the SAML IDP role (use case 1. above) as well as SAML SP role (use case 2. above).

  • Host Profiling: Citrix ADC supports endpoint analysis (EPA) feature which is used for host profile checks. EPA can be used to grant quarantined access in case user is not meeting security checks necessary for full access.

  • Compliance Auditing: Citrix ADC supports a wide range of auditing mechanisms like Appflow, Syslog, and user-defined logging.

Configuration steps

Citrix Gateway for hosted windows applications

Network Architectures


When you deploy Citrix Gateway in the DMZ, user connections must traverse the first firewall to connect to Citrix Gateway. By default, user connections use SSL on port 443 to establish this connection. To allow user connections to reach the internal network, you must allow SSL on port 443 through the first firewall.

Citrix Gateway decrypts the SSL connections from the user device and establishes a connection on behalf of the user to the network resources behind the second firewall. The ports that must be open through the second firewall are dependent on the network resources that you authorize external users to access.

For example, if you authorize external users to access a web server in the internal network, and this server listens for HTTP connections on port 80, you must allow HTTP on port 80 through the second firewall. Citrix Gateway establishes the connection through the second firewall to the HTTP server on the internal network on behalf of the external user devices.

Citrix Gateway deployed in the secure network


When you deploy Citrix Gateway in the secure network, connect one interface on Citrix Gateway to the Internet and the other interface to servers running in the secure network. Putting Citrix Gateway in the secure network, provides access for local and remote users. This configuration only has one firewall. However, it makes the deployment less secure for users connecting from a remote location. Although Citrix Gateway intercepts traffic from the Internet, the traffic enters the secure network before users are authenticated. When Citrix Gateway is deployed in a DMZ, users are authenticated before network traffic reaches the secure network.

When Citrix Gateway is deployed in the secure network, Citrix Gateway Plug-in connections must traverse the firewall to connect to Citrix Gateway. By default, user connections use the SSL protocol on port 443 to establish this connection. To support this connectivity, you must open port 443 on the firewall.

SAML Identity Provider (IdP) mode


The SAML IdP (Identity Provider) is a SAML entity that is deployed on the customer network. The IdP receives requests from the SAML SP and redirects users to a logon page, where they must enter their credentials. The IdP authenticates these credentials with the user directory (external authentication server, such as LDAP) and then generates a SAML assertion that is sent to the SP.

The SP validates the token, and the user is then granted access to the requested protected application.

When the Citrix ADC appliance is configured as an IdP, all requests are received by an authentication virtual server that is associated with the relevant SAML IdP profile

Note: A Citrix ADC appliance can be used as a IdP in a deployment where the SAML SP is configured either on the appliance or on any external SAML

When used as a SAML IdP, a Citrix ADC appliance:

  • Supports all authentication methods that it supports for traditional logons.

  • Digitally signs assertions. Support for the SHA256 algorithm is introduced in Citrix ADC 11.0 Build 55.x.

  • Supports single-factor and two-factor authentication. SAML must not be configured as the secondary authentication mechanism.

  • Can encrypt assertions by using the public key of the SAML SP. This is recommended when the assertion includes sensitive information. Support introduced in Citrix ADC 11.0 Build 55.x.

  • Can be configured to accept only digitally signed requests from the SAML SP. Support introduced in Citrix ADC 11.0 Build 55.x

  • Can log on to the SAML IdP by using the following 401-based authentication mechanisms: Negotiate, NTLM, and Certificate. Support introduced in Citrix ADC 11.0 Build 55.x.

  • Can be configured to send 16 attributes in addition to the NameId attribute. The attributes must be extracted from the appropriate authentication server. For each of them, you can specify the name, the expression, the format, and a friendly name in the SAML IdP profile. Support introduced in Citrix ADC 11.0 Build 55.x.

  • If the Citrix ADC appliance is configured as a SAML IdP for multiple SAML SP, a user can gain access to applications on the different SPs without explicitly authenticating every time. The Citrix ADC appliance creates a session cookie for the first authentication, and every subsequent request uses this cookie for authentication. Support introduced in Citrix ADC 11.0 Build 55.x.

  • Can send multi-valued attributes in a SAML assertion. Support introduced in Citrix ADC 11.0 Build 64.x.

  • Supports post and redirect bindings. Support for redirect bindings is introduced in Citrix ADC 11.0 Build 64.x. o

If the system time on Citrix ADC SAML IdP and the peer SAML SP is not in sync, the messages might get invalidated by either party. To avoid such cases, you can now configure the time duration for which the assertions will be valid.

This duration, called the “skew time,” specifies the number of minutes for which the message should be accepted.

The skew time can be configured on the SAML SP and the SAML IdP.


Support introduced in Citrix ADC 11.0 Build 64.x.

  • Can be configured to serve assertions only to SAML SPs that are preconfigured on or trusted by the IdP. For this configuration, the SAML IdP must have the service provider ID (or issuer name) of the relevant SAML SPs. Support introduced in Citrix ADC 11.0 Build 64.x.

ADFS proxy mode configuration



To set up Citrix ADC as an ADFS proxy, the following features must be enabled in your Citrix ADC system - Load Balancing, Content Switching SSL Offloading. Configuring the Citrix ADC as an ADFS proxy involves the following steps:

  1. Set up a content switching virtual server. This is the ADFS proxy VIP, the IP address for this virtual server is the IP that will be used as the replacement for the ADFS server IP.
  2. Create four load balancing virtual servers: one each for active and passive authentication, one for metadata access and one for rewriting the request URL.
  3. Create and bind the required content switching policies to the CS vserver. These will consist of the following:
    • Two policies for parsing active and passive authentication requests, with pre-authentication enabled/disabled (disabled if authentication is preferred at the ADFS server)
    • One policy for parsing metadata requests, which are unauthenticated and have pre-authentication disabled.
    • One policy for rewriting the request URL from /adfs/services/trust to /adfs/services/trust/proxymex.
  4. Create a AAA vserver, LDAP authentication and negotiate and session policies for authentication of requests at NetS-caler and performing Kerberos impersonation/KCD (Kerberos Constrained Delegation) to the backend ADFS server.

For more information, refer to the deployment guide for the Citrix ADC ADFS proxy.

Packet flow

Packet flow for the Citrix ADC as ADFS proxy with internal/external user access:

  1. Internal/external user access to Office 365 is enabled by ADFS.

  2. User is redirected to the applicable federation service for authentication.

  3. User is redirected to the enterprise’s internal federation service.

  4. Internal user is load balanced to the ADFS farm.

  5. External user connects to Citrix ADC AAA-TM logon page.

  6. User is authenticated against Active Directory or similar authentication service.

  7. Post authentication, Citrix ADC does SSO (Kerberos/NTLM) to the ADFS farm.

  8. ADFS server validates SSO credentials and returns STS token.

  9. External user connects to the federation service where the token and claims are verified.

  10. Based on validation, the federation service provides the user with a new security token.

  11. External user provides authorization cookie with security token to the resource for access.

Benefits of using Citrix ADC as an ADFS proxy

  1. Caters to both load balancing and ADFS proxy needs

  2. Works with both internal and external user access scenarios

  3. Supports several methods for pre-authentication and enables multi-factor authentication

  4. Provides an SSO experience for end users

  5. Supports both active and passive protocols
    • Examples of active protocol apps – Outlook, Lync
  6. Examples of passive protocol apps – Outlook web app, browsers

  7. Citrix ADC is a hardened device for DMZ-based deployment

  8. Adds value with additional core ADC features
    • Content Switching
    • SSL offload
    • Rewrite
    • Responder
    • Rate Limit
    • Security (AAA-TM, Gateway, Application Firewall)