Reading Time: 9 minutes

In this blogpost, I’ll explain how to install and configure Active Directory Federation Services (AD FS) and Azure AD Connect to achieve Hybrid Identity with Azure Active Directory, based on Windows Server 2016.

The implementation outlined in this blogpost is relevant for one on-premises datacenter and an Active Directory Domain Services environment, consisting of one Active Directory domain. We’ll try to keep this as simple as possible, so we’ll make the following choices:

• We won't deploy the AD FS Servers in a redundant/high-available fashion
• We’ll use Windows Internal Database (WID) to host the AD FS Configuration database
• We wont deploy the Web App Proxies in a redundant/high-available fashion
• We’ll use an AD FS service communications certificate issued by a publicly-trusted Certification Authority (CA).

 

Before you begin

Before you begin, you should have access to the following information:

• The DNS domain name of your organization’s Active Directory Domain Services (AD DS) environment
• Credentials for an Enterprise Admin account in the AD DS environment
• Credentials to access the DNS zone of the DNS Domain Name of your organization

Of course, it’s a good idea to make a back-up of your Domain Controllers and test one of the backups in a separate networking environment to make sure you’re able to restore.

Requirements

Before you can implement Hybrid Identity, based on Windows Server 2016, your environment needs to comply with these requirements:

• The Active Directory schema needs to be at least Windows Server 2016.
• Your organization needs at least one Windows Server 2012-based (or up) Active Directory Domain Controller
• The Active Directory Domain Services Domain Functional Level needs to be at least Windows Server 2008 R2.

Overview

In the blogpost, we’ll implement the following:

Step 1: Configuring Active Directory

Service Accounts

Before we can setup Hybrid Identity, we need to create a service accounts. We’ll use a group Managed Service Accounts (gMSAs) for AD FS, because it offers the best security.

Run these two elevated PowerShell one-liners:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

New-ADServiceAccount ADFSgMSA –DNSHostName adfsgmsa.domain.tld

 

DNS Records

Next up, we’ll configure the internal DNS records for the AD FS Farm Name:

Add-DNSServerResourceRecordA –IPv4Adddress 10.0.0.5 -Name sts -ZoneName domain.tld

 

Step 2: Setting up the AD FS Server

About AD FS

Active Directory Federation Services (AD FS) can be seen as an add-on to Active Directory Domain Services (AD DS). AD DS offers single sign-on for on-premises functionality like file servers and printer servers, leveraging protocols like NTLM and Kerberos. AD FS also offers single sign-on, but based on standards like WS-Federation, SAML, Oauth2 and SCIM. AD FS can be used to provide single sign-on to (web) applications on-premises, but it is particularly useful for cloud-based (web) applications.

The AD FS server is the component that performs the security translation between the ‘old’ protocols and the new standards. In the RFCs, it is referred to as a Security Token Service (STS).

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring AD FS.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

AD FS Role

To install the AD FS role, run the following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

AD FS Service Communications certificate

AD FS requires a certificate.

On a Windows or Windows Server installation, simply create a certificate request for a certificate with the following DNS subjects:

• CN=sts.domain.tld
• DNS=sts.domain.tld
• DNS=enterpriseregistration.domain.tld
• DNS=certauth.sts.domain.tld

Make sure you create a certificate request for a certificate with the SHA-2 hashing algorithm, a 2048-bit key length (or longer) and a legacy key pair.

You can use any Certificate Authority (CA) you’d like, but I recommend certificates issued by Let’s Encrypt for the AD FS service communications certificate. Let’s Encrypt is a free, automated, and open Certificate Authority (CA).

Submit your certificate request, pass the validation checks and then receive a perfectly valid TLS certificate for free.

I installed the certificate on the box where I requested it. Then I exported it and protected the key material with a password. I copied it the hard disk of the AD FS Server where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureString –String "YourPasswordHere" –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

After the role is installed and the certificate is installed, we can configure AD FS, using the following PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.domain.tld"}).Thumbprint

Install-AdfsFarm -CertificateThumbprint $thumb -FederationServiceName sts.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$

Restart-Computer

The AD FS Server is setup after it comes online.

 

Step 3: Setting up the Web Application Proxy

About the Web Application Proxy

To use AD FS with Azure Active Directory, we need to publish it publicly, or at least to Microsoft. Microsoft recommends to use the Web Application Proxy role to publish AD FS publicly. Yes, you could make the previously configured AD FS Server to the Internet, but this is not recommended.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation for the Web Application Proxy, too. This time, however, it’s located on a perimeter network, if your organization has any.

The server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring it as a Web Application Proxy.

Log on as a local admin and copy the certificate over to this server.

Then, install the role, using the  following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

I copied the exported certificate to the hard disk of the Web Application Proxy where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureString –String "YourPasswordHere" –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

Now that the role is installed and the certificate is installed, we can configure the Web Application Proxy, using the following two PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.domain.tld"}).Thumbprint

Install-WebApplicationProxy –CertificateThumbprint $Thumb -FederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.

 

Step 4: Setting up Azure Active Directory

About Azure Active Directory

Azure Active Directory is Microsoft’s cloud-based Identity Management as-a-Service solution. It offers single sign-on access to Office 365 and over 2800 other cloud apps and services from the likes of Google and Amazon.

Setup the Azure AD tenant

We’ll configure a new Azure Active Directory tenant, by leveraging the Office 365 trial wizard. This wizard allows you to create an Azure Active Directory tenant without the need of a credit card.

Follow the link above and register the tenant. Do not forget to write down the password for the built-in tenant administrator account somewhere safe.

Connect to the tenant

Next, let’s connect to the tenant. Use an elevated PowerShell session and type the following one-liner to install the Azure Active Directory PowerShell Module:

Install-Module AzureAD

Press Yes twice. Now, Let’s put it to action to log into our tenant using the bootstrap/fallback admin account we created when we created the tenant:

Connect-AzureAD

In the pop-up authentication window, type your username and press Next. Then, in the password stage, enter the password and press Sign in.

Configure your DNS domain name

Next, configure your DNS domain name:

New-AzureADDomain -Name domain.tld -IsDefault $true

Your Azure AD Tenant is now ready to go.

 

Step 5: Setting up Azure AD Connect

About Azure AD Connect

Azure AD Connect is Microsoft’s free bridge between Active Directory Domain Services (AD DS) and Azure Active Directory. It helps organizations make themselves known towards Microsoft as a tenant by synchronizing objects and attributes and configuring synchronization and sign-in options.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with downloading, installing and configuring Azure AD Connect.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

Download Azure AD Connect

Use a browser to download the latest version of Azure AD Connect to disk.

Install and configure Azure AD Connect

Double-click the AzureADConnect.msi file.

After the initial installation, you will begin configuring Azure AD Connect, automatically. In the Welcome to Azure AD Connect screen, select the I agree to the license terms and privacy notice option and click Continue.

In the Express Settings screen, click Customize.

Note:
When we would’ve used Express Settings, one of the configuration outcomes would have been PAssword Hash Synchronization (PHS) as the Sign-in option.

Click Install on the Install required components screen.

In the User sign-in screen select Federation with AD FS as the sign on method.
Click Next.

In the Connect to Azure AD screen, enter the username and password for the Azure AD bootstrap/fallback account. Click Next when done.

In the Connect your directories screen, click the Add Directory button. In the AD Forest account pop-up window, specify a user account with at least Domain Admin credentials for the Active Directory domain you want to add, or a user account with at least Enterprise Admin credentials, when you want to add an entire Active Directory forest. Press OK when done. Then, press Next on the Connect your directories screen.

In the Azure AD sign-in configuration screen, click Next to accept the userPrincipalName attribute as the on-premises attribute to use as the Azure AD username.

Press Next in the Domain and OU filtering screen to accept synchronizations of all domains and organizational units (OUs) within the connected Active Directory.

Note:
Some objects will not be synchronized by default, like the built-in Administrator account and other privileged accounts when these privileges stem from memberships to well-known privileged groups, like the Domain Admins and Account Operators groups.

In the Uniquely identifying your users screen, click Next.

In the Filter users and devices screen, click Next. to Synchronize all users and devices instead of creating a pilot group for synchronization.

In the Optional features screen, click Next.

In the Domain Administrator Credentials screen, enter the username and password of a user account in the Active Directory Domain Services environment where AD FS will be managed with Domain Admin privileges. Click Next when done.

In the AD FS farm screen, select Use an existing AD FS farm. In the SERVER NAME field, enter adfs1.domain.tld, or use the Browse button to select the AD FS server from Active Directory. Click Next when done.

In the Azure AD Domain screen, select the DNS domain name that you wish to federate from the dropdown list.

Now, we face the challenge of verifying our DNS Domain Name. In your external DNS zone, implement the following DNS records:

• The above TXT or MX record as shown in Azure AD Connect
• An A record for sts.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server
• An A record for enterpriseregistration.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server.

Also, this is a good time to make sure traffic is allowed from the Internet to the Web Application Proxy, using TCP 443. Open up this firewall port when you haven’t yet. The time this takes makes sure the DNS records are populated and visible, as this tends to take some time at some DNS providers…

Then, click the green Verify Domain button, next to the DNS domain name.

Eventually, you’ll receive the message that your DNS Domain name is now a managed domain that will be converted into a federated domain. Click Next.

On the Ready to configure screen, click Install.

On the Configuration complete screen, click Next.

On the Verify federation configuration screen, select the I have created DNS A records that allow clients to resolve my federation service from both the intranet and the extranet. option. Then, click Verify to verify name resolution of the AD FS Farm using external DNS and access to the AD FS Farm using TCP 443.

After successful verification, click the Exit button.

You can now use Azure Active Directory with Single Sign-On.

 

Concluding

Congratulations!

You have setup Hybrid Identity using Active Directory Federation Services (AD FS) as the sign-in option. Now you can use this new piece of infrastructure to rollout Microsoft Intune, give your colleagues access to Microsoft Office 365 or over 2800+ applications that are ready to integrate with Azure Active Directory, all without the hassle of logon prompts and disparate passwords between solutions.

Note:
For the AD FS Server and the Web Application Proxy, you can use Windows Server version 1709 or other Server Core installations, too, even though the above blogpost only mentions Windows Server 2016.