Section 1: Overview 3 NetScaler Summary 3 NetScaler AAA-TM Module 3 Traffi c Management 3 Unifi ed Gateway 3 Authentication Overview: 4 Password Changes 5 One Public IP for AAA-TM Deployments on NetScaler 6 Limitations and Usage Guidelines 6 SAML 2.0 SaaS Applications 7 Why SAML? 7 ADFS Hybrid Cloud Integration 8 ADFS Proxy Mode 8 ADFS IDP Mode 9 NetScaler Multi-Factor (nFactor) Authentication 9 Customer Enterprise Applications 10

Section 2: Confi guration Steps 11 Unifi ed Gateway for Hosted Windows Applications 11 NetScaler Gateway deployed in the secure network 11 SAML Identity Provider (IdP) Mode 12 Note: 12 Note: 13 ADFS Proxy Mode Confi guration 14 Citrix NetScaler is an all-in-one application delivery controller that makes applications run up to fi ve 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 traffi c management • Proven application acceleration such as HTTP compression and caching • An integrated application fi rewall for application security • Server offl oading to signifi cantly reduce costs and consolidate servers

As an undisputed leader of service and application delivery, Citrix NetScaler is deployed in thousands of networks around the world to optimize, secure and control the delivery of all enterprise and cloud services. Deployed di- rectly in front of web and database servers, NetScaler combines high-speed load balancing and content switch- ing, http compression, content caching, SSL acceleration, application fl ow visibility and a powerful application fi rewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplifi ed with end-to-end monitoring that transforms network data into actionable business intelligence. NetScaler allows policies to be defi ned and managed using a simple declarative policy engine with no programming expertise required.

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 NetScaler ADC to verify the client's credentials, either locally or with a third-party authentication server, and allow 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.

Enterprises can now achieve federation and single sign-on across enterprise, Web, SaaS and on-premises virtual applications and desktops via NetScaler Unifi ed Gateway. NetScaler Unifi ed 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 NetScaler today for their XenApp and Xen Desktop 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 NetScaler Unifi ed Gateway.

All existing authentication mechanisms that work with NetScaler Gateway work with Unifi ed Gateway. These include LDAP, RADIUS, SAML, Kerberos, Certifi cate based Authentication, and so on. All existing authentication mechanisms that work with NetScaler Gateway work with Unifi ed Gateway. These include LDAP, RADIUS, SAML, Kerberos, Certifi cate based Authentication, and so on.

Whatever authentication mechanism is confi gured on NetScaler Gateway virtual server before the upgrade is used automatically used when the NetScaler Gateway virtual server is placed behind the Unifi ed Gateway virtual server.

There are no additional confi guration steps involved, other than assigning a non-addressable IP address (0.0.0.0) to NetScaler Gateway virtual server.

To understand how AAA works in a distributed environment, consider an organization with an intranet that its employees access in the offi ce, at home, and when traveling. The content on the intranet is confi dential 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:

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

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

o Verifi es that the user is authorized to access specifi c intranet content before delivering the user's request to the application server.

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

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

Authentication requires that several entities: the client, the NetScaler 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 confi guration of your protected application servers. AAA-TM handles password changes for users by using the protocol-specifi c 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 authen- ticated 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 indicat- ed domain administration server, authenticates to that server, and performs the password change on that server.

Note:

When confi guring AAA-TM with an LDAP authentication server, the system administrator must keep the following con- ditions and limitations in mind:

o AAA-TM assumes that the domain administration server in the referral accepts the same bind credentials as the original server. o AAA-TM only follows LDAP referrals for password change operations. In other cases AAA-TM refuses to follow the referral. o 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 fi le on the appliance or to a syslog server. Auditing requires confi g- uring the appliance and any syslog server that you use.

Authentication Matrix

NetScaler supports AAA framework for Traffi c 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.

NetScaler 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 certifi cate. This is depicted in the following diagram:

Windows Hosted Applications by XenApp and XenDesktop

You can deploy NetScaler 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 re- mote users must connect to NetScaler Gateway before they can access any resources in the internal network. NetScaler Gateway is most commonly installed in the following locations in a network:

o In the network DMZ o In a secure network that does not have a DMZ

You can also deploy NetScaler Gateway with XenApp, XenDesktop, StoreFront, and XenMobile Server to allow users to ac- cess their Windows, web, mobile, and SaaS applications.

If your deployment includes XenApp, StoreFront, or XenDesktop 7, you can deploy NetScaler Gateway in a single-hop or double-hop DMZ confi guration. A double-hop deployment is not supported with earlier versions of XenDesktop or XenMo- bile App Edition.

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

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:

o LargeProvider must ensure security of user data. o 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. o 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:

o LargeProvider does not have to maintain a database for BigCompany users. Freed from identity management, Large Provider can concentrate on providing better services. o BigCompany does not bear the burden of making sure the LargeProvider user database is kept in sync with its own user database. o 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 NetScaler appliance can be deployed as a SAML Service Provider (SP) and a SAML Identity Provider (IdP). Read through the relevant topics to understand the confi gurations that must be performed on the NetScaler appliance.

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 part- ners, 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 Ac- tive 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.

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 user is 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 Inter- net, it is a best practice to use an AD FS 2.0 Proxy. https://blogs.technet.microsoft.com/askds/2012/01/05/understanding-the-ad-fs-2-0-proxy/ The federated partner's Identity Provider (IP) sends claims that refl ect its users' identity, groups, and attribute data. There- fore, your organization no longer needs to revoke, change, or reset the credentials for the partner's users, since the creden- tials 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. Confi guring as the identity provider enables reusing existing accounts managed by existing Active Directory objects for au- thentication. 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. https://msdn.microsoft.com/en-us/library/bb897402.aspx

nFactor gives a fresh perspective to authentication, streamlines the authentication fl ow and provides great fl exibility during authentication

Multi-factor authentication enhances the security of an application by requiring users to provide multiple proofs of identify to gain access. The NetScaler appliance provides an extensible and fl exible approach to confi guring multi-factor authentica- tion. This approach is called nFactor authentication. With nFactor authentication you can:

o Confi gure any number of authentication factors.

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

o 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.

o Confi gure pass-through for an authentication factor. This means that no explicit login interaction is required for that factor.

o Confi gure the order in which different types of authentication are applied. Any of the authentication mechanisms that are supported on the NetScaler appliance can be confi gured as any factor of the nFactor authentication setup.

These factors are executed in the order in which they are confi gured.

o Confi gure the NetScaler to proceed to an authentication factor that must be executed when authentication fails.

To do so, you confi gure 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 confi gure the next factor, which must specify the alternative authentication mechanism to apply. 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 a variety of locations and using a variety of 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 impact- ed with this approach.

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

Host Profi ling: NetScaler supports endpoint analysis (EPA) feature which is used for host profi le checks. EPA can be used to grant quarantined access in case user is not meeting security checks necessary for full access.

Compliance Auditing: NetScaler supports a wide range of auditing mechanisms like Appfl ow, Syslog and user-defi ned log- ging. Section 2: Confi guration Steps

Unifi ed Gateway for Hosted Windows Applications

Network Architecture(s)

When you deploy NetScaler Gateway in the DMZ, user connections must traverse the fi rst fi rewall to connect to NetScaler 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 fi rst fi rewall.

NetScaler 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 fi rewall. The ports that must be open through the second fi rewall 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 fi rewall. NetScaler Gateway establishes the connection through the second fi rewall to the HTTP server on the internal network on behalf of the external user devices.

When you deploy NetScaler Gateway in the secure network, connect one interface on NetScaler Gateway to the Internet and the other interface to servers running in the secure network. Putting NetScaler Gateway in the secure network provides access for local and remote users. Because this confi guration only has one fi rewall, however, makes the deployment less secure for users connecting from a remote location. Although NetScaler Gateway intercepts traffi c from the Internet, the traffi c enters the secure network before users are authenticated. When NetScaler Gateway is deployed in a DMZ, users are authen- ticated before network traffi c reaches the secure network.

When NetScaler Gateway is deployed in the secure network, NetScaler Gateway Plug-in connections must traverse the fi rewall to connect to NetScaler 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 fi rewall.

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 cre- dentials 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 NetScaler appliance is confi gured as an IdP, all requests are received by an authentication virtual server that is associated with the relevant SAML IdP profi le.

A NetScaler appliance can be used as a IdP in a deploymsent where the SAML SP is confi gured either on the appliance or on any external SAML SP.

When used as a SAML IdP, a NetScaler appliance:

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

o Digitally signs assertions. Support for the SHA256 algorithm is introduced in NetScaler 11.0 Build 55.x.

o Supports single-factor and two-factor authentication. SAML must not be confi gured as the secondary authentica tion mechanism.

o Can encrypt assertions by using the public key of the SAML SP. This is recommended when the assertion includes sensitive information. Support introduced in NetScaler 11.0 Build 55.x. o Can be confi gured to accept only digitally signed requests from the SAML SP. Support introduced in NetScaler 11.0 Build 55.x o Can log on to the SAML IdP by using the following 401-based authentication mechanisms: Negotiate, NTLM, and Certifi cate. Support introduced in NetScaler 11.0 Build 55.x. o Can be confi gured 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 profi le. Support introduced in NetScaler 11.0 Build 55.x. o If the NetScaler appliance is confi gured 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 NetScaler appliance creates a session cookie for the fi rst authentication, and every subsequent request uses this cookie for authentication. Support introduced in NetScaler 11.0 Build 55.x. o Can send multi-valued attributes in a SAML assertion. Support introduced in NetScaler 11.0 Build 64.x. o Supports post and redirect bindings. Support for redirect bindings is introduced in NetScaler 11.0 Build 64.x. o Can specify the validity of a SAML assertion. If the system time on NetScaler 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 confi gure the time duration for which the assertions will be valid. This duration, called the "skew time," specifi es the number of minutes for which the message should be accepted. The skew time can be confi gured on the SAML SP and the SAML IdP.

Support introduced in NetScaler 11.0 Build 64.x.

o Can be confi gured to serve assertions only to SAML SPs that are pre-confi gured on or trusted by the IdP. For this con fi guration, the SAML IdP must have the service provider ID (or issuer name) of the relevant SAML SPs. Support intro duced in NetScaler 11.0 Build 64.x. Confi guration

To setup NetScaler as an ADFS proxy, the following features must be enabled in your NetScaler system - Load Balancing, Content Switching, SSL Offl oading. Confi guring the NetScaler as an ADFS proxy involves the following steps:

1. Setup 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 NetScaler ADFS proxy at https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/guide-to-deploying-netscaler-as-an-ac- tive-directory-federation-services-proxy.pdf

Packet Flow

Packet fl ow for the NetScaler as ADFS proxy with internal/external user access: 1. Internal/external user access to Offi ce 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 NetScaler AAA-TM logon page. 6. User is authenticated against Active Directory or similar authentication service. 7. Post authentication, NetScaler 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 verifi ed. 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. Benefi ts of using NetScaler 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. NetScaler is a hardened device for DMZ-based deployment 8. Adds value with additional core ADC features • Content Switching • SSL offl oad • Rewrite • Responder • Rate Limit • Security (AAA-TM, Gateway, Application Firewall) About Citrix

Citrix (NASDAQ:CTXS) is a leader in mobile workspaces, providing virtualization, mobility management, network- ing and cloud services to enable new ways to work better. Citrix solutions power business mobility through secure, personal workspaces that provide people with instant access to apps, desktops, data and communications on any device, over any network and cloud. This year Citrix is celebrating 25 years of innovation, making IT simpler and people more productive. With annual revenue in 2013 of $2.9 billion, Citrix solutions are in use at more than 330,000 organizations and by over 100 million users globally. Learn more at www.citrix.com.

Copyright © 2014 Citrix Systems, Inc. All rights reserved. Citrix, NetScaler MPX, NetScaler SDX, NetScaler, CloudBridge and AppFlow are trademarks of Citrix Systems, Inc. and/or one of its subsidiaries, and may be registered in the U.S. and other countries. Other product and company names mentioned herein may be trademarks of their respective companies.