With the COVID-19 pandemic ravaging business globally over the past two months, many organizations have been rushing to deploy or scale up their previously piloted collaboration products to full production. One of the clients I worked with had an immediate need to leverage the free trial Microsoft Teams licenses Microsoft was providing to organizations and as this organization did not have an Office 365 tenant setup, the first step was to set one up and decide how they want users to authenticate. The decision was made to use Active Directory Federation Services as they wanted to keep the authentication traffic directed to their on-premise infrastructure, which leverages DUO multi-factor authentication. I'll be writing a series of blog posts as I deploy an ADFS farm, Citrix ADC for load balancing, DUO integration, and AD Connect with ADFS for authentication. This post will outline the process of deploying a redundant ADFS infrastructure. The operating system I'll be using for this deployment is Windows Server 2019, which is ADFS version 4.0.
Prerequisites
Servers:
Service Account:
You will need to decide the type of service account to use for the ADFS farm. The options are to use a Group Managed Service Account (recommended) or an existing user domain account (the traditional method). Review the following documentation for more information:
Manually Configure a Service Account for a Federation Server Farm https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/manually-configure-a-service-account-for-a-federation-server-farm
Database:
You will need to decide whether to use WIN (Windows Internal Database) or SQL Server database for the farm. There are advantages and disadvantages for each option so please review the following documentation for more information:
The Role of the AD FS Configuration Database https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-ad-fs-configuration-database
Certificate:
You will need a certificate with the FQDN for your ADFS deployment and optionally a subject alternative name for the subdomain certauth.<yourFQDN>. Using a certificate with the SAN name would allow device authentication and user certificate authentication to connect to the ADFS server via port 443 at different FQDNs (e.g. fs.contoso.com and certauth.fs.contoso.com). Not using a certificate with the certauth.<yourFQDN> SAN entry will create an additional binding on port 49443 on the same FQDN for user certificate authentication.
More detail can be found at the following Microsoft documentation:
AD FS support for alternate hostname binding for certificate authentication https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-support-for-alternate-hostname-binding-for-certificate-authentication
DNS:
Deploying the first ADFS 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 Active Directory Federation Services and click Next:
Leave the Features as default and click Next:
The Active Directory Federation Services window will be displayed providing a description and links for documentation. Proceed 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 feature will proceed to install:
You will be presented with the link Configure the federation service on this server. once the installation completes. Proceed by clicking on the link to launch the configuration:
This is the first ADFS server in the farm so leave the radio button Create the first federation server in a federation server farm selected and click Next:
Ensure that you are logged in as a domain administrator for the install and if not, change the account to one that has permissions then click Next:
Proceed to select the certificate if you have already imported one onto the server's Local Computer store or use the Import button to import a certificate from the wizard, enter the FQDN you'll be publishing ADFS service and finally a logical name for the organization that would be displayed on the ADFS portal login page:
As shown in the warning banner presented, the KDS Root Key has not been configured for the use of a Group Managed Service Accounts but for the purpose of this deployment, we'll be using a traditional service account:
We'll be using a WIN database for this deployment:
A summary of the deployment will be displayed, proceed by clicking Next:
A prerequisites check will be made and if all are met then proceed by clicking on Configure:
Note that the certificate I used did not have the SAN entry certauth.<FQDN> so the warning message about configuring an additional binding pn port 49443 is created:
The SSL certificate subject alternative names do not support host name 'certauth.domain.com'. Configuring certificate authentication binding on port '49443' and hostname 'fs.domain.com'.
Once the server has been successfully configured, you may receive the additional warning message depending on what your internal domain is:
The SSL certificate does not contain all UPN suffix values that exist in the enterprise. Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices. For more information, see http://go.microsoft.com/fwlink/?LinkID=311954
The reason why this message will be displayed is because the organization in this example uses a domain with the suffix .local, which is a non-internet routable TLD (top level domain) and therefore the certificate does and cannot have this FQDN as a name. This can be safely ignored as you would be using a routable domain such as the one for your email address.
Click on the Close button to complete the configuration.
Before proceeding to deploy the second ADFS server for the farm, I usually proceed to test the functionality of the newly deployed ADFS server to verify it is in good health. Aside from reviewing the event logs, one of the ways to validate the functionality is to turn on the sign on page, which used to be enabled in previous ADFS versions but is now disabled by default.
Begin by confirming that the sign on page is disabled, enable it, then configure that it is enabled.
Use the following cmdlet to determine whether the sign on page is enabled:
Get-AdfsProperties |Select-Object *EnableIdp*
Use the following cmdlet to enable the sign on page:
Set-AdfsProperties -EnableIdpInitiatedSignonPage $True
Use the following cmdlet to confirm that the sign on page is enabled:
Get-AdfsProperties |Select-Object *EnableIdp*
**If you do not have the load balancer set up yet then you will either need to modify the internal DNS entry for fs.contoso.com to point directly to the first ADFS server or use a host record on the computer you intend to test the sign on page.
Launch a browser and navigate to the following URL to verify that a sign on page is presented, then click on Sign in:
https://fs.contoso.com/adfs/ls/idpinitiatedsignon.htm
Proceed to sign in with domain credentials and verify you are able to successfully sign in successfully:
Deploy the second redundant ADFS Server
With the health of the first ADFS server verified, repeat the same deployment procedure on the second ADFS server but select Add a federation server to a federation server farm during the install as shown in the screenshot below:
Ensure that you are using an account with domain administrator permissions:
If you deployed the first ADFS server with a WIN database then proceed by filling in the Primary Federation Server name with the FQDN of the server (e.g. svr-adfs-01.internaldomain.com). If the deployment uses a SQL server then select Specify the database location for an existing farm using SQL Server and enter the SQL database information:
Select an imported SSL certificate (same one you used for the first server) or import it if it hasn't already been placed into the Local Computer certificate store:
As mentioned during the deployment of the first server, we will be using a traditional service account for the deployment:
A summary of the deployment will be displayed:
The deployment will commence:
Proceed with the configuration once the prerequisites check has completed successfully:
You'll see similar warning messages as the first deployment:
Click on the Close button when the installation has completed:
This concludes the deployment of the internal ADFS servers farm. The next post will outline the deployment of the Web Application Proxy servers.