The document is organized in a series of scenarios, with each building on the ones before it. It is strongly recommended that the reader follow the document's instructions in the order they are presented.
The scenarios covered are:

Corporate application, accessed from anywhere: External, not-domain-joined client (i.e. at the coffee shop) accessing the same EC2-hosted application, using AD FS v1.1 with an AD FS proxy. In addition to external (forms-based) authentication, the proxy also provides added security for the corporate federation server

Service provider application: Domain-joined and external Windows clients accessing an EC2-hosted application operated by a service provider, using one AD FS v1.1 federation server for each organization (with the service provider's federation server hosted in EC2) and a federated trust between the parties

Service provider application with added security: Same clients accessing same vendor-owned EC2-hosted application, but with an AD FS proxy deployed by the software vendor for security purposes.

To reduce the overall computing requirements for this lab, AD FS federation servers are deployed on the same machines as Active Directory Domain Services (AD DS) domain controllers and Active Directory Certificate Services (AD CS) certificate authorities. This configuration presents security risks. In a production environment, it is advisable to deploy federation servers, domain controllers and certificate authorities on separate machines.

This lab includes a fully-functional Public Key Infrastructure (PKI) deployment, using Active Directory Certificate Services. PKI is a critical foundational element to a production-ready federation deployment. Note that:

This lab uses a single-tier certificate hierarchy. Note that a two-tier certificate hierarchy with an offline certificate authority (CA) responsible for the organization root certificate would be more secure, but is outside the scope of this lab.

Also, this lab uses CA-issued certificates (chained to an internal root CA certificate) for SSL server authentication. This requires distribution of the root CA certificate to all clients that access those web servers, to avoid SSL-related errors. In a production deployment, it is preferable to use certificates that chain to a third-party root certificate (from Verisign, RSA, etc.) that is already present in Windows operating systems, since this alleviates the need to distribute root CA certificates.

This lab also includes a fully-functional Domain Name Services (DNS) deployment, using Microsoft DNS Server. DNS is also a critical foundational element to a production-ready federation deployment. Note that:

This lab uses fictional DNS domains, which Internet name servers resolve to the microsoft.com web site, breaking the lab functionality. Thus, the lab simulates resolution of external DNS names by using DNS forwarding from domain DNS instances to a hypothetical "Internet DNS" server that you run on one of the EC2-hosted web servers. While useful in the context of this lab, DNS forwarding is not a requirement of a functional federation deployment.

To varying degrees, every scenario covered in this lab requires inbound Internet connectivity to the corporate federation servers, which will reside inside your organization's firewall. Before proceeding, make sure you have access to an external/internet IP address, with open ports 80 and 443 for Scenario 1, and port 443 only for Scenarios 2 through 5.

This lab will require a total of three local computers. In this lab, Hyper-V virtualization technology in Windows Server 2008 was used to keep physical machine requirements down.

To simplify the recording of important values you must type during configuration, please use the Important Values Worksheet.