Extend Active Directory Federation Services (AD FS) to Azure
This reference architecture implements a secure hybrid network that extends your on-premises network to Azure and uses Active Directory Federation Services (AD FS) to perform federated authentication and authorization for components running in Azure. Deploy this solution.
Download a Visio file of this architecture.
AD FS can be hosted on-premises, but if your application is a hybrid in which some parts are implemented in Azure, it may be more efficient to replicate AD FS in the cloud.
The diagram shows the following scenarios:
- Application code from a partner organization accesses a web application hosted inside your Azure VNet.
- An external, registered user with credentials stored inside Active Directory Domain Services (DS) accesses a web application hosted inside your Azure VNet.
- A user connected to your VNet using an authorized device executes a web application hosted inside your Azure VNet.
Typical uses for this architecture include:
- Hybrid applications where workloads run partly on-premises and partly in Azure.
- Solutions that use federated authorization to expose web applications to partner organizations.
- Systems that support access from web browsers running outside of the organizational firewall.
- Systems that enable users to access to web applications by connecting from authorized external devices such as remote computers, notebooks, and other mobile devices.
This reference architecture focuses on passive federation, in which the federation servers decide how and when to authenticate a user. The user provides sign in information when the application is started. This mechanism is most commonly used by web browsers and involves a protocol that redirects the browser to a site where the user authenticates. AD FS also supports active federation, where an application takes on responsibility for supplying credentials without further user interaction, but that scenario is outside the scope of this architecture.
For additional considerations, see Choose a solution for integrating on-premises Active Directory with Azure.
This architecture extends the implementation described in Extending AD DS to Azure. It contains the followign components.
AD DS subnet. The AD DS servers are contained in their own subnet with network security group (NSG) rules acting as a firewall.
AD DS servers. Domain controllers running as VMs in Azure. These servers provide authentication of local identities within the domain.
AD FS subnet. The AD FS servers are located within their own subnet with NSG rules acting as a firewall.
AD FS servers. The AD FS servers provide federated authorization and authentication. In this architecture, they perform the following tasks:
Receiving security tokens containing claims made by a partner federation server on behalf of a partner user. AD FS verifies that the tokens are valid before passing the claims to the web application running in Azure to authorize requests.
The web application running in Azure is the relying party. The partner federation server must issue claims that are understood by the web application. The partner federation servers are referred to as account partners, because they submit access requests on behalf of authenticated accounts in the partner organization. The AD FS servers are called resource partners because they provide access to resources (the web application).
Authenticating and authorizing incoming requests from external users running a web browser or device that needs access to web applications, by using AD DS and the Active Directory Device Registration Service.
The AD FS servers are configured as a farm accessed through an Azure load balancer. This implementation improves availability and scalability. The AD FS servers are not exposed directly to the Internet. All Internet traffic is filtered through AD FS web application proxy servers and a DMZ (also referred to as a perimeter network).
For more information about how AD FS works, see Active Directory Federation Services Overview. Also, the article AD FS deployment in Azure contains a detailed step-by-step introduction to implementation.
AD FS proxy subnet. The AD FS proxy servers can be contained within their own subnet, with NSG rules providing protection. The servers in this subnet are exposed to the Internet through a set of network virtual appliances that provide a firewall between your Azure virtual network and the Internet.
AD FS web application proxy (WAP) servers. These VMs act as AD FS servers for incoming requests from partner organizations and external devices. The WAP servers act as a filter, shielding the AD FS servers from direct access from the Internet. As with the AD FS servers, deploying the WAP servers in a farm with load balancing gives you greater availability and scalability than deploying a collection of stand-alone servers.
For detailed information about installing WAP servers, see Install and Configure the Web Application Proxy Server
Partner organization. A partner organization running a web application that requests access to a web application running in Azure. The federation server at the partner organization authenticates requests locally, and submits security tokens containing claims to AD FS running in Azure. AD FS in Azure validates the security tokens, and if valid can pass the claims to the web application running in Azure to authorize them.
You can also configure a VPN tunnel using Azure gateway to provide direct access to AD FS for trusted partners. Requests received from these partners do not pass through the WAP servers.
For more information about the parts of the architecture that are not related to AD FS, see the following:
- Implementing a secure hybrid network architecture in Azure
- Implementing a secure hybrid network architecture with Internet access in Azure
- Implementing a secure hybrid network architecture with Active Directory identities in Azure.
The following recommendations apply for most scenarios. Follow these recommendations unless you have a specific requirement that overrides them.
Create VMs with sufficient resources to handle the expected volume of traffic. Use the size of the existing machines hosting AD FS on premises as a starting point. Monitor the resource utilization. You can resize the VMs and scale down if they are too large.
Follow the recommendations listed in Running a Windows VM on Azure.
Configure the network interface for each of the VMs hosting AD FS and WAP servers with static private IP addresses.
Do not give the AD FS VMs public IP addresses. For more information, see the Security considerations section.
Set the IP address of the preferred and secondary domain name service (DNS) servers for the network interfaces for each AD FS and WAP VM to reference the Active Directory DS VMs. The Active Directory DS VMS should be running DNS. This step is necessary to enable each VM to join the domain.
AD FS availability
Create an AD FS farm with at least two servers to increase availability of the service. Use different storage accounts for each AD FS VM in the farm. This approach helps to ensure that a failure in a single storage account does not make the entire farm inaccessible.
We recommend the use of managed disks. Managed disks do not require a storage account. You simply specify the size and type of disk and it is deployed in a highly available way. Our reference architectures do not currently deploy managed disks but the template building blocks will be updated to deploy managed disks in version 2.
Create separate Azure availability sets for the AD FS and WAP VMs. Ensure that there are at least two VMs in each set. Each availability set must have at least two update domains and two fault domains.
Configure the load balancers for the AD FS VMs and WAP VMs as follows:
Use an Azure load balancer to provide external access to the WAP VMs, and an internal load balancer to distribute the load across the AD FS servers in the farm.
Only pass traffic appearing on port 443 (HTTPS) to the AD FS/WAP servers.
Give the load balancer a static IP address.
Create a health probe using HTTP against
/adfs/probe. For more information, see Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2.
AD FS servers use the Server Name Indication (SNI) protocol, so attempting to probe using an HTTPS endpoint from the load balancer fails.
Add a DNS A record to the domain for the AD FS load balancer. Specify the IP address of the load balancer, and give it a name in the domain (such as adfs.contoso.com). This is the name clients and the WAP servers use to access the AD FS server farm.
AD FS security
Prevent direct exposure of the AD FS servers to the Internet. AD FS servers are domain-joined computers that have full authorization to grant security tokens. If a server is compromised, a malicious user can issue full access tokens to all web applications and to all federation servers that are protected by AD FS. If your system must handle requests from external users not connecting from trusted partner sites, use WAP servers to handle these requests. For more information, see Where to Place a Federation Server Proxy.
Place AD FS servers and WAP servers in separate subnets with their own firewalls. You can use NSG rules to define firewall rules. If you require more comprehensive protection you can implement an additional security perimeter around servers by using a pair of subnets and network virtual appliances (NVAs), as described in the document Implementing a secure hybrid network architecture with Internet access in Azure. All firewalls should allow traffic on port 443 (HTTPS).
Restrict direct sign in access to the AD FS and WAP servers. Only DevOps staff should be able to connect.
Do not join the WAP servers to the domain.
AD FS installation
The article Deploying a Federation Server Farm provides detailed instructions for installing and configuring AD FS. Perform the following tasks before configuring the first AD FS server in the farm:
Obtain a publicly trusted certificate for performing server authentication. The subject name must contain the name clients use to access the federation service. This can be the DNS name registered for the load balancer, for example, adfs.contoso.com (avoid using wildcard names such as *.contoso.com, for security reasons). Use the same certificate on all AD FS server VMs. You can purchase a certificate from a trusted certification authority, but if your organization uses Active Directory Certificate Services you can create your own.
The subject alternative name is used by the device registration service (DRS) to enable access from external devices. This should be of the form enterpriseregistration.contoso.com.
For more information, see Obtain and Configure a Secure Sockets Layer (SSL) Certificate for AD FS.
On the domain controller, generate a new root key for the Key Distribution Service. Set the effective time to the current time minus 10 hours (this configuration reduces the delay that can occur in distributing and synchronizing keys across the domain). This step is necessary to support creating the group service account that is used to run the AD FS service. The following PowerShell command shows an example of how to do this:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
Add each AD FS server VM to the domain.
To install AD FS, the domain controller running the primary domain controller (PDC) emulator flexible single master operation (FSMO) role for the domain must be running and accessible from the AD FS VMs. <<RBC: Is there a way to make this less repetitive?>>
AD FS trust
Establish federation trust between your AD FS installation, and the federation servers of any partner organizations. Configure any claims filtering and mapping required.
- DevOps staff at each partner organization must add a relying party trust for the web applications accessible through your AD FS servers.
- DevOps staff in your organization must configure claims-provider trust to enable your AD FS servers to trust the claims that partner organizations provide.
- DevOps staff in your organization must also configure AD FS to pass claims on to your organization's web applications.
For more information, see Establishing Federation Trust.
Publish your organization's web applications and make them available to external partners by using preauthentication through the WAP servers. For more information, see Publish Applications using AD FS Preauthentication
AD FS supports token transformation and augmentation. Azure Active Directory does not provide this feature. With AD FS, when you set up the trust relationships, you can:
- Configure claim transformations for authorization rules. For example, you can map group security from a representation used by a non-Microsoft partner organization to something that that Active Directory DS can authorize in your organization.
- Transform claims from one format to another. For example, you can map from SAML 2.0 to SAML 1.1 if your application only supports SAML 1.1 claims.
AD FS monitoring
The Microsoft System Center Management Pack for Active Directory Federation Services 2012 R2 provides both proactive and reactive monitoring of your AD FS deployment for the federation server. This management pack monitors:
- Events that the AD FS service records in its event logs.
- The performance data that the AD FS performance counters collect.
- The overall health of the AD FS system and web applications (relying parties), and provides alerts for critical issues and warnings.
The following considerations, summarized from the article Plan your AD FS deployment, give a starting point for sizing AD FS farms:
- If you have fewer than 1000 users, do not create dedicated servers, but instead install AD FS on each of the Active Directory DS servers in the cloud. Make sure that you have at least two Active Directory DS servers to maintain availability. Create a single WAP server.
- If you have between 1000 and 15000 users, create two dedicated AD FS servers and two dedicated WAP servers.
- If you have between 15000 and 60000 users, create between three and five dedicated AD FS servers and at least two dedicated WAP servers.
These considerations assume that you are using dual quad-core VM (Standard D4_v2, or better) sizes in Azure.
If you are using the Windows Internal Database to store AD FS configuration data, you are limited to eight AD FS servers in the farm. If you anticipate that you will need more in the future, use SQL Server. For more information, see The Role of the AD FS Configuration Database.
You can use either SQL Server or the Windows Internal Database to hold AD FS configuration information. The Windows Internal Database provides basic redundancy. Changes are written directly to only one of the AD FS databases in the AD FS cluster, while the other servers use pull replication to keep their databases up to date. Using SQL Server can provide full database redundancy and high availability using failover clustering or mirroring.
DevOps staff should be prepared to perform the following tasks:
- Managing the federation servers, including managing the AD FS farm, managing trust policy on the federation servers, and managing the certificates used by the federation services.
- Managing the WAP servers including managing the WAP farm and certificates.
- Managing web applications including configuring relying parties, authentication methods, and claims mappings.
- Backing up AD FS components.
AD FS utilizes the HTTPS protocol, so make sure that the NSG rules for the subnet containing the web tier VMs permit HTTPS requests. These requests can originate from the on-premises network, the subnets containing the web tier, business tier, data tier, private DMZ, public DMZ, and the subnet containing the AD FS servers.
Consider using a set of network virtual appliances that logs detailed information on traffic traversing the edge of your virtual network for auditing purposes.
Deploy the solution
A solution is available on GitHub to deploy this reference architecture. You will need the latest version of the Azure CLI to run the Powershell script that deploys the solution. To deploy the reference architecture, follow these steps:
Download or clone the solution folder from GitHub to your local machine.
Open the Azure CLI and navigate to the local solution folder.
Run the following command:
.\Deploy-ReferenceArchitecture.ps1 <subscription id> <location> <mode>
<subscription id>with your Azure subscription ID.
<location>, specify an Azure region, such as
<mode>parameter controls the granularity of the deployment, and can be one of the following values:
Onpremise: Deploys a simulated on-premises environment. You can use this deployment to test and experiment if you do not have an existing on-premises network, or if you want to test this reference architecture without changing the configuration of your existing on-premises network.
Infrastructure: deploys the VNet infrastructure and jump box.
CreateVpn: deploys an Azure virtual network gateway and connects it to the simulated on-premises network.
AzureADDS: deploys the VMs acting as Active Directory DS servers, deploys Active Directory to these VMs, and creates the domain in Azure.
AdfsVm: deploys the AD FS VMs and joins them to the domain in Azure.
PublicDMZ: deploys the public DMZ in Azure.
ProxyVm: deploys the AD FS proxy VMs and joins them to the domain in Azure.
Prepare: deploys all of the preceding deployments. This is the recommended option if you are building an entirely new deployment and you don't have an existing on-premises infrastructure.
Workload: optionally deploys web, business, and data tier VMs and supporting network. Not included in the
PrivateDMZ: optionally deploys the private DMZ in Azure in front of the
WorkloadVMs deployed above. Not included in the
Wait for the deployment to complete. If you used the
Prepareoption, the deployment takes several hours to complete, and finishes with the message
Preparation is completed. Please install certificate to all AD FS and proxy VMs.
Restart the jump box (ra-adfs-mgmt-vm1 in the ra-adfs-security-rg group) to allow its DNS settings to take effect.
Obtain an SSL Certificate for AD FS and install this certificate on the AD FS VMs. Note that you can connect to them through the jump box. The IP addresses are 10.0.5.4 and 10.0.5.5. The default username is contoso\testuser with password AweSome@PW.
The comments in the Deploy-ReferenceArchitecture.ps1 script at this point provides detailed instructions for creating a self-signed test certificate and authority using the
makecertcommand. However, perform these steps as a test only and do not use the certificates generated by makecert in a production environment.
Run the following PowerShell command to deploy the AD FS server farm:
.\Deploy-ReferenceArchitecture.ps1 <subscription id> <location> Adfs
On the jump box, browse to
https://adfs.contoso.com/adfs/ls/idpinitiatedsignon.htmto test the AD FS installation (you may receive a certificate warning that you can ignore for this test). Verify that the Contoso Corporation sign-in page appears. Sign in as contoso\testuser with password AweS0me@PW.
Install the SSL certificate on the AD FS proxy VMs. The IP addresses are 10.0.6.4 and 10.0.6.5.
Run the following PowerShell command to deploy the first AD FS proxy server:
.\Deploy-ReferenceArchitecture.ps1 <subscription id> <location> Proxy1
Follow the instructions displayed by the script to test the installation of the first proxy server.
Run the following PowerShell command to deploy the second proxy server:
.\Deploy-ReferenceArchitecture.ps1 <subscription id> <location> Proxy2
Follow the instructions displayed by the script to test the complete proxy configuration.