Menu
Web Application Proxy and AD FS on AWS
Web Application Proxy and AD FS Quick Start

Design Considerations

This Quick Start is designed for a highly available AD FS implementation that supports 1,000 to 15,000 users, but there are a number of options available for architecting an AD FS deployment. Here are Microsoft's recommendations for determining the minimum number of servers to deploy:

  • Fewer than 1,000 users – A small environment can use existing infrastructure instead of running dedicated AD FS servers. If you need to support fewer than 1,000 users, you can install AD FS on at least two of your domain controllers. Ideally, these domain controllers should be in two separate Availability Zones.

  • 1,000 to 15,000 users – In this scenario, Microsoft recommends using a dedicated AD FS and Web Application Proxy server infrastructure. The AD FS database can run using a Windows Internal Database (WID), so you'll need four servers (two Web Application Proxy, two AD FS) in this architecture, as shown in Figure 1.

  • 15,000 to 60,000 users – For large environments, Microsoft recommends using three to five dedicated AD FS servers, and at least two dedicated Web Application Proxy servers. Note that if you're scaling beyond five dedicated AD FS servers, you'll need a dedicated SQL Server instance instead of running a WID.

These recommendations are based on a hardware profile that supports 8 CPU cores, 4 GiB of RAM, and a 1 gigabit network connection.

Selecting an Instance Type

AD FS is considered a processor-bound workload, meaning that CPU resources are the highest in demand. This Quick Start uses C4 compute-optimized instances by default.

Specifically, the c4.2xlarge instance type is used to provide 8 vCPUs and 15 GiB of memory to meet or exceed requirements, based on the recommendations in the previous section. Additionally, the c4.2xlarge instance type supports Amazon EBS optimization, enhanced networking, and high network performance, which results in higher packets per second, lower latency, and lower jitter. Although c4.2xlarge provides more memory than required, it's a great candidate for workloads running in a production environment.

Database Options

The recommended topology for AD FS is to create a federation server farm that includes at least two AD FS servers. When you install AD FS on the first server, the federation server farm is created. You can join the next server to the farm, and then load balance those servers.

An AD FS federation server farm uses a database to hold configuration data. For farms with five or fewer servers, you can use a Windows Internal Database (WID). The primary AD FS server will have a read/write copy of this database. The secondary AD FS servers in the farm receive updates from the primary server to a read-only copy of the WID. If the primary AD FS server fails, the secondary server can still process authentication requests, but you cannot make configuration changes until either the primary server is brought back online or the secondary server is converted to primary.

For federation server farms that have more than five AD FS servers, you'll need to use a SQL Server database for the configuration database. When you use SQL Server for your AD FS database, all members in the federation server farm have write access to the configuration data.

Microsoft recommends that you use WID until you scale past five AD FS servers. This Quick Start utilizes WID with AD FS by default.

Load Balancing

For production deployments, you should implement load balancing to make your Web Application Proxy and AD FS services highly available. You can use Elastic Load Balancing or a third-party virtual load balancer appliance.

Both the Web Application Proxy and AD FS layers can be load balanced individually with Elastic Load Balancing. You can deploy an Internet-facing load balancer for the Web Application Proxy layer that will service users accessing published web applications over the Internet. In addition, you can configure an internal load balancer for the AD FS servers. You would then configure the Web Application Proxy layer to point to the load-balanced DNS name (e.g., sts.example.com) that resolves to the internal load balancer.

Certificates

Certificates are required to install both the Web Application Proxy and AD FS components. This Quick Start automates the deployment and installation of these components by using certificates issued from an internal enterprise certificate authority (CA), which runs on the domain controller infrastructure. You can replace these certificates in your own production deployments. The requirements and recommendations for both the Web Application Proxy and AD FS layers are discussed in the next two sections.

Web Application Proxy Certificates

  • Issuing CA – Typically, the Web Application Proxy infrastructure will use certificates issued from a commercial or public CA, such as DigiCert or Verisign, which should be installed in the computer's personal certificate store. Using a public CA generally prevents you from having to install root certificates on your client devices. You can use your own public key infrastructure (PKI) to issue the Web Application Proxy certificates, but you'll need to ensure that client devices trust the issuing CA, which typically involves installing the root certificate on the devices as well as making the URL of your certificate revocation list externally accessible.

  • Certificate FQDNs – You can explicitly set the certificate subject and subject alternative name (SAN) fields, or you can choose to use a wildcard certificate (e.g., *.example.com). For explicit naming, you'll need to set the subject field to the AD FS federation service name (e.g., sts.example.com). If you plan to use the Workplace Join feature, you'll also need two SAN entries: one for the federation service name (e.g., sts.example.com) and one for enterprise registration in the format enterpriseregistration.yourdomain.com. Additionally, you'll want SAN entries for any fully qualified domain name (FQDN) that you will be publishing, such as externally facing SharePoint sites, OWA, etc.

AD FS Certificates

  • Issuing CA – Typically, the AD FS infrastructure will use certificates issued from an internal PKI, such as an enterprise Active Directory CA, because the servers in the infrastructure are not Internet facing. This is especially useful in an Active Directory domain environment where all domain-joined machines will trust the issuing CA by default. If you choose not to domain-join your Web Application Proxy servers, you can install the CA root certificate on those servers in the computer's trusted root certificate authority store. If you do not have an existing PKI implementation, it's probably easiest to use the same public certificate on both the Web Application Proxy and AD FS servers.

  • Certificate FQDNs – The AD FS certificate requires the federation service name to be set on the subject field (e.g., sts.example.com), or you can use a wildcard certificate.

Domain-Joined Proxies

You may choose not to domain-join your Web Application Proxy servers, because they will be placed in public virtual private cloud (VPC) subnets. This is a typical practice for server workloads running in a demilitarized zone (DMZ). However, if the web application you want to publish through Web Application Proxy must support Integrated Windows authentication, you should domain-join the Web Application Proxy server.

This Quick Start automatically joins the Web Application Proxy servers to the Active Directory Domain Services environment. See the appendix for an example of how to publish a web application that uses Integrated Windows authentication.

Authentication Scenarios

Publishing web applications with Web Application Proxy supports three authentication scenarios:

  • AD FS pre-authentication – In this scenario, users authenticate against AD FS before gaining access to the published web application. This requires that you add an AD FS relying party trust to the federation service. For detailed coverage on AD FS pre-authentication flow, see Publish Applications using AD FS Preauthentication in the Microsoft TechNet Library.

  • Client certificate pre-authentication – In this scenario, one or more external servers connect to an on-premises web application through the Web Application Proxy infrastructure using a certificate for authentication. Despite the name, this scenario should not be used for client devices that connect to a published web application. For more information, see Publish Applications using Client Certificate Preauthentication in the Microsoft TechNet Library.

  • Pass-through pre-authentication – In this scenario, access to the web application is proxied directly to the back-end server without pre-authentication against AD FS. For example, this is the option you would use to make AD FS externally accessible. Subsequently published applications that use AD FS pre-authentication will access AD FS via pass-through pre-authentication.

See the appendix for an example that covers both AD FS and pass-through pre-authentication.