Deploying NetScaler as an ADFS Proxy vs Deploying NLBs with ADFS Proxy (WAPs) vs ADFS with SQL Server Merge Replication
Enabling seamless authentication for Office 365 use cases
Recently, more enterprises are migrating to a cloud-based application deployment model such as Microsoft Office 365.
When migrating to the cloud, enterprises want to ensure the user experience does not change. However, seamless access to services hosted outside the enterprise data center requires a new component in app deployment design. No one wants the Active Directory password to travel on the wire outside the data center. Therefore, federation becomes a natural and proven alternative. Referring to primarily to Microsoft services, Active Directory Federation Services (ADFS) is the solution you are looking for. The ADFS security token service extends the single sign-on, (SSO) experience for Active Directory-authenticated clients to resources outside the enterprise data center.
ADFS Proxy Deployment
Packet flow of how the ADFS proxy helps with external user access:
- External user accesses internal or external applications enabled by ADFS.
- User is redirected to the applicable federation service for authentication.
- User is redirected to the enterprise’s internal federation service.
- User is connected to the ADFS proxy in the DMZ and is presented with a sign-on page.
- ADFS proxy takes inputs from the external user and connects to the ADFS farm.
- ADFS proxy presents external user credentials to the ADFS farm.
- ADFS server authenticates the external user with enterprise Active Directory.
- ADFS server returns authorization cookie with a signed security token and claims.
- ADFS proxy sends the token and claim information to external user.
- User connects to the federation service where the token and claims are verified.
- Based on validation, the federation service provides the user with a new security token.
- The external user provides the new authorization cookie with security token to the resource for access.
Microsoft recommendations for 3rd party ADFS proxies
Deployment scenario and access flow with NetScaler as ADFS proxy
If you are using the NetScaler ADC for load balancing of your ADFS proxy farm and other key services, only one additional step is needed to set up NetScaler as a replacement for the ADFS proxy farm. This means NetScaler does not just play the ADC role, but also assumes ownership of the processes performed by the ADFS proxy for external user access scenario. NetScaler is a proven remote access solution for the DMZ. NetScaler can use the AAA for Traffic Management (AAA-TM) feature of NetScaler to fulfill the ADFS proxy use case while other product security features add to the overall value of this solution.
Packet flow of how NetScaler as ADFS proxy helps with internal/external user access:
- Internal/external user access to Office 365 application is enabled by ADFS.
- User is redirected to the applicable federation service for authentication.
- User is redirected to the enterprise’s internal federation service.
- Internal user is load balanced to the ADFS farm.
- External user connects to NetScaler AAA-TM logon page.
- User is authenticated against Active Directory or similar authentication service.
- Post authentication, NetScaler does SSO (Kerberos/NTLM) to the ADFS farm.
- ADFS server validates SSO credentials and returns STS token.
- External user connects to the federation service where the token and claims are verified.
- Based on validation, the federation service provides the user with a new security token.
- External user provides authorization cookie with security token to the resource for access.
Here both internal and external users can go through the NetScaler path with the only difference being that external users are required to pre-authenticate with the NetScaler AAA-TM module. For this access scenario, the AAA-TM vserver must be set up on NetScaler for pre-authentication. Internal users can be directly load balanced to the ADFS server farm
Benefits of using NetScaler as ADFS proxy
- Caters to both load balancing and ADFS proxy needs
- Works with both internal and external user access scenarios
- Supports rich methods for pre-authentication and enables multi-factor authentication
- Provides an SSO experience for end users
- Supports both active and passive protocols a. Examples of active protocol apps — Outlook, Lync b. Examples of passive protocol apps — Outlook web app, browsers
- Hardened device for DMZ-based deployment
- Adds value with additional core ADC features
- Content Switching
- SSL offload
- Rewrite
- Responder
- Rate Limit
- Security
Note that for active protocol-based scenarios, users connect to Office 365 and provide their credentials. Microsoft Federation Gateway contacts the ADFS service on behalf of the active protocol client and submits their credentials. Post authentication, the ADFS service provides Federation Gateway with a token, which in turn is submitted to Office 365 to provide client access. For active protocol-based use cases, clients typically authenticate on NetScaler using 401 NTLM. The configuration guide describes how to set up NetScaler for both active and passive protocol-based use cases.For more details and configuration guide
Deploying NLBs with ADFS Proxy (WAP)
In most use cases you will run ADFS and the ADFS proxy farm, which would require load balancing and scale with high availability.
DNS record for ADFS farm is resolving Load Balancer for ADFS requests.In an ADFS farm, from a client connecting point of view, each server is identical — when they are connected to through a load balancing mechanism. In this case, two servers (primary and secondary) should have the Load Balancer receiving the initial ADFS requests, and then it will forward requests to either of the ADFS servers.
As far as the primary and secondary goes this is only for the configuration side of things, when using WID as the backend database.
The ADFS proxy uses the same principle for load balancing as the ADFS servers. The Load Balancer should be configured to listen for requests coming in from the internet. It then load balances requests to each of the ADFS proxy servers. The proxy servers will then forward requests to the Load Balancer again, this time listening for ADFS server requests. It will then load balance requests to each of the ADFS servers.
Federation Server Farm Using WID and Proxies
Web Application Proxy does not include integrated load-balancing functionality. If you plan to deploy multiple Web Application Proxy servers, you should consider deploying a load-balancer to ensure that the external traffic is distributed evenly between Web Application Proxy servers. You can use any hardware or software load-balancer that supports HTTP and HTTPS, including Windows Network Load Balancing.
You can also configure a load-balancer for published web applications. That is, you can deploy a load-balancer between the Web Application Proxy servers and the published web application. You can use any hardware or software load-balancer that supports HTTP and HTTPS, including Windows Network Load Balancing.
To deploy this topology, in addition to two web application proxies, you must make sure that your perimeter network can also provide access to a Domain Name System (DNS) server and to a second Network Load Balancing (NLB) host. The second NLB host must be configured with an NLB cluster that uses an Internet-accessible cluster IP address, and it must use the same cluster DNS name setting as the previous NLB cluster configured on the corporate network (fs.fabrikam.com). The web application proxies should also be configured with Internet-accessible IP addresses.
Illustration above shows the existing federation server farm with WID topology how the fictional Fabrikam, Inc., company provides access to a perimeter DNS server, adds a second NLB host with the same cluster DNS name (fs.fabrikam.com), and adds two web application proxies (wap1 and wap2) to the perimeter network.
Federation Server Farm Using WID
The default topology for Active Directory Federation Services (ADFS) is a federation server farm, using the Windows Internal Database (WID). In this topology, ADFS uses WID as the store for the ADFS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.
The act of creating the first federation server in a farm also creates a new Federation Service. When you use WID for the AD FS configuration database, the first federation server that you create in the farm is referred to as the primary federation server. This means that this computer is configured with a read/write copy of the AD FS configuration database.
All other federation servers that you configure for this farm are referred to as secondary federation servers because they must replicate any changes that are made on the primary federation server to the read-only copies of the AD FS configuration database that they store locally.
The built-in ADFS farm replication will ensure the ADFS configuration is replicated between all servers in the farm every 5 minutes by default.
Plan on placing all of the federation servers in your corporate network behind a Network Load Balancing (NLB) hosts that can be configured for an NLB cluster with a dedicated cluster Domain Name System (DNS) name and cluster IP address.
This cluster DNS name must match the Federation Service name, for example, fs.fabrikam.com
The NLB host can use the settings that are defined in this NLB cluster to allocate client requests to the individual federation servers. The illustration above shows how the fictional Fabrikam, Inc., company sets up the first phase of its deployment using a two-computer federation server farm (fs1 and fs2) with WID and the positioning of a DNS server and NLB host that is wired to the corporate network.
Federation Server Farm Using SQL Server
This topology for Active Directory Federation Services (AD FS) differs from the federation server farm using Windows Internal Database (WID) deployment topology in that it does not replicate the data to each federation server in the farm. Instead, all federation servers in the farm can read and write data into a common database that is stored on a server running Microsoft SQL Server that is located in the corporate network.
AlwaysOn Availability groups were introduced in SQL Server 2012 and provide a new way to create a high availability SQL Server instance. AlwaysOn Availability groups combine elements of clustering and database mirroring for redundancy and failover at both the SQL instance layer and the database layer. Unlike previous high availability options, AlwaysOn Availability groups do not require a common storage (or storage area network) at the database layer.
An availability group is comprised of a primary replica (a set of read-write primary databases) and one to four availability replicas (sets of corresponding secondary databases). The availability group supports a single read-write copy (the primary replica), and one to four read-only availability replicas. Each availability replica must reside on a different node of a single Windows Server Failover Clustering (WSFC) cluster.
From the perspective of the nodes of an AD FS SQL Server farm, the AlwaysOn Availability group replaces the single SQL Server instance as the policy / artifact database. The availability group listener is what the client (the AD FS security token service) uses to connect to SQL.
The following diagram shows an AD FS SQL Server Farm with AlwaysOn Availability group.
If you plan to use AlwaysOn Availability groups in combination with SQL Server merge replication, please take note of the issues described under “Key Deployment Considerations for using AD FS with SQL Server Merge Replication” at Microsoft Technet site. In particular, when an AlwaysOn availability group containing a database that is a replication subscriber fails over, the replication subscription fails. To resume replication, a replication administrator must manually reconfigure the subscriber.
SQL Server Merge Replication
SQL Server merge replication allows for AD FS policy data redundancy with the following characteristics:
- Read and write capability on all nodes (not just the primary)
- Smaller amounts of data replicated asynchronously to avoid introducing latency to the system
The following diagram shows a geographically redundant AD FS SQL Server farms with merge replication (1 publisher, 2 subscribers):
Key Deployment Considerations for using AD FS with SQL Server Merge Replication (note numbers in the diagram above)
- The distributor database is not supported for use with AlwaysOn Availability Groups or database mirroring. See SQL Server support statements for AlwaysOn Availability groups with replication options at Replication, Change Tracking, Change Data Capture, and AlwaysOn Availability Groups (SQL Server).
- When an AlwaysOn availability group containing a database that is a replication subscriber fails over, the replication subscription fails. To resume replication, a replication administrator must manually reconfigure the subscriber. See the SQL Server description of specific issue at Replication Subscribers and AlwaysOn Availability Groups (SQL Server) and overall support statements for AlwaysOn Availability groups with replication options Replication, Change Tracking, Change Data Capture, and AlwaysOn Availability Groups (SQL Server).
For more detailed instructions on how to configure AD FS to use a SQL Server merge replication, see Setup Geographic Redundancy with SQL Server Replication.
Sources:
https://technet.microsoft.com/en-us/library/dn383650(v=ws.11).aspx
https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/design/ad-fs-design-guide
