Deploying Azure AD Connect for Office 365 with AD FS for authentication

One of the methods for providing authentication for Office 365 services is to redirect users back to an on-premise AD FS (Active Directory Federation Services) portal so that authentication can be handled by the local infrastructure with Domain Controllers. Some organizations prefer this route because they may already have AD FS setup for multiple services with a MFA solution configured and would like to unify authentication requests to their on-premise infrastructure because they have yet to migrate their infrastructure to the Azure cloud. In other instances, the organization may already have most of their infrastructure migrated to the Azure cloud but would like to leverage the additional capabilities of AD FS. I won’t go into the details of each option but refer to the following documentation for more information:

Azure AD Connect user sign-in options
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-user-signin#federation-that-uses-a-new-or-existing-farm-with-ad-fs-in-windows-server-2012-r2

I’ve come across many organizations who have their AD Connect installed on a domain controller but it is actually not recommended by Microsoft:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites

Installing Azure AD Connect on a Domain Controller is not recommended due to security practices and more restrictive settings that can prevent Azure AD Connect from installing correctly.

Other security concerns are as follows:

• Restarts of the server for troubleshooting AD Connect would affect domain controller services, DNS or other roles that may be on the server
• DR for domain controllers would not be as straightforward with the additional AD Connect service installed and the same will be for the AD Connect
• AD Connect installs a version of SQL Server 2012 Express Edition database which complicates the demotion of a domain controller if that is to be done in the future
• SQL Server 2012 is an additional component that can raise security concerns when on a domain controller
• Extra application or agent increases the attack surface (SQL Server are known for vulnerabilities)
• Azure AD Connect service accounts requiring administrative permissions are added locally to the server which means it would be placed into the Builtin\Administrators group thus resulting it having administrative privileges to the AD Domain
• Local install of SQL Server would consume additional memory thus resulting in extra memory consumption contending with the domain controller’s use of RAM to cache the ntds.dit database
• If the domain controller AD Connect is installed on is not a GC then that can cause issues

I would suggest reviewing the Microsoft provided documentation so that you can have the information required to make the best decision that meets the organization’s requirements.

With the above stated, the purpose of this post will be to demonstrate the process of installing and setting up Azure AD Connect to use AD FS as the user sign-in method for the organization on a Windows Server 2019 server with an already deployed AD FS on Windows Server 2019 farm.

For more information about deploying AD FS on Windows Server 2019, refer to my previous blog posts:

Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html

Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory_21.html

Custom Domain Prerequisite

Begin by ensure that the organization’s sign-in domain (typically the primary SMTP domain) has been added as a custom domain and verified with the required TXT record in your Azure tenant:

Proceed to download the latest Azure AD Connect from the Azure Active Directory portal:

In the event where the organization’s Active Directory domain is non-routable (e.g. contoso.local), you will need to prepare the domain for directory synchronization as outlined in the following documentation.

Prepare a non-routable domain for directory synchronization

https://docs.microsoft.com/en-us/office365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization

Install Azure AD Connect

Launch the downloaded AzureADConnect.msi file to start the installer:

Proceed to install Azure AD Connect:

Configure Azure AD Connect

I usually recommend to never go with Express settings as this configures Azure AD Connect with default settings, which most administrations may not go back to review the documentation to understand what it does and may have unanticipated consequences in the future.

I would like to encourage everyone who needs to set up AD Connect to go through all the following documentation that will outline the configuration parameters for a custom installation:

Custom installation of Azure AD Connect
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

Setting up AD FS for sign-in also is not available via the Express Settings so select the Customize button:

By leaving all of the optional settings unchecked, AD Connect will set up a SQL Server 2012 Express LocalDB instance, create the appropriate groups, and assign permissions without intervention. For more information about the optional settings, please refer to the following table:

Use an existing SQL Server	Allows you to specify the SQL Server name and the instance name. Choose this option if you already have a database server that you would like to use. Enter the instance name followed by a comma and port number in Instance Name if your SQL Server does not have browsing enabled. Then specify the name of the Azure AD Connect database. Your SQL privileges determine whether a new database will be created or your SQL administrator must create the database in advance. If you have SQL SA permissions see How to install using an existing database. If you have been delegated permissions (DBO) see Install Azure AD Connect with SQL delegated administrator permissions.
Use an existing service account	By default Azure AD Connect uses a virtual service account for the synchronization services to use. If you use a remote SQL server or use a proxy that requires authentication, you need to use a managed service account or use a service account in the domain and know the password. In those cases, enter the account to use. Make sure the user running the installation is an SA in SQL so a login for the service account can be created. See Azure AD Connect accounts and permissions. With the latest build, provisioning the database can now be performed out of band by the SQL administrator and then installed by the Azure AD Connect administrator with database owner rights. For more information see Install Azure AD Connect using SQL delegated administrator permissions.
Specify custom sync groups	By default Azure AD Connect creates four groups local to the server when the synchronization services are installed. These groups are: Administrators group, Operators group, Browse group, and the Password Reset Group. You can specify your own groups here. The groups must be local on the server and cannot be located in the domain.

We will be using a local SQL Express database (installed by AD Connect) to store the data for AD Connect so proceed by clicking on the Install button:

Once Azure AD Connect has been installed, you will be presented with the following User sign-in options:

Password Hash Synchronization is the default option as it is for the Express settings and given that we are configuring AD FS as the sign-in option, proceed by selecting Federation with AD FS:

Proceed by entering the credentials for an account that has global administrator permissions for the Azure tenant:

Select the domain in the forest that Azure AD Connect will be synchronization from the FOREST drop down menu:

**Note that the domain in this example has a non-routable internal domain (.local suffix) but a UPN suffix with the SMTP domain the organization will be used to sign into resources have already been added as a custom domain and verified.

Select Create new AD account if a service account has not already been created for the AD Connect Synchronization application:

AD Connect will validate the Enterprise admin credentials to ensure that it is able to connect to the selected domain:

Upon successful completion, the selected domain will be listed under the CONFIGURED DIRECTORIES heading with a green check mark beside it:

Clicking Next will allow AD Connect to retrieve the directory schema of the domain:

Since the Active Directory domain uses a non-routable suffix but an additional UPN has already been configured, the wizard will indicate that it is not added (it isn’t possible to do so) but the UPN suffix has been verified:

For referencing the following are attributes that are available:

Proceed with using having the userPrincipalname selected for the USER PRINCIPAL NAME drop box menu and select Continue without matching all UPN suffixes to verified domains (this needs to be selected as there is a non-routable domain listed):

The next Domain/OU Filtering page is where the configuration for whether AD Connect will synchronize the whole domain or only selected domains and OUs is configured. Be cognizant of whether the whole domain should be synchronized or not as this as it is best practice to only synchronize OUs that are required especially if the domain has a lot of unused objects. Selectively synchronizing only the objects that is needed will optimize the performance. With that said, if the OU structure isn’t organized well with objects scattered across everywhere then it may be best to synchronize the whole domain to avoid missing critical objects.

Uniquely identifying users isn’t as important for a single forest with single domain as users typically have only one identity but having multiple forests and domains usually means a single user could have multiple identities. If an organization with multiple forests and domains is being configured, decide multiple identities will be identified as described in the following table.

Setting	Description
Users are only represented once across all forests	All users are created as individual objects in Azure AD. The objects are not joined in the metaverse.
Mail attribute	This option joins users and contacts if the mail attribute has the same value in different forests. Use this option when your contacts have been created using GALSync. If this option is chosen, User objects whose Mail attribute aren't populated will not be synchronized to Azure AD.
ObjectSID and msExchangeMasterAccountSID/ msRTCSIP-OriginatorSid	This option joins an enabled user in an account forest with a disabled user in a resource forest. In Exchange, this configuration is known as a linked mailbox. This option can also be used if you only use Lync and Exchange is not present in the resource forest.
sAMAccountName and MailNickName	This option joins on attributes where it is expected the sign-in ID for the user can be found.
A specific attribute	This option allows you to select your own attribute. If this option is chosen, User objects whose (selected) attribute aren't populated will not be synchronized to Azure AD. Limitation: Make sure to pick an attribute that already can be found in the metaverse. If you pick a custom attribute (not in the metaverse), the wizard cannot complete.

For the purpose of this example, only one domain in a forest will be synchronized so the Users are represented only once across all directories will be selected:

For reference, a few of the options for attributes that can be used to identify users are as follows:

The Filter users and devices is great for AD Connect pilots where the OU structure does not permit the synchronization of objects that are selected for the pilot. With the filtering option, an administrator can create a group and add all the objects in so these objects are the only ones that get synchronized into Azure AD. Note that nested groups are not allowed so all the objects in the group must be direct members.

I won’t go write an explanation as to what each optional feature provides as the table from the documentation does a great job explaining it:

Optional Features	Description
Exchange Hybrid Deployment	The Exchange Hybrid Deployment feature allows for the co-existence of Exchange mailboxes both on-premises and in Office 365. Azure AD Connect is synchronizing a specific set of attributes from Azure AD back into your on-premises directory.
Exchange Mail Public Folders	The Exchange Mail Public Folders feature allows you to synchronize mail-enabled Public Folder objects from your on-premises Active Directory to Azure AD.
Azure AD app and attribute filtering	By enabling Azure AD app and attribute filtering, the set of synchronized attributes can be tailored. This option adds two more configuration pages to the wizard. For more information, see Azure AD app and attribute filtering.
Password hash synchronization	If you selected federation as the sign-in solution, then you can enable this option. Password hash synchronization can then be used as a backup option. For additional information, see Password hash synchronization. If you selected Pass-through Authentication this option can also be enabled to ensure support for legacy clients and as a backup option. For additional information, see Password hash synchronization.
Password writeback	By enabling password writeback, password changes that originate in Azure AD is written back to your on-premises directory. For more information, see Getting started with password management.
Group writeback	If you use the Office 365 Groups feature, then you can have these groups represented in your on-premises Active Directory. This option is only available if you have Exchange present in your on-premises Active Directory.
Device writeback	Allows you to writeback device objects in Azure AD to your on-premises Active Directory for Conditional Access scenarios. For more information, see Enabling device writeback in Azure AD Connect.
Directory extension attribute sync	By enabling directory extensions attribute sync, attributes specified are synced to Azure AD. For more information, see Directory extensions.

As AD FS is going to be configured, we will enabled Password has synchronization as a fallback if the federation service is not available:

Implement password hash synchronization with Azure AD Connect sync
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization

Password hash synchronization can also be enabled in addition to federation. It may be used as a fallback if your federation service experiences an outage.

Enter an account with domain administrator rights for the Azure AD Connect to perform the configuration changes:

Note that the account needs to be a local administrator on the AD FS servers that will be used. Domain Administrators group is usually a part of the administrator group on the servers but if they are not, ensure that you add this account onto the servers:

Configure AD FS Farm

The AD Connect wizard can actually create and configure an AD FS farm but this example already has an AD FS farm configured so the Use an existing AD FS farm will be selected:

Specify the FQDN of the primary server in the AD FS farm:

The wizard will attempt to validate the AD FS farm:

Upon successfully validating the farm, select the domain to federate with Azure AD:

Allow AD Connect to perform the configuration:

Once the configuration has completed, allow AD Connect to start the synchronization:

Verifying synchronization service connectivity to Azure Active Directory

Creating the Azure Active Directory Synchronization Account

Installing Azure AD Connect Health agent for sync

Azure AD Connection configuration has now completed:

Verify Internal and External AD FS Access

If an existing AD FS farm was used then the DNS records for intranet and internet access should have been configured so proceed to run both of the Verify federation connectivity tests:

Verify Azure AD Connect Configuration for Azure Active Directory

Switching back to the Azure portal’s Azure Active Directory will display the Status as Enabled for Azure AD Connect:

Verify Azure AD Connect Synchronization Service

Launching the Synchronization Service Manager on the AD Connect server will show that a Full Import, Full Synchronization and Export is ran:

Test Office 365 Sign-in AD FS Redirection

Attempting to sign in through https://login.microsoftonline.com should not bring you to the AD FS login page:

However, you will be redirected the AD FS sign page once the email address (UPN) is entered as the identity:

Verify Relying Party Trusts Configuration for O365 in AD FS

Logging onto the AD FS management console on the AD FS server will show that a Microsoft Office 365 Identity Platform Worldwide was configured in the Relying Party Trusts by the Azure AD Connect wizard:

Turn on MFA for O365 Sign-in

If a MFA solution such as Duo in this example is deployed, it can be turned on by right clicking on Microsoft Office 365 Identity Platform Worldwide and selecting Edit Access Control Policy…:

Click on Use access control policy link:

Select Permit everyone and require MFA:

MFA will now be required when users sign into Office 365 via the AD FS sign-in portal.