Pages

Tuesday, April 21, 2020

Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019

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:

image

Click Next:

image

Select Role-based or feature-based installation and click Next:

image

Leave the Select a server from the pool radio button selected and click Next:

image

Select Remote Access and click Next:

image

Leave the Features as default and click Next:

image

The Remote Access window will be displayed providing a description of the service. Proceed and click Next:

image

The following Add Roles and Features Wizard window will be displayed to display the tools that will be installed onto the server:

image

Select the Web Application Proxy role and click Next:

image

A restart isn’t usually necessary so you can leave the radio button for that option unchecked and then click on Install:

image

The Web Application Proxy and dependent components will proceed to install:

imageimage

You will be presented with a Welcome wizard once the installation completes. Proceed by clicking on the link to launch the configuration:

image

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

imageimage

Select the SSL certificate that has been installed onto the Local Computer certificate store:

image

Proceed with the configuration by clicking on the Configure button:

image

The configuration will begin:

image

Once the configuration completes, click on the Close button:

image

The Remote Access Management Console should automatically launch listing the server name on the left window:

image

Click on the Publish button on the right window:

image

Click Next to proceed:

image

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)

image

image

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.

image

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):

image

image

image

Option #2: Pass-through

image

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):

image

image

Proceed with publishing the application by clicking on the Publish button:

image

Close the wizard when completed:

image

You should now see the newly published ADFS web application in the Published Web Applications window:

image

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:

image

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

image

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.

image

1 comment:

Expat Wife Escapades said...

This is a great post, thanks