A Real-world tested Approach for Transitioning Web Application Proxy Servers

ADFS[11]

We’ve migrated many AD FS implementations from Windows Server 2012 R2 to Windows Server 2016 and beyond. This blogpost intends to share our experiences during these migrations, so you can take advantage of them during your migrations.

 

How we migrate

In general, we migrate Web Application Proxy servers by adding additional Web Application Proxies to the AD FS Farm. From there, we take one of three routes:

  1. We cut over the external IP address of the AD FS Farm in the external DNS zone to the new Web Application Proxy server. This is our usual path when an organization wants to migrate one single Web Application Proxy server to a new one.
  2. We add the additional Web Application Proxy server(s) to the load-balancer that spreads the authentication requests to a pool of Web Application Proxy servers. After a short period of coexistence to check if everything works, we remove the Web Application Proxy server(s) the organization no longer wants to use. This is our usual path when an organization has a load-balancer in place.
  3. We provide the additional Web Application Proxy server with an external IP address. Then, we use Azure Traffic Manager to cut over the DNS entry of the existing Web Application Proxy to Traffic Manager. After a short period of coexistence to check if everything works, we configure Azure Traffic Manager to only flow authentication requests to the new Web Application Proxy server and we decommission the old Web Application Proxy server.

All three migration approaches have their pros and cons. They also have distinctly different requirements. Scenario 3 requires Azure Traffic Manager, for instance. This requirement typically costs three dollar for our migration, but adds the benefit of being able to roll-back in case of trouble.

 

What is migrated

Some settings are configured, by default, when you add a Web Application Proxy server, while others require manual migration:

Created, by default

By default, the following settings and configuration items are automatically provisioned on additional Web Application Proxy servers to the same AD FS farm:

  • The certificate-based trust to the Active Directory Federation Services (AD FS) farm for the Web Application Proxy server
  • Membership to the Web Application Proxy ConnectedServers configuration for the AD FS farm
  • Windows Firewall exceptions to allow inbound communications

Migrated, by default

By default, the following settings and configuration items are automatically provisioned on additional Web Application Proxy servers to the same AD FS farm:

  • The publishing rules defined on other Web Application Proxy servers attached to the same AD FS farm
  • The AD FS certificate, but only when the Web Application Proxy is created through the Azure AD Connect wizard
  • Any changes to the default set of endpoints, allowed through proxies for the AD FS farm

Needs to manually be set or migrated

However, important parts need to be migrated or configured manually:

  • The AD FS certificate, unless the Web Application Proxy is created through the Azure AD Connect wizard
  • The TLS certificates for the backend systems, applications and/or services that are published through the Web Application Proxy server(s)
  • Name resolution, when it is not dependent on a DNS infrastructure in either the perimeter network (when the Web Application Proxy server is placed there), on the server network (when the Web Application Proxy server is placed there) unless it is hosted by the Active Directory Domain Controllers and the Web Application Proxy server is domain-joined
  • Any network firewall rules between the Web Application Proxy server and the (load balancer for the) AD FS Server(s)
  • Any network firewall rules between the Web Application Proxy server and the backend systems, applications and/or services that are published through the Web Application Proxy server(s)
  • When the last Web Application Proxy server for a down-level version of Windows Server is decommissioned, the Web Application Proxy Configuration Version needs to be updated. This is a manual action.

 

Creating an inventory

To transition Web Application Proxy servers, it’s a good idea to create an inventory beforehand. Answer these questions:

Q1 What does the AD FS farm look like?

Determine the amount of AD FS servers that are part of the AD FS farm and their hostnames, so you can check the routes and firewall rules from any (new) Web Application Proxy server. Run the following line of Windows PowerShell from the AD FS server that is the primary server in case of WID, or any AD FS server when Microsoft SQL Server is used to host the AD FS configuration database:

(Get-AdfsProperties).Hostname

(Get-AdfsProperties).ArtifactDbConnection

(Get-AdfsFarmInformation).FarmNodes | Format-Table

The above three cmdlets return the URL of the AD FS Farm, whether its using Windows Internal Database (WID) or a Microsoft SQL Server as the AD FS configuration database and a table with all the AD FS servers, including their roles in the AD FS farm.

Q2 What domain are the AD FS servers joined to?

As Web Application Proxy servers can only be joined to the same Active Directory domain the AD FS servers are joined to, we’ll look up the DNS domain name using any one of the AD FS servers with the following line of Windows PowerShell:

(Get-WmiObject Win32_ComputerSystem).Domain

Q3 What are the current Web Application Proxy servers?

To gather this information, you need to run the following lines on a Web Application Proxy:

(Get-WebApplicationProxyConfiguration).ConfigurationVersion

(Get-WebApplicationProxyConfiguration).ConnectedServersName

The above two cmdlets return the configuration version for the Web Application Proxy servers and the hostnames of the Web Application Proxy servers.

Q4 What are web applications are currently being published?

To gather this information, you need to run the following lines on a Web Application Proxy:

Get-WebApplicationProxyApplication

This cmdlet returns a formatted table of the published web applications, including their names, front-end URLs, back-end URLs and the pre-authentication method.

Note:
On non-domain-joined Web Application Proxy servers, only the Passthrough pre-authentication method is available. If your migration path includes switching from domain-joined Web Application Proxy servers to non-domain-joined Web Application Proxy servers, remove or change the application that have ADFS as pre-authentication method.

Q5 What do the Web Application Proxy servers use for name resolution?

Now that we know the URLs for the AD FS Farm, and back-end URLs for published applications, we can determine the name resolution method used by the Web Application Proxy servers. They’re either using a DNS server or using the HOSTS file. The safest bet is to check the HOSTS file for uncommented entries on the current Web Application Proxy servers with the following line of PowerShell:

Get-Content C:\Windows\System32\drivers\etc\hosts | Select-String -NotMatch "^#"

Entries in the HOSTS file indicate the IP address for the AD FS Farm. When multiple AD FS servers are in use, usually they are behind a load-balancer. In this case, the entry in the HOSTS file for the AD FS farm (see the answers to Q1) indicates the virtual IP address that publishes the back-end pool of AD FS servers.

When the HOSTS file is empty, simply run the following line of Windows PowerShell to find the IP address for the AD FS hostname:

Resolve-DNSName -Name adfshostname

Q6 What additional routes do the Web Application Proxy servers use?

Use the following line of Windows PowerShell to find any additional routes that the current Web Application Proxy server(s) use:

Get-NetRoute

Q7 What are the current certificates in use?

We need to know which TLS certificates are available on the current Web Application Proxy servers. As we’re only interested in TLS certificates for the local machine, we can use the following lines of PowerShell:

Set-Location Cert:\LocalMachine\My

Get-ChildItem | Format-Table FriendlyName, Subject, NotAfter

This outputs a table with TLS certificates, together with their subjects and their expiry dates. The CN=ADFS ProxyTrust certificate(s) can be ignored for the purpose of this inventory, as they refer to the trust relationship between the Web Application Proxy and the AD FS farm.

 

Implement the new Web Application Proxy

Implementing the new Web Application Proxy is easy. Simply create a new (virtual) machine with your favorite supported Windows Server version on it.

A1 Take care of the basics

Make sure the Windows Server installation is activated, up to date with Windows Updates and protected with an anti-malware solution before you continue with the next steps. For more information, refer to these earlier blogposts:

A2 Implement the required name resolution method

The new Web Application Proxy needs to be able to resolve the hostname for AD FS server(s) and the back-end URLs. When the answer to Q5 pops up with HOSTS file entries, then recreate these on the new Web Application Proxy server as well.

A3 Implement the required routes and firewall rules

As the new Web Application Proxy needs to be able to communicate to the AD FS server(s) and the back-end URLs for the published web applications, create the necessary routes and/or firewall rules to allow this traffic. The required information is in the answer to Q6.

A4 (Optionally) Domain-join the Web Application Proxy

If you want the Web Application Proxy server to be domain-joined, run the following lines of PowerShell:

Add-Computer -DomainName "domain.tld"

Restart-Computer

Tip!
Only join the Web Application Proxy server to Active Directory when you have published web application that use ADFS as the pre-authentication method (or when you plan to publish web applications this way in the future). The required information is in the answer for Q4.

Note:
Remember that you can only join a Web Application Proxy server to the same domain as the AD FS server(s). The domain name is the answer to Q2.

A5 Install the certificate(s)

Install the same TLS certificate(s) that is/are used by the current Web Application Proxy server(s) on the new Web Application Proxy server, too. Export these certificates from the current Web Application Proxy server(s) and/or AD FS server(s) with their private keys, or download the certificate(s) again from your certification authority.  The required information is the answer to Q7.

A6 Install the Web Application Proxy feature

Run the following lines of Windows PowerShell to install the Web Application Proxy feature:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

A7 Configure the Web Application Proxy

Run the following lines of Windows PowerShell to configure the Web Application Proxy:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject –match "sts.domain.tld"}).Thumbprint

Install-WebApplicationProxy -CertificateThumbprint $thumb -FederationServiceName sts.domain.tld

After configuration, check the ConnectedServers list on the Web Application Proxy server:

(Get-WebApplicationProxyConfiguration).ConnectedServersName

Alternatively:
As an alternative to actions A5 through A7, you can also use the Azure Active Directory Connect Configuration wizard to install the certificate, install the Web Application Proxy feature and configure the Web Application Proxy. This method works for both domain-joined and non-domain-joined Web Application Proxies, but always requires traffic over TCP port 5985 from the Azure AD Connect server(s) to the Web Application Proxy server(s).

A8 (Optionally) Configure Azure AD Connect Health

To monitor the health of the new Web Application Proxy server, install the Azure AD Connect Health agent for AD FS onto it and configure it. Through the Azure AD Connect Health dashboard that is part of the Azure Portal, you can then see the activity and health for the Web Application Proxy when you put it in use.

A9 Harden the Web Application Proxy

Of course, you want to apply hardening before you put the Web Application Proxy in use. Refer to these earlier blogposts for my hardening recommended practices:

 

Put the Web Application Proxy in use

The Web Application Proxy is now ready for use.

A10 Testing the Functionality of the new Web Application Proxy

However, before you put a new Web Application Proxy server in use, check these areas of attention by pointing an external device through its HOSTS file to IP address of the new Web Application Proxy server:

  1. Can you sign in to the applications, services and/or systems that are represented by the relying party trusts, like you would normally?
  2. Can you access the published web applications, like you would normally?

These technical and functional tests verify that the Web Application Proxy is functioning properly to meet your organization’s needs.

A11 Add the Web Application Proxy to the pool

Now you can add the Web Application Proxy as an additional endpoint to your Azure Traffic Manager profile, or to the back-end pool of the load balancer.

Tip!
Don’t forget to remove the IP address of the new Web Application Proxy from the HOSTS file on the machine you tested with…

A12 Monitor the new Web Application Proxy’s traffic and load

As you put the Web Application Proxy server in use, monitor its traffic using Azure AD Connect Health to see if your load balancer and/or Azure Traffic Manager profile is indeed flowing authentication requests to it. Monitor the CPU and memory on the new Web Application Proxy to assure the load is as expected.

 

Decommissioning the old Web Application Proxy Server(s)

Now that the new Web Application Proxy server is running as it should, we can decommission any Web Application Proxy that is faulty, redundant, running a previous version of Windows Server or you want to get rid of for some other reason.

Perform these actions to decommission a Web Application Proxy:

A13 Remove the Web Application Proxy from the pool

Remove the Web Application Proxy as an endpoint from your Azure Traffic Manager profile, or from the back-end pool of the load balancer.

Monitor traffic to the Web Application Proxy server to make sure no more authentication requests are sent to the host.

A14 Remove the Web Application Proxy from ConnectedServers

The ConnectedServers list in the Web Application Proxy configuration determines which servers are valid Web Application Proxies. Removing a server here, actively removes it as a Web Application Proxy from the AD FS farm.

To gather this information, you need to run the following lines on a Web Application Proxy:

(Get-WebApplicationProxyConfiguration).ConnectedServersName

To remove the Web Application Proxy server, specifically specify the Web Application Proxy servers that are to remain by listing them and separating them with commas in the below line of Windows PowerShell:

Set-WebApplicationProxyConfiguration -ConnectedServersName <commaseparatedlistofWAPsinFQDNs>

A15 Remove the Web Application Proxy role

Now, we can uninstall the Web Application Proxy role from the Web Application Proxy server. Perform the following line of Windows PowerShell to do so:

Uninstall-WindowsFeature Web-Application-Proxy

A16 Remove the Web Application Proxy from the ConnectedServers list

Uninstalling the feature, however, does not remove the Web Application Proxy from the AD FS Farm. From another Web Application Proxy, you’ll notice the server is still in the ConnectedServersName list:

(Get-WebApplicationProxyConfiguration).ConnectedServers

Remove it using the following Windows PowerShell script:

$WapToRemove = "OldWap.domain.tld"

$WAPs = ((Get-WebApplicationProxyConfiguration).ConnectedServersName) –replace $WapToRemove


Set-WebApplicationProxyConfiguration
-ConnectedServersName $WAPs

A17 Remove infrastructure services

As you now have decommissioned the Web Application Proxu server, make sure to also remove it from monitoring, logging, backup, anti-malware and other infrastructure management services your organization leverages.

A18 Remove the server from the domain

If the Web Application Proxy is a member of the Active Directory domain, remove it from the Active Directory domain using the following line of Windows PowerShell and specifying an Active Directory account that has sufficient (delegated)permissions to remove a computer from Active Directory:

$Cred = Get-Credential

Remove-Computer –UnjoinDomaincredential $cred -PassThru -Verbose -Restart

Afterward, remove the computer account for the server from Active Directory and DNS.

 

After you have decommissioned a Web Application Proxy Server

After you have decommissioned a Web Application Proxy server, answer this question:

Q8 Is this the last Web Application Proxy running this version?

Web Application Proxy servers run in a configuration version, depending on the oldest Windows Server version used by Web Application Proxy servers in the AD FS farm. When the last Web Application Proxy server running a previous version of Windows Server is removed from the AD FS farm, the configuration version can be upgraded with action A19.

After you decommission an AD FS server, answer these questions:

A19 Upgrade the Configuration version

When all Web Application Proxy servers running a previous version of Windows Server have been decommissioned, you need to upgrade the configuration version to be able to continue managing the Web Application Proxy servers.

Use the following line of Windows PowerShell to do so:

Set-WebApplicationProxyConfiguration –UpgradeConfigurationVersion

 

Concluding

The above approach is our real-world tested approach to transitioning Web Application Proxy Servers, based on projects with our customers.

Enjoy!

Series Navigation

<< A Real-world tested Approach for Transitioning AD FS Servers

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.