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:
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.
Some settings are configured, by default, when you add a Web Application Proxy server, while others require manual migration:
By default, the following settings and configuration items are automatically provisioned on additional Web Application Proxy servers to the same AD FS farm:
By default, the following settings and configuration items are automatically provisioned on additional Web Application Proxy servers to the same AD FS farm:
However, important parts need to be migrated or configured manually:
To transition Web Application Proxy servers, it’s a good idea to create an inventory beforehand. Answer these questions:
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.
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
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.
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.
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
Use the following line of Windows PowerShell to find any additional routes that the current Web Application Proxy server(s) use:
Get-NetRoute
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.
Implementing the new Web Application Proxy is easy. Simply create a new (virtual) machine with your favorite supported Windows Server version on it.
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:
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.
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.
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.
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.
Run the following lines of Windows PowerShell to install the Web Application Proxy feature:
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
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).
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.
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:
The Web Application Proxy is now ready for use.
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:
These technical and functional tests verify that the Web Application Proxy is functioning properly to meet your organization’s needs.
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…
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.
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:
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.
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 ommaseparatedlistofWAPsinFQDNs>
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
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:
Remove it using the following Windows PowerShell script:
$WapToRemove = "OldWap.domain.tld"
$WAPs = (( Get-WebApplicationProxyConfiguration ).ConnectedServersName) – replace $WapToRemove
Set-WebApplicationProxyConfiguration -ConnectedServersName $WAPs
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.
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, answer this question:
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:
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
The above approach is our real-world tested approach to transitioning Web Application Proxy Servers, based on projects with our customers.
Enjoy!