Performing a simple Hybrid Identity implementation with AD FS on-premises

Hybrid Identity

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:

SimpleADFS

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 adfs1.domain.tld

 

DNS Records

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

Add-DNSServerResourceRecordAIPv4Adddress 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. Smile

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-SecureStringString 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-SecureStringString 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-WebApplicationProxyCertificateThumbprint $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.

Azure AD Connect - User sign-in

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

Azure AD Connect - Connect to Azure AD

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

Azure AD Connect - Connect your directories

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.

Azure AD Connect - Azure AD sign-in configuration

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.

Azure AD Connect - Uniquely identifying your users

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.

Azure AD Connect - Optional Features

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.

Azure AD Connect - AD FS farm

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.

Azure AD Connect - Verify Azure AD Domain

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.

Azure AD Connect - Verified Azure AD Domain

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.

Azure AD Connect - Ready to configure

On the Ready to configure screen, click Install.

On the Configuration complete screen, click Next.

Azure AD Connect - Verify federation configuration

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! Thumbs up

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.

4 Responses to Performing a simple Hybrid Identity implementation with AD FS on-premises

  1.  

    Three questions.

    Why the ‘enterpriseregistration’ and ‘certauth’ fqdn in the cert?

    In AD FS 2.0 the AD FS service account needed Read permission on the private key of the AD FS certificate, is this not necessary anymore?

    Why not also enable password sync for ‘back-up’ auth when AD FS is totally lost?

    • Hi,

      When, in a later stage you’d want to enable the AD FS Device Registration Service (DRS) or when you want to fully enable Windows 10-based clients, you’ll need the two DNS names in the certificate. I feel people are tempted to choose a certificate for just the DNS name of the AD FS farm during every AD FS implementation. However, when at a later stage they feel they need the Subject Alternative Name (SAN) certificate, with most certification authorities they can’t get the original certificate refunded, while the SAN certificate can be reissued during its (commercial) lifetime. Also note that wildcard certificates only cover hostnames one level deep, so the certauth DNS name won’t be covered.

      The steps described are the steps needed. There are no additional steps needed for the gMSA to pick up the certificate.

      Most organizations we work with choose AD FS, because they don’t want their users’ passwords stored in any other identity system than their own Active Directory or LDAP store. We don’t see customers choose the Password Hash Sync (PHS) authentication method and the federated authentication method. Organizations tend to choose one, not both. In dire situations, though, it’s possible to generate passwords for all synchronized user objects in Azure Active Directory using a couple of PowerShell Cmdlets. This information can be mail merged and then sent out. Also, organizations that implement Web Application Proxies often want to publish on-premises web apps, making AD FS useful in more than one way, where PHS would only provide a failover situation for cloud access.

       
  2.  

    What if the external zone name and the internal AD domain name are different?

    Must the AD domain name be a publicly registered domain name?

    Can you have DNS name values or SAN values that are not publicly resolvable?

    • Hi John,

      The external DNS domain and the internal AD domain DNS domain can be different. In this case, however, you would have to take care of some additional things. For instance, the best practice is to add the external DNS domain name as an additional UPN suffix and then change it for the user accounts in scope of synchronization and federation. Alternatively, you can use Alternate Login ID, but this limits the Microsoft online services you can consume. Of course, DNS itself also requires some more configuration.

      The AD Domain Name does not have to be a publicly registered domain name, but it is highly recommended by Microsoft when you want to consume cloud services in the most efficient way. The days of .local top level domain names for new Active Directory domains in today’s cloud world, indeed, are numbered.

      You cannot request certificates with DNS names that are not publicly resolvable from publicly-trusted Certification Authorities (CAs) for certificates with expiration dates beyond November 1, 2015. (Read More). You cannot use a certificate from a publicly-trusted CA, but you can request and use certificates from your own internal CA. However, this certificate will not work for all components of your Hybrid Identity implementation and you limits the ability to use Single Sign-On on devices that trust your Root CA.

       

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.