// Add steps as necessary for accessing the software, post-configuration, and testing. Don’t include full usage instructions for your software, but add links to your product documentation for that information.
//Should any sections not be applicable, remove them

== Post-deployment steps

=== Run Windows Updates

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

1. Create an RDP session from the Remote Desktop Gateway server to each deployed server.
2. Open the *Settings* application.
3. Open *Update & Security*.
4. Click *Check for updates*.
5. Install any updates and reboot if necessary.

[[design-considerations]]
== 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]]
=== 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]]
=== 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]]
=== 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 https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements[Microsoft AD FS Requirements] for detailed load balancing and health check requirements.

[[certificates]]
=== 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]]
==== 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]]
==== 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]]
=== 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]]
=== 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 https://technet.microsoft.com/en-us/library/dn383640.aspx[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 https://technet.microsoft.com/en-us/library/dn584096.aspx[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 http://aws.amazon.com/security/[AWS Security Center].

[[operating-system-security]]
=== 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]]
=== 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*

* AWS CloudFormation +
https://aws.amazon.com/documentation/cloudformation/
* Amazon EBS

* User guide: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html
* Volume types: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
* Optimized instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

* Amazon EC2

* User guide for Microsoft Windows: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/

* Amazon VPC +
http://aws.amazon.com/documentation/vpc/

*Microsoft Web Application Proxy and AD FS*

* Planning for AD FS Server Capacity +
https://technet.microsoft.com/en-us/library/gg749899.aspx
* Planning to Publish Applications Using Web Application Proxy +
https://technet.microsoft.com/en-us/library/dn383650.aspx
* Configure the Web Application Proxy Infrastructure +
https://technet.microsoft.com/en-us/library/dn383644.aspx
* Install and Configure the Web Application Proxy Server +
https://technet.microsoft.com/en-us/library/dn383662.aspx
* Publish Applications using AD FS Preauthentication +
https://technet.microsoft.com/en-us/library/dn383640.aspx
* Publish Applications using Pass-through Preauthentication +
https://technet.microsoft.com/en-us/library/dn383639.aspx
* Enabling Federation to AWS using Windows Active Directory, ADFS, and SAML 2.0 +
https://blogs.aws.amazon.com/security/post/Tx71TWXXJ3UI14/Enabling-Federation-to-AWS-using-Windows-Active-Directory-ADFS-and-SAML-2-0

*Deploying Microsoft software on AWS*

* Microsoft on AWS +
https://aws.amazon.com/microsoft/
* Secure Microsoft applications on AWS +
https://d0.awsstatic.com/whitepapers/aws-microsoft-platform-security.pdf
* Microsoft Licensing Mobility +
https://aws.amazon.com/windows/mslicensemobility/
* MSDN on AWS +
https://aws.amazon.com/windows/msdn/
* AWS Windows and .NET Developer Center +
https://aws.amazon.com/net/

*Tools*

* Best Practices Analyzer for Web Application Proxy +
https://technet.microsoft.com/en-us/library/dn383651.aspx
* Load-balancing solutions in the AWS Marketplace +
https://aws.amazon.com/marketplace/

*Associated Quick Start reference deployments*

* Microsoft Active Directory on AWS +
https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/
* Microsoft Remote Desktop Gateway on AWS +
https://docs.aws.amazon.com/quickstart/latest/rd-gateway/
* Additional reference deployments +
https://aws.amazon.com/quickstart/ [[_Appendix:_Publishing_Outlook]]