As a follow up to my previous post demonstrating the deployment of a redundant Active Directory Federation Services (ADFS) Farm on Windows Server 2019:
Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html
This post serves to demonstrate the deployment of the internet facing ADFS Web Application Proxy servers.
Prerequisites
Servers:
Prepare 2 x Windows Server 2019 servers that will serve as the ADFS Web Application Proxy servers located in a DMZ network (these servers does not have to be joined to the domain and I typically suggest they reside in a workgroup unless there is a compelling reason to join them to the domain)
Certificate:
You can use the same certificate that you used for your internal ADFS servers that contain the FQDN for your ADFS deployment (e.g. fs.contoso.com)
DNS:
During the deployment:
I’ve had inconsistent results during the deployment if the WAP server connects to a internal ADFS server in the farm that hosts a secondary read only copy of the WID so begin by configuring the WAP server to connect directly to the internal ADFS server that host the primary writable WID database.
After the deployment:
Determine how you will be configuring the ADFS Web Application Proxy servers’ DNS settings.
Scenario #1 – Using your internal Active Directory DNS servers
If you are using your internal Active Directory DNS servers, which will serve the IP address of either your load balancer that load balances the internal ADFS server farm, then no action is required as the Web Application Proxy servers will properly resolve the IP required to get to the internal farm.
Scenario #2 – Using your external DNS servers
If these DMZ servers are not going to use your internal Active Directory DNS servers to perform lookups and/or using a DNS service that is unaware of the internal IP address for the fs.contoso.com address then you would either create a record on these DNS servers (if you manage them) or use host records on the Web Application Proxy servers to force traffic to fs.contoso.com to the load balancer so communication can be established between them and the internal ADFS server farm.
In addition to the above scenarios, you will need to create an external DNS entry for the FQDN of your ADFS Web Application Proxy (e.g. fs.contoso.com) that points to your internet facing firewall, which will then NAT the IP into a load balancer to load balance the ADFS Web Application Proxy servers.
Deploying the first ADFS Web Application Proxy server
Begin by launching server manager and clicking on Add roles and features:
Click Next:
Select Role-based or feature-based installation and click Next:
Leave the Select a server from the pool radio button selected and click Next:
Select Remote Access and click Next:
Leave the Features as default and click Next:
The Remote Access window will be displayed providing a description of the service. Proceed and click Next:
The following Add Roles and Features Wizard window will be displayed to display the tools that will be installed onto the server:
Select the Web Application Proxy role and click Next:
A restart isn’t usually necessary so you can leave the radio button for that option unchecked and then click on Install:
The Web Application Proxy and dependent components will proceed to install:
You will be presented with a Welcome wizard once the installation completes. Proceed by clicking on the link to launch the configuration:
Fill out the following fields:
Federation service name - Enter the fully qualified domain name (FQDN) of the AD FS server (e.g. fs.contoso.com)
User name and Password - An account with location administrator permissions on the internal ADFS server
Select the SSL certificate that has been installed onto the Local Computer certificate store:
Proceed with the configuration by clicking on the Configure button:
The configuration will begin:
Once the configuration completes, click on the Close button:
The Remote Access Management Console should automatically launch listing the server name on the left window:
Click on the Publish button on the right window:
Click Next to proceed:
I feel that most material available on the internet demonstrating the deployment of a WAP server are never very clear on this step so I’d like to try providing a bit more information for the differences between the following preauthentication methods.
Active Directory Federation Services (AD FS)
This preauthentication method will always direct the traffic for the published application to the AD FS server so the user requesting the traffic will be authenticated by your internal ADFS server farm. There are also 3 different types of preauthentication when you select this option and they are:
- Web and MSOFBA
- HTTP Basic
- OAuth2
Which option you should select depends on the requirements of the application you’re publishing so review the following article and determine the correct method:
Publishing Applications using AD FS Preauthentication
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/web-application-proxy/publishing-applications-using-ad-fs-preauthentication
In the document from the link above, scroll down to the following headings:
- Publish an Application that uses MS-OFBA
- Publish an Application that uses HTTP Basic
- Publish an Application that uses OAuth2 such as a Microsoft Store App
An example of when you would need to select this option is if you are configuring AD FS claims-based authentication with Outlook on the web. If you select Pass-through preauthentication then you would have effectively bypassed ADFS sending the authentication back to the Exchange server.
Pass-through
This preauthentication method will directly send the traffic for the published application to the backend server and bypasses the internal AD FS server farm. What this means is that if you are publishing a web application that leverages AD FS for authentication then you have effectively bypassed it and sent the user or application to authenticate to the application server.
One of the common questions I’ve been asked in the past is which of the above should you be selecting if you are publishing ADFS so you can have users accessing Office 365 to authenticate against it and the short answer is both would work because the target server for the traffic redirected from Office 365 to your WAP server is destined for the ADFS server. Selecting Active Directory Federation Services (AD FS) or Pass-through would send the traffic essentially to the same place.
Please refer to the following documentation for more information on the differences as this setting cannot be changed afterwards but you can always remove and recreate the published application:
Publish Applications using AD FS Preauthentication
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383640(v=ws.11)
Publish Applications using Pass-through Preauthentication
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383639(v=ws.11)
I’ll include the screenshots for using both options to demonstrate what the configuration looks like.
Option #1: Active Directory Federation Services (AD FS)
Note that the Microsoft Office 365 Identity Platform Worldwide option would only be displayed if you have already confirmed this in the ADFS farm. If you are publishing other applications then you will need to make sure configure them in the ADFS farm before you attempt to publish them.
Enter a logical name for the web application, the FQDN for the external URL, select the SSL certificate that has been imported into the Local Computer certificate store, determine whether you want to enable HTTP to HTTPS redirection, and finally enter the backend internal ADFS farm’s URL (this will be same as the external URL for this design):
Option #2: Pass-through
Enter a logical name for the web application, the FQDN for the external URL, select the SSL certificate that has been imported into the Local Computer certificate store, determine whether you want to enable HTTP to HTTPS redirection, and finally enter the backend internal ADFS farm’s URL (this will be same as the external URL for this design):
Proceed with publishing the application by clicking on the Publish button:
Close the wizard when completed:
You should now see the newly published ADFS web application in the Published Web Applications window:
Repeat the previous steps for the second ADFS Web Application Proxy server and you should see the additional server listed in the Remote Access Management Console:
There is no need to publish the application twice if you have multiple Web Application Proxies as the publication of the application will automatically be configured on the other servers.
Event Logs
The following are event log entries that will be logged on the internal ADFS server when the Web Application Proxy Server successfully connects to the internal ADFS farm:
Log Name: AD/FS Admin
Source: AD FS
Event ID: 395
Level: Information
The trust between the federation server proxy and the Federation Service was established successfully using the account 'contoso\tluk'.
Proxy trust certificate subject: CN=ADFS ProxyTrust - ADFSWAP1.
Proxy trust certificate thumbprint: 1A2A8768073DB880E2ED086E8226848F129E4DB
Log Name: AD/FS Admin
Source: AD FS
Event ID: 396
Level: Information
The trust between the federation server proxy and the Federation Service was renewed successfully.
Proxy trust certificate subject: CN=ADFS ProxyTrust - ADFSWAP1.
Proxy trust certificate old thumbprint: 1A2A8768073DB880E2ED086E8226848F129E4DBE.
Proxy trust certificate new thumbprint: 18F8E09B827F49D23073BE398E8D9BF643D8AF75.
