In Part 1 we installed the internal AD FS Server, to publish these federation services to the internet, now we also need to install an AD FS Reverse Proxy server in our perimeter network.

Therefore we have to install the Web Application Proxy (WAP) and Remote Access server role on a Windows Server 2019 in the perimeter network as follows.

Install the Federation Service Proxy Role Service
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/install-the-federation-service-proxy-role-service

To install the Federation Service Proxy role service using PowerShell
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/install-the-federation-service-proxy-role-service#to-install-the-federation-service-proxy-role-service-using-powershell

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools



This post is split into multiple parts

Part 1 … will cover the installation from the internal ADFS Server

Part 2 … will cover the installation from the ADFS Reverse Proxy Server in the perimeter network

Part 3 … will cover all about certificates for an ADFS environment

Part 4 … we will create an ASP.NET Web Application (.NET Framework -Web Forms) and configure it to be claim aware using WS-FED.

Part 5 … we will create an ASP.NET Core Web Application (MVCs) and configure it to be claim aware using WS-FED.

Part 6 … we will create an ASP.NET Web Application (.NET Framework – MVC) and configure it to be claim aware by using OAuth 2.0 and OpenID Connect.

Part 7 … we will create an ASP.NET Core Web Application (MVC) and configure it to be claim aware by using OAuth 2.0 and OpenID Connect.

Part 8 … will explain and list all identity protocols, AD FS supports.



I will use here also the Server Manager to install the AD FS Proxy role in Windows Server 2019.

Therefore I have to install the Remote Access server role.


Select Web Application Proxy and add the required features.


To configure the Web Application Proxy we can click on the link inside the Add Roles and Features Wizard.


Here we need to enter the Federation service name from our internal ADFS Server.


The Federation service name is the FQDN you entered for the internal ADFS server and can be determined when you click on the Edit Federation Service Properties … inside the AD FS console from the internal ADFS server as follows.



We also need to enter the credentials of a local administrator account on the internal federation server.

I will use here the default local administrator account from the internal federation server.


AD FS Requirements
https://docs.microsoft.com/en-gb/windows-server/identity/ad-fs/overview/ad-fs-requirements#BKMK_1

Each AD FS and Web Application Proxy server has an SSL certificate to service HTTPS requests to the federation service. The Web Application Proxy can have additional SSL certificates to service requests to published applications.

Recommendation: Use the same SSL certificate for all AD FS federation servers and Web Application proxies



Here we should use the same SSL certificate as for the internal federation server.

If the federation service should interact with external third party provider, solutions or partners, you should use a public certificate from a trusted CA. Otherwise they will not trust your federation services.





After closing the wizard the Remote Access Management Console is automatically opened.



From now on the AD FS Proxy server will work and publish the authentication services to internet based clients.

Clicking on Operations Status will show us that it is working properly and everything is fine.



As described in Part 1, we can now test if we can sign-in from an internet based client. Therefore of course first the FQDN from the federation service name should point to the right public IP which you have published on your front firewall for HTTP and HTTPS traffic inbound to the ADFS Proxy server.

Verify the ADFS Sign-In Page
https://fs.braintesting.de/adfs/ls/idpinitiatedsignon.htm

AD FS Troubleshooting – Idp-Initiated Sign On
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon

The AD FS sign-on page can be used to test whether or not authentication is working. This is done by navigating to the page and signing in. Also, we can use the sign-in page to verify that all SAML 2.0 relying parties are listed.



Looks fine …


Links

AD FS Help
https://adfshelp.microsoft.com/

AD FS – Testing claims rules without deploying a sample app
https://social.technet.microsoft.com/wiki/contents/articles/39541.ad-fs-testing-claims-rules-without-deploying-a-sample-app.aspx



In Part 3 we will see the requirements for the different certificates we use in an ADFS environment.