Web Application Proxy and AD FS on the AWS Cloud

Quick Start Reference Deployment

QS

September 2020
AWS Quick Start Reference Team

Visit our GitHub repository for source files and to post feedback, report bugs, or submit feature ideas for this Quick Start.

This Quick Start was created by Amazon Web Services (AWS). Quick Starts are automated reference deployments that use AWS CloudFormation templates to deploy key technologies on AWS, following AWS best practices.

Overview

This Quick Start reference deployment guide discusses architectural considerations and configuration steps for deploying a Web Application Proxy and Active Directory Federation Services (AD FS) environment on the Amazon Web Services (AWS) Cloud. It also provides links for viewing and launching AWS CloudFormation templates that automate the deployment.

The guide is for IT infrastructure architects, administrators, and DevOps professionals who are planning to implement or extend their Web Application Proxy and AD FS workloads on the AWS Cloud.

Web Application Proxy and AD FS on AWS

Microsoft Active Directory Federation Services (AD FS) is a Windows Server role that provides identity federation and single sign-on (SSO) capabilities for users accessing applications in an AD FS-secured environment, or with federated partner organizations. Put simply, AD FS authenticates users and provides security tokens to applications or federated partner applications that trust AD FS.

For example, you could implement identity federation with AWS Identity and Access Management (IAM) and AD FS, and then use your Active Directory user name and password (instead of the AWS root account or IAM user credentials) to sign in to the AWS Management Console, or to make calls to AWS APIs.

Like domain controllers and other internal server workloads, AD FS servers are deployed in a private virtual private cloud (VPC) subnet. In order to make AD FS accessible to external users, you can deploy the Web Application Proxy role on Windows Server 2012 R2. The Web Application Proxy server can proxy requests to the AD FS infrastructure for users who are connecting from an external location, without the need for VPN connectivity.

You can also use Web Application Proxy to selectively publish and pre-authenticate connections to internal web applications, allowing external users outside your organization to access those applications over the internet.

In this guide, we’ll take a look at using your own Active Directory Domain Services (AD DS) infrastructure in AWS, along with AD FS and Web Application Proxy, to provide seamless external access to web applications running in AWS.

Some of the benefits and features of publishing applications with Web Application Proxy and AD FS are:

  • Network isolation – Publishing web applications through Web Application Proxy means that back-end servers are never directly exposed to the internet. You can publish popular web-based workloads such as Microsoft SharePoint, Outlook Web App (OWA), Exchange ActiveSync, Lync (Skype for Business), and even custom web applications through Web Application Proxy.

  • Denial-of-service (DoS) protection – The Web Application Proxy infrastructure uses several mechanisms to implement basic DoS protection, such as throttling and queuing, before routing connections to back-end web applications.

  • Multi-factor authentication – Pre-authentication with AD FS provides support for smart cards, device authentication, and more.

  • Single sign-on (SSO) – This functionality provides users with seamless access to applications without re-prompting for credentials after initial authentication.

  • Workplace Join - Users can connect devices that are not typically domain-joined, such as personal laptops, tablets, and smartphones, to their company’s resources. Known devices can be granted conditional access to applications, and you can require that devices register before gaining access to published applications.

For further details, see Planning to Publish Applications Using Web Application Proxy on Microsoft TechNet.

This guide and associated AWS CloudFormation template can be used in conjunction with other AWS Quick Starts to securely publish web applications running on SharePoint, Exchange, Lync, or your own web-based applications. The infrastructure deployed by this Quick Start enables external users to pre-authenticate to AD FS to access these web applications, without exposing the applications or AD FS infrastructure directly to the internet. You can also use this infrastructure to enable federation with AWS.

AWS costs

You are responsible for the cost of the AWS services and any paid third-party licenses used while running this Quick Start. There is no additional cost for using the Quick Start.

The AWS CloudFormation templates for Quick Starts include configuration parameters that you can customize. Some of the settings, such as the instance type, affect the cost of deployment. For cost estimates, see the pricing pages for each AWS service you use. Prices are subject to change.

After you deploy the Quick Start, create AWS Cost and Usage Reports to deliver billing metrics to an Amazon Simple Storage Service (Amazon S3) bucket in your account. These reports provide cost estimates based on usage throughout each month and aggregate the data at the end of the month. For more information, see What are AWS Cost and Usage Reports?

Software licenses

This Quick Start deploys AWS EC2 instances running Microsoft Windows, and the cost of the Windows licenses is included in the cost of the EC2 instances. All roles and functionality deployed on top of the Windows instances are included in the cost of the Windows licenses.

Architecture

Deploying this Quick Start for a new virtual private cloud (VPC) with default parameters builds the following Web Application Proxy and AD FS environment in the AWS Cloud.

Architecture
Figure 1. Quick Start architecture for WAP and AD FS on AWS

The AWS CloudFormation template creates a fully functional AD FS federation server farm with Web Application Proxy on the AWS Cloud. The template deploys the following components:

  • A virtual private cloud (VPC) with resources distributed across two Availability Zones for high availability.*

  • Public subnets in each Availability Zone that provide access to and from the internet. The public subnets include network address translation (NAT) gateway instances for outbound internet access, and Remote Desktop Gateway (RD Gateway) instances in an Auto Scaling group for inbound remote administrative access. Web Application Proxy servers are deployed in the public subnets to help provide secure inbound connectivity to web applications.*

  • Private subnets in each Availability Zone for running enterprise workloads such as Active Directory domain controllers and AD FS servers, shielded from direct access over the internet.*

  • In the private subnets, domain controllers that act as enterprise certificate authorities (CAs) that issue the required SSL certificates to the AD FS infrastructure. For production deployments, you might want to consider commercial certificates issued from a public CA, and we’ll cover this in greater detail later in this guide.

  • In the private subnets, two AD FS servers running on Windows Server 2012 R2, which are deployed in each Availability Zone to support high availability and load distribution.

  • Security groups to tightly control the flow of traffic between your Amazon EC2 instances.

*The template that deploys the Quick Start into an existing VPC skips the components marked by asterisks and prompts you for your existing VPC configuration.

Planning the deployment

Specialized knowledge

This deployment requires a moderate level of familiarity with AWS services. If you’re new to AWS, see Getting Started Resource Center and AWS Training and Certification. These sites provide materials for learning how to design, deploy, and operate your infrastructure and applications on the AWS Cloud.

This Quick Start assumes familiarity with Microsoft Active Directory.

AWS account

If you don’t already have an AWS account, create one at https://aws.amazon.com by following the on-screen instructions. Part of the sign-up process involves receiving a phone call and entering a PIN using the phone keypad.

Your AWS account is automatically signed up for all AWS services. You are charged only for the services you use.

Technical requirements

Before you launch the Quick Start, your account must be configured as specified in the following table. Otherwise, deployment might fail.

Resource quotas

If necessary, request service quota increases for the following resources. You might request quota increases to avoid exceeding the default limits for any resources that are shared across multiple deployments. The Service Quotas console displays your usage and quotas for some aspects of some services. For more information, see What is Service Quotas? and AWS service quotas.

Resource This deployment uses

VPCs

1

Elastic IP addresses

1

AWS Identity and Access Management (IAM) security groups

2

IAM roles

2

EC2 instances

5

Supported Regions

This Quick Start is supported in all non-GovCloud AWS Regions

Certain Regions are available on an opt-in basis. For more information, see Managing AWS Regions.

EC2 key pairs

Make sure that at least one Amazon EC2 key pair exists in your AWS account in the Region where you plan to deploy the Quick Start. Make note of the key pair name. You need it during deployment. To create a key pair, see Amazon EC2 key pairs and Linux instances.

For testing or proof-of-concept purposes, we recommend creating a new key pair instead of using one that’s already being used by a production instance.

IAM permissions

Before launching the Quick Start, you must sign in to the AWS Management Console with IAM permissions for the resources that the templates deploy. The AdministratorAccess managed policy within IAM provides sufficient permissions, although your organization may choose to use a custom policy with more restrictions. For more information, see AWS managed policies for job functions.

Prepare for the deployment

If you are deploying the WAP ADFS Quick Start into an existing VPC, ensure your Active Directory environment includes at least one certificate authority (CA). If you are using AWS Managed Microsoft Active Directory this will require you to have at least one domain-joined server that can be configured as the CA, since AWS Managed Microsoft Active Directory does not act as a CA natively. A domain-joined server can be promoted to a CA by executing the following PowerShell code from an elevated command prompt:

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Deployment options

This Quick Start provides two deployment options:

  • Deploy WAP and AD FS into a new VPC (end-to-end deployment). This option builds a new AWS environment consisting of the VPC, subnets, NAT gateways, security groups, bastion hosts, and other infrastructure components. It then deploys WAP and AD FS into this new VPC.

  • Deploy WAP and AD FS into an existing VPC. This option provisions WAP and AD FS in your existing AWS infrastructure.

The Quick Start provides separate templates for these options. It also lets you configure Classless Inter-Domain Routing (CIDR) blocks, instance types, and WAP and AD FS settings, as discussed later in this guide.

Deployment steps

Sign in to your AWS account

  1. Sign in to your AWS account at https://aws.amazon.com with an IAM user role that has the necessary permissions. For details, see Planning the deployment earlier in this guide.

  2. Make sure that your AWS account is configured correctly, as discussed in the Technical requirements section.

Create a key pair in your preferred Region.

To do this, in the navigation pane of the Amazon EC2 console, choose Key Pairs, Create Key Pair, type a name, and then choose Create.

Deploy1
Figure 2. Creating a key pair

Amazon EC2 uses public-key cryptography to encrypt and decrypt login information. To be able to log in to your instances, you must create a key pair. With Windows instances, we use the key pair to obtain the administrator password via the Amazon EC2 console and then log in using Remote Desktop Protocol (RDP) as explained in the step-by-step instructions in the Amazon Elastic Compute Cloud User Guide.

If necessary, request a service limit increase for the Amazon EC2 c4.2xlarge instance type.

To do this, in the AWS Support Center, choose Create Case, Service Limit Increase, EC2 instances, and then complete the fields in the limit increase form, as shown in Figure 4. The current default limit is 20 instances.

+ You might need to request an increase if you already have an existing deployment that uses this instance type, and you think you might exceed the default limit with this reference deployment. It might take a few days for the new service limit to become effective. For more information, see Amazon EC2 Service Limits in the AWS documentation.

Note The Quick Start uses five Elastic IP addresses by default: two for the NAT gateways, two for the proxies, and one for the RD Gateway instance. The default limit for Elastic IP addresses is five per AWS Region. If you’re planning to deploy multiple RD Gateway instances by configuring the Number of RDGW Hosts parameter, we recommend that you also request an increase in the Elastic IP address limit: In the AWS Support Center, choose Create Case, Service Limit Increase, Elastic IPs, and then complete the fields.

Deploy2
Figure 3. Requesting a service limit increase

Launch the Quick Start

You are responsible for the cost of the AWS services used while running this Quick Start reference deployment. There is no additional cost for using this Quick Start. For full details, see the pricing pages for each AWS service used by this Quick Start. Prices are subject to change.
  1. Sign in to your AWS account, and choose one of the following options to launch the AWS CloudFormation template. For help with choosing an option, see deployment options earlier in this guide.

Deploy WAP and AD FS into a new VPC on AWS

View template

Deploy WAP and AD FS into an existing VPC on AWS

View template

If you’re deploying WAP and AD FS into an existing VPC, make sure that your VPC has two private subnets in different Availability Zones for the workload instances, and that the subnets aren’t shared. This Quick Start doesn’t support shared subnets. These subnets require NAT gateways in their route tables, to allow the instances to download packages and software without exposing them to the internet.

Also, make sure that the domain name option in the DHCP options is configured as explained in the Amazon VPC documentation. You provide your VPC settings when you launch the Quick Start.

Each deployment takes about 1 hour and 30 minutes to complete.

  1. Check the AWS Region that’s displayed in the upper-right corner of the navigation bar, and change it if necessary. This is where the network infrastructure for WAP and AD FS will be built. The template is launched in the us-east-1 Region by default.

  1. On the Create stack page, keep the default setting for the template URL, and then choose Next.

  2. On the Specify stack details page, change the stack name if needed. Review the parameters for the template. Provide values for the parameters that require input. For all other parameters, review the default settings and customize them as necessary.

In the following tables, parameters are listed by category and described separately for the deployment options. When you finish reviewing and customizing the parameters, choose Next.

Unless you are customizing the Quick Start templates for your own deployment projects, keep the default settings for the parameters Quick Start S3 bucket name, Quick Start S3 bucket Region, and Quick Start S3 key prefix. Changing these settings automatically updates code references to point to a new Quick Start location. For more information, see the AWS Quick Start Contributor’s Guide.

Launch into a new VPC

Table 1. Network Configuration
Parameter label (name) Default value Description

Availability Zones (AvailabilityZones)

Requires input

List of Availability Zones to use for the subnets in the VPC. Note: The logical order is preserved and only 2 AZs are used for this deployment.

VPC CIDR (VPCCIDR)

10.0.0.0/16

CIDR Block for the VPC

Private Subnet 1 CIDR (PrivateSubnet1CIDR)

10.0.0.0/19

CIDR block for private subnet 1 located in Availability Zone 1.

Private Subnet 2 CIDR (PrivateSubnet2CIDR)

10.0.32.0/19

CIDR block for private subnet 2 located in Availability Zone 2.

Public Subnet 1 CIDR (PublicSubnet1CIDR)

10.0.128.0/20

CIDR Block for the public DMZ subnet 1 located in Availability Zone 1

Public Subnet 2 CIDR (PublicSubnet2CIDR)

10.0.144.0/20

CIDR Block for the public DMZ subnet 2 located in Availability Zone 2

Allowed Remote Desktop Gateway External Access CIDR (RDGWCIDR)

Requires input

Allowed CIDR Block for external access to the Remote Desktop Gateways

Table 2. Amazon EC2 Configuration
Parameter label (name) Default value Description

Key Pair Name (KeyPairName)

Requires input

Public/private key pairs allow you to securely connect to your instance after it launches

Domain Controller 1 Instance Type (ADServer1InstanceType)

m5.large

Amazon EC2 instance type for the first Active Directory instance

Domain Controller 1 NetBIOS Name (ADServer1NetBIOSName)

DC1

NetBIOS name of the first Active Directory server (up to 15 characters)

Domain Controller 1 Private IP Address (ADServer1PrivateIP)

10.0.0.10

Fixed private IP for the first Active Directory server located in Availability Zone 1

Domain Controller 2 Instance Type (ADServer2InstanceType)

m5.large

Amazon EC2 instance type for the second Active Directory instance

Domain Controller 2 NetBIOS Name (ADServer2NetBIOSName)

DC2

NetBIOS name of the second Active Directory server (up to 15 characters)

Domain Controller 2 Private IP Address (ADServer2PrivateIP)

10.0.32.10

Fixed private IP for the second Active Directory server located in Availability Zone 2

Size of the domain controller data drive (DataDriveSizeGiB)

20

Size of Data Drive that contains SYSVOL and NTDS

Remote Desktop Gateway Instance Type (RDGWInstanceType)

t2.large

Amazon EC2 instance type for the Remote Desktop Gateway instances

WAP and ADFS Server Instance Type (WAPADFSInstanceType)

c4.2xlarge

Amazon EC2 instance type for the WAP and ADFS Servers

Table 3. Microsoft Active Directory Configuration
Parameter label (name) Default value Description

Domain DNS Name (DomainDNSName)

example.com

Fully qualified domain name (FQDN) of the forest root domain e.g. example.com

Domain NetBIOS Name (DomainNetBIOSName)

example

NetBIOS name of the domain (up to 15 characters) for users of earlier versions of Windows e.g. EXAMPLE

Domain Admin User Name (DomainAdminUser)

Admin

User name for the account that will be added as Domain Administrator. This is separate from the default "Administrator" account

Domain Admin Password (DomainAdminPassword)

Requires input

Password for the domain admin user. Must be at least 8 characters containing letters, numbers and symbols

Table 4. Microsoft Active Directory Certificate Services Configuration
Parameter label (name) Default value Description

Deploy PKI Infrastructure (PKI)

One-Tier

Do you want to Deploy PKI Infrastructure if so what kind, Two Tier or One Tier

Offline Root CA NetBIOS Name (OrCaServerNetBIOSName)

ORCA1

NetBIOS name of the Offline Root CA server (Only Used For Two Tier PKI) (up to 15 characters)

Enterprise Root CA NetBIOS Name (EntCaServerNetBIOSName)

ENTCA1

NetBIOS name of the Enterprise Root or Subordinate CA server (up to 15 characters)

Table 5. Microsoft Remote Desktop Gateway Configuration
Parameter label (name) Default value Description

Number of RDGW Hosts (NumberOfRDGWHosts)

1

Enter the number of Remote Desktop Gateway hosts to create

Table 6. AWS Quick Start Configuration
Parameter label (name) Default value Description

Quick Start S3 Bucket Name (QSS3BucketName)

aws-quickstart

S3 bucket name for the Quick Start assets. Quick Start bucket name can include numbers, lowercase letters, uppercase letters, and hyphens (-). It cannot start or end with a hyphen (-).

Quick Start S3 bucket region (QSS3BucketRegion)

us-east-1

The AWS Region where the Quick Start S3 bucket (QSS3BucketName) is hosted. When using your own bucket, you must specify this value.

Quick Start S3 Key Prefix (QSS3KeyPrefix)

quickstart-microsoft-wapadfs/

S3 key prefix for the Quick Start assets. Quick Start key prefix can include numbers, lowercase letters, uppercase letters, hyphens (-), and forward slash (/).

Launch into an existing VPC

Table 7. Network Configuration
Parameter label (name) Default value Description

VPC CIDR (VPCCIDR)

10.0.0.0/16

CIDR Block used by the VPC

VPC ID (VPCID)

Requires input

ID of the VPC (e.g., vpc-0343606e)

Private Subnet 1 ID (PrivateSubnet1ID)

Requires input

ID of the private subnet 1 in Availability Zone 1 (e.g., subnet-a0246dcd)

Private Subnet 2 ID (PrivateSubnet2ID)

Requires input

ID of the private subnet 2 in Availability Zone 2 (e.g., subnet-a0246dcd)

Public Subnet 1 ID (PublicSubnet1ID)

Requires input

ID of the public subnet 1 in Availability Zone 1 (e.g., subnet-e3246d8e)

Public Subnet 2 ID (PublicSubnet2ID)

Requires input

ID of the public subnet 2 in Availability Zone 2 (e.g., subnet-e3246d8e)

Table 8. Amazon EC2 Configuration
Parameter label (name) Default value Description

Key Pair Name (KeyPairName)

Requires input

Public/private key pairs allow you to securely connect to your instance after it launches

WAP and ADFS Server Instance Type (WAPADFSInstanceType)

c4.2xlarge

Amazon EC2 instance type for the WAP and ADFS Servers

SSM Parameter to Grab Latest AMI ID (LatestAmiId)

/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-Base

NO_DESCRIPTION

Table 9. Microsoft Active Directory Configuration
Parameter label (name) Default value Description

Domain DNS Name (DomainDNSName)

example.com

Fully qualified domain name (FQDN) of the forest root domain e.g. corp.example.com

Domain NetBIOS Name (DomainNetBIOSName)

example

NetBIOS name of the domain (upto 15 characters) for users of earlier versions of Windows e.g. CORP

Domain Admin User Name (DomainAdminUser)

StackAdmin

User name for the account that will be added as Domain Administrator. This is separate from the default "Administrator" account

Domain Admin Password (DomainAdminPassword)

Requires input

Password for the domain admin user. Must be at least 8 characters containing letters, numbers and symbols

Domain Member Security Group ID (DomainMemberSGID)

Requires input

ID of the Domain Member Security Group (e.g., sg-7f16e910)

Table 10. AWS Quick Start Configuration
Parameter label (name) Default value Description

Quick Start S3 Bucket Name (QSS3BucketName)

aws-quickstart

S3 bucket name for the Quick Start assets. Quick Start bucket name can include numbers, lowercase letters, uppercase letters, and hyphens (-). It cannot start or end with a hyphen (-).

Quick Start S3 bucket region (QSS3BucketRegion)

us-east-1

The AWS Region where the Quick Start S3 bucket (QSS3BucketName) is hosted. When using your own bucket, you must specify this value.

Quick Start S3 Key Prefix (QSS3KeyPrefix)

quickstart-microsoft-wapadfs/

S3 key prefix for the Quick Start assets. Quick Start key prefix can include numbers, lowercase letters, uppercase letters, hyphens (-), and forward slash (/).

  1. On the Configure stack options page, you can specify tags (key-value pairs) for resources in your stack and set advanced options. When you’re finished, choose Next.

  2. On the Review page, review and confirm the template settings. Under Capabilities, select the two check boxes to acknowledge that the template creates IAM resources and might require the ability to automatically expand macros.

  3. Choose Create stack to deploy the stack.

  4. Monitor the status of the stack. When the status is CREATE_COMPLETE, the WAP and AD FS deployment is ready.

  5. Use the values displayed in the Outputs tab for the stack, as shown in WAP and AD FS outputs after successful deployment, to view the created resources.

cfn_outputs
Figure 4. WAP and AD FS outputs after successful deployment

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.

In order to take advantage of header inspection, it is recommended that Application Load Balancers (rather than Network Load Balancers or Classic Load Balancers) be deployed. The Internet-facing load balancer for the Web Application Proxy layer should be configured to accept HTTPS requests on port 443 and forward these requests to the Web Application Proxy servers, and a certificate obtained from a trusted third-party Certificate Authority will need to be assigned to this listener. The internal load balancer will also be configured to accept HTTPS requests on port 443 but its listener can be assigned an internally-signed certificate.

See Microsoft AD FS Requirements for detailed load balancing and health check requirements.

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:_Publishing_Outlook[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:_Publishing_Outlook[appendix] for an example that covers both AD FS and pass-through pre-authentication.

Security

When you build systems on the AWS infrastructure, security responsibilities are shared between you and AWS. This shared model can reduce your operational burden as AWS operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the services operate. In turn, you assume responsibility and management of the guest operating system (including updates and security patches), other associated applications, as well as the configuration of the AWS-provided security group firewall. For more information about security on AWS, visit the AWS Security Center.

Operating System Security

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.

Security Groups

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 Web Application Proxy. We recommend that you review security groups and further restrict access as needed once the deployment is up and running.

Additional Resources

AWS services

Microsoft Web Application Proxy and AD FS

Deploying Microsoft software on AWS

Tools

Associated Quick Start reference deployments

FAQ

Q. I encountered a CREATE_FAILED error when I launched the Quick Start.

A. If AWS CloudFormation fails to create the stack, we recommend that you relaunch the template with Rollback on failure set to Disabled. (This setting is under Advanced in the AWS CloudFormation console, Options page.) With this setting, the stack’s state is retained and the instance is left running, so you can troubleshoot the issue. (For Windows, look at the log files in %ProgramFiles%\Amazon\EC2ConfigService and C:\cfn\log.)

When you set Rollback on failure to Disabled, you continue to incur AWS charges for this stack. Please make sure to delete the stack when you finish troubleshooting.

For additional information, see Troubleshooting AWS CloudFormation on the AWS website.

Q. I encountered a size limitation error when I deployed the AWS CloudFormation templates.

A. We recommend that you launch the Quick Start templates from the links in this guide or from another S3 bucket. If you deploy the templates from a local copy on your computer or from a location other than an S3 bucket, you might encounter template size limitations. For more information about AWS CloudFormation quotas, see the AWS documentation.

Appendix: Publishing Outlook Web App to the Internet with AD FS Pre-Authentication

Instead of using the nested AWS CloudFormation template to launch a new environment, you can use the Web Application Proxy and AD FS template included with this Quick Start to launch the components into an existing VPC.

Important The sub-template for Web Application Proxy and AD FS provided with this guide is built to work with existing VPCs that have two public and two private subnets, and an existing Active Directory Domain Services implementation. More specifically, it is designed to work with the existing Microsoft-based AWS Quick Starts, such as Exchange Server, SharePoint Server, and Lync Server.

In this appendix, we’ll show you how to launch the Web Application Proxy and AD FS infrastructure on top of the Exchange Server Quick Start. Then we’ll walk through the steps to publish Outlook Web App (OWA) to the internet using Web Application Proxy and AD FS.

Note This walkthrough details the process of publishing OWA using Integrated Windows authentication. You can follow the same general process for Exchange Server 2010, or other web applications you want to publish with Integrated Windows authentication. It is also possible to publish OWA with claims-based authentication using Exchange Server 2013 SP1 or newer, but that scenario is beyond the scope of this guide.

  1. Launch the Exchange Server Quick Start.

  2. Once the Exchange Server 2019 stack has been created successfully, launch the Web Application Proxy and AD FS template. As shown previously in this guide, you’ll need to specify the KeyPairName for your chosen region. Additionally, you’ll need to specify the IDs for your existing VPC and for the public and private subnets.

  3. Initiate a Remote Desktop Protocol (RDP) connection to one of the RD Gateway instances. You can retrieve the Elastic IP for the RD Gateway servers in the Amazon EC2 console. From there, use RDP to connect to the EXCH1 server.

  4. On EXCH1, navigate to the Exchange Admin Center (https://exch1/ecp) in a web browser. Sign in by using the stackadmin user account and password you specified when building the stack.

Additional1
Figure 5. Logging into the Exchange Admin Center
  1. In the left pane, choose Servers, Virtual directories.

Additional2
Figure 6. Viewing the virtual directories on EXCH1
  1. Double-click owa (Default Web Site) on the EXCH1 server. Choose Authentication, Integrated Windows authentication, and then choose Save. You should also change the corresponding setting on the ECP virtual directory on EXCH1.

Additional3
Figure 7. Setting OWA authentication to Integrated Windows

Note In a load-balanced production environment, you would modify this setting on each Exchange server that is running the Client Access role.

  1. Establish an RDP connection to the ADFS1 server. In Control Panel, choose Administrative Tools, and then launch the ADFS Management snap-in.

  2. Open the context (right-click) menu for Trust Relationships, and then choose Add Non-Claims-Aware Relying Party Trust to start the wizard.

Additional4
Figure 8. Adding a non-claims-aware relying party trust
  1. On the welcome page of the wizard, choose Start, and type a display name such as OWA. Provide a unique identifier string for the non-claims-aware relying party trust. Use the default service name created by the Quick Start (e.g., http://sts.example.com/adfs/services/trust) for the URL.

  2. Indicate that you do not want to configure multi-factor authentication, and then choose Next.

  3. Go through the remaining screens without making changes. On the final screen, leave the Open the Edit Issuance Authorization Rules option selected, and then choose Close.

  4. On the Edit Claim Rules screen, choose Add Rule, Permit Access to All Users, and then choose Finish.

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

Additional5
Figure 9. Viewing the Remote Access Management console

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.

  1. Under Tasks, choose Publish.

  2. On the Welcome screen, choose Next. On the Preauthentication tab, choose Pass-through.

Additional6
Figure 10. Selecting the pass-through pre-authentication method
  1. Provide a name such as ADFS for the rule. Specify the external URL, the external certificate, and the back-end server URL as shown in Figure 11.

Additional7
Figure 11. Configuring the publishing rule

Note If you’ve implemented internal load balancing for the AD FS tier, you can set the back-end server URL to a load-balanced endpoint instead of an individual server name.

  1. Choose Publish, and then Close to exit the wizard.

  2. Choose Publish again to create a new rule for OWA. This time, set the pre-authentication method to Active Directory Federation Services (AD FS), and then choose Next.

Additional8
Figure 12. Selecting the AD FS pre-authentication method
  1. For the relying party for the application, select the relying party trust you created on the AD FS server, and then choose Next.

Additional9
Figure 13. Selecting the relying party
  1. Provide a name such as OWA for the rule. Specify the external URL, external certificate, back-end URL, and service principal name (SPN) for the back-end server, as shown in Figure 14.

Additional10
Figure 14. Configuring rule details

Note If you’ve implemented internal load balancing for the Exchange client access tier, you can set the back-end server URL and SPN to a load-balanced endpoint instead of an individual server name.

  1. Choose Publish and close the wizard.

  2. Establish an RDP connection to DC1. In Control Panel, choose Administrative Tools, and then launch the Active Directory Users and Computers snap-in.

  3. Navigate to the Computers container, right-click the WAP1 computer, and then choose Properties. On the Delegation tab, choose Trust this computer for delegation to specified services only. Check the option to use any authentication protocol, and add the HTTP service type on the EXCH1 computer to the list, as shown in Figure 15. Choose Apply, and then choose OK.

Additional11
Figure 15. Configuring Kerberos constrained delegation

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

  1. If you did not use your own domain name, you’ll need to edit the hosts file on your machine to allow your computer to resolve the endpoints at example.com: Add a mapping for sts.example.com and mail.example.com to your local hosts file, making sure that both hosts resolve to the public EIP of the WAP1 server.

  2. Open a web browser from your external workstation or server. Navigate to mail.example.com. You should be redirected to the federation service and prompted for authentication. Provide the stackadmin user name and password, and then choose Sign in.

Additional12
Figure 16. Pre-authenticating to AD FS

If the authentication is successful, the connection should be proxied to the EXCH1 server through the Web Application Proxy, as shown in Figure 17.

Additional13
Figure 17. Connected to the published application

Send us feedback

To post feedback, submit feature ideas, or report bugs, use the Issues section of the GitHub repository for this Quick Start. To submit code, see the Quick Start Contributor’s Guide.

Quick Start reference deployments

GitHub repository

Visit our GitHub repository to download the templates and scripts for this Quick Start, to post your comments, and to share your customizations with others.


Notices

This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether expressed or implied. This document does not create any warranties, representations, contractual commitments, conditions, or assurances from AWS, its affiliates, suppliers, or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

The software included with this paper is licensed under the Apache License, version 2.0 (the "License"). You may not use this file except in compliance with the License. A copy of the License is located at http://aws.amazon.com/apache2.0/ or in the accompanying "license" file. This code is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either expressed or implied. See the License for specific language governing permissions and limitations.