In order to ensure the deployed servers' operating systems and installed applications have the latest Microsoft updates, run Windows Update on each server.

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.

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.

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

Both the WAP and AD FS layers can be load balanced individually with Elastic Load Balancing. You can deploy an Internet-facing load balancer for the WAP 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 WAP layer to point to the load-balanced DNS name (for example, sts.example.com) that resolves to the internal load balancer.

To take advantage of header inspection, it is recommended that Application Load Balancers (rather than Network Load Balancers or Classic Load Balancers) be deployed. You should configure the internet-facing load balancer for the WAP layer to accept HTTPS requests on port 443 and to forward requests to the WAP servers. You must assign a certificate obtained from a trusted third-party CA to the listener for the internet-facing load balancer. For listener of the internal load balancer, also configured to accept HTTPS requests on port 443, you can assign an internally-signed certificate.

For detailed load-balancing and health-check requirements, refer to AD FS Requirements.

Certificates are required to install both the WAP and AD FS components. This Quick Start automates the deployment and installation of these components by using certificates issued from an internal enterprise 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 WAP and AD FS layers are discussed in the next two sections.

As your WAP servers are deployed to public subnets, you may choose not to join them to a domain. This is a typical practice for server workloads running in a perimeter zone. However, if the web application you want to publish must support Integrated Windows authentication, you should join the WAP servers.

This Quick Start automatically joins the WAP servers to the Active Directory Domain Services environment. For help publishing a web application that uses Integrated Windows authentication, refer to Publish Outlook on the web with AD FS preauthentication, later in this guide.

Publishing web applications with WAP supports three authentication scenarios:

For an example that covers both AD FS and pass-through preauthentication, refer to Publish Outlook on the web with AD FS preauthentication, later in this guide.

All the Windows Servers deployed by this Quick Start are domain-joined. You can authenticate to these instances by using the stackadmin@example.com domain administrator account. You can specify the password for this account as you launch the stack. You can retrieve the local administrator password for domain-joined instances by using the KeyPairName parameter specified during the launch. Operating system patches are your responsibility and should be performed on a periodic basis.

A security group acts as a firewall that controls the traffic for one or more instances. When you launch an instance, you associate one or more security groups with the instance. You add rules to each security group that allow traffic to or from its associated instances. You can modify the rules for a security group at any time. The new rules are automatically applied to all instances that are associated with the security group.

The security groups created and assigned to the individual instances as part of this solution are restricted as much as possible while allowing access to the various functions needed by AD FS and WAP. After deployment, review security groups and further restrict access as needed.

Establish an RDP connection to the WAP1 server. In Control Panel, choose Administrative Tools, and then launch the Remote Access Management snap-in.

To publish OWA to the internet, you’ll need to create two rules. The first rule will be a pass-through authentication rule to the AD FS server. This will allow users to pre-authenticate before being connected to OWA.

Now you are ready to test accessing OWA from an external workstation or server over the internet.