Synchronization methods with Azure AD Connect

Having covered the concept of hybrid identity and authentication, you will now go through the process that makes hybrid identity possible—directory synchronization. The tool used to configure directory synchronization is called Azure AD Connect (previously known as Azure AD Sync Service and DirSync). Azure AD Connect consists of, or can leverage, the following components:

• Synchronization services
• Active Directory Federation Services (AD FS)—an optional component
• Health monitoring

Azure AD Connect supports multiple AD forests and multiple Exchange organizations to a single Microsoft 365 tenant. It leverages a one-way process, where it synchronizes users, groups, and contact objects from your on-premises AD to Microsoft 365.

Although this is almost exclusively a one-way process, there are some writeback capabilities that can be leveraged if chosen or required, which will allow attributes from passwords and groups set in Microsoft 365 to be written back to an on-premises AD.

The principles of Azure AD Connect are shown in the following diagram:

Figure 1.5: Azure AD Connect

Once Azure AD Connect is configured and in place, the source of authority for these newly synchronized objects remains with the on-premises AD. Therefore, these objects must be managed by on-premises tools, such as AD Users and Computers or PowerShell. Microsoft 365 administrators will, therefore, not be able to make changes to cloud objects in the Microsoft 365 portal that are synchronized from the on-premises AD.

When setting up Azure AD Connect for the first time, the installation wizard will guide you to select either an Express Settings installation or a customized settings installation. The Express Settings installation is the default setting for Azure AD Connect and is designed for use with password hash synchronization from a single AD forest. The installation dialog is shown in the following screenshot:

Figure 1.6: Express settings

The custom settings installation provides a richer selection of optional features that can be configured to provide enhanced functionality if required. You can start a custom settings installation by clicking on Customize:

Figure 1.7: Custom settings

With the custom settings installation, you are provided with the following options to extend your on-premises identities in the cloud using Azure AD Connect:

• Password hash synchronization
• Pass-through authentication
• Federation with AD FS
• Federation with PingFederate
• Enable single sign-on
• Do not configure

The following sections will explain how to configure the first five of these options in detail.

Password hash synchronization

Password hash synchronization is the simplest method to establish a hybrid identity with Azure AD. Also commonly known as same sign-on, password hash synchronization can be set up using Azure AD Connect. This will synchronize a hash of the user passwords to Azure AD from your on-premises AD.

With password hash synchronization, users logging onto their cloud accounts via the Microsoft 365 portal will authenticate directly to Microsoft 365 cloud services as opposed to leveraging on-premises authentication and security:

Figure 1.8: Password hash synchronization

How does this work? Here is the process in a few simple steps:

1. The password synchronization agent within Azure AD Connect will request the stored password hashes at 2-minute intervals from a domain controller. In response to this, the domain controller will encrypt the hash. This encryption is executed with a key that is acquired from the Remote Procedure Call (RPC) session key and then salted. Salting is a process pertaining to password hashing. Essentially it involves adding a unique value to the end of the password to create a different hash value. This provides an additional layer of security and helps protect against brute-force attacks.
2. The domain controller will then send the result, along with the salt, to the sync agent using RPC. The agent can now decrypt the envelope. It is important to point out that the sync agent never has any access to the password in cleartext.
3. Once decrypted, the sync agent performs a re-hash on the original password hash, changing it to a SHA256 hash by imputing this into the PKDF2 function.
4. The agent will then sync the resulting SHA256-hashed password hash from Azure AD Connect to Azure AD using SSL.
5. When Azure AD receives the hash, it will be encrypted with an AES algorithm and then stored in the Azure AD database.

Therefore, when a user signs into Azure AD with their on-premises AD username and password, the password is taken through this process. If the hash result is a match for the hash stored in Azure AD, the user will be successfully authenticated.

Pass-through authentication

Pass-through authentication is an alternative to password hash synchronization. This method is commonly used when Microsoft 365 administrators require users to authenticate their Microsoft 365 logins on-premises as opposed to directly to Azure AD:

Figure 1.9: Pass-through authentication

Unlike password hash synchronization, pass-through authentication does not synchronize passwords from on-premises AD to Microsoft 365. Instead, it allows users to log on to both on-premises and cloud applications and services using the same password. This provides a far more cohesive experience for users, with the added benefit that on-premises passwords are never stored in the cloud in any form.

A lightweight agent is all that is needed to set this up with Azure AD Connect and this agent is automatically installed on the Azure AD Connect server when you run the initial setup for pass-through authentication. To provide resiliency to your pass-through authentication solution, the agent can be installed onto additional servers in your on-premises AD sites. The agents should ideally be installed on servers close to your domain controllers to improve sign-in latency. Servers on which the agent is installed should also be security hardened to the same extent that you would protect domain controllers.

Note

It is recommended to configure a minimum of three authentication agents in your environment. The maximum number of agents that can be installed is 40. It is generally good practice to have at least one agent deployed to each of your AD sites to make pass-through authentication resilient and highly available.

The authentication agents must be able to make outbound requests to Azure AD over the following ports in order to function:

Table 1.1: Azure AD ports

Federation

Federation, in simple terms, can be described as domains that trust each other. They share access to resources across organizations, with authentication and authorization settings configured to control the trust.

It is possible to federate your on-premises AD environment with Azure AD to provide authentication and authorization. As is the case with pass-through authentication, a federated sign-in method enforces all user authentication via on-premises methods as opposed to the cloud.

The main benefits of federation are that it provides enhanced access controls to administrators. However, the drawback of this method is that additional infrastructure will inevitably need to be provisioned and maintained.

In Azure AD Connect, there are two methods available to configure federation with Azure AD. These are AD FS and the more recently added PingFederate.

To explain the infrastructure requirements in more detail, AD FS can be used as an example. In order to configure AD FS in line with Microsoft’s best practices, you will need to install and configure a minimum of two on-premises AD FS servers on your AD environment and two web application proxy servers on your perimeter network.

This configuration provides the necessary security principles to ensure that both internal and (especially) remote users authenticate to the services within your hybrid environment in a manner that provides appropriate authentication and authorization. The process of federation is shown in the following diagram:

Figure 1.10: Federation

So, how does federation actually work? Well, there are two main principles that you need to understand. These are claims-based authentication and federated trusts. The following sections will explain each of these in detail.

Claims-based authentication

Claims-based authentication works on the principle of users making statements about themselves in order to authenticate and gain access to applications by using industry-standard security protocols. User claims rely on the claims issuer, which is the Security Token Service (STS). The STS can be configured on your AD FS server. The statements provided by users can relate to name, identity, key, group, privilege, or capability.

A claim is issued by the user to the claims issuer. It is then assigned values and packaged into a security token by the claims issuer (the STS). This security token is essentially an envelope that contains the claims relating to the user. The token is sent back to the user and then passed to the application that the user wishes to access.

The claim relies on the explicit trust that is established with the issuer. The application that the user wishes to access will only trust the user’s claim if it subsequently trusts the claims issuer (the STS).

With claims-based authentication, you can configure a number of authentication methods. The most commonly used ones are as follows:

• Kerberos authentication
• Forms authentication
• X.509 certificates
• Smart cards

Although many older applications do not support claims-based authentication, the main use-case argument for applications that do support it is that it simplifies the process of trust for those target applications. Instead of having to place their trust directly in the user making the claim, they can be secure in the knowledge that they can absolutely trust the claims issuer instead.

Federated trust

Federated trusts expand on the capabilities of claims-based authentication by enabling your issuer to accept security tokens from other issuers as opposed to a user having to directly authenticate. In this scenario, the issuer can both issue and accept security tokens from other trusted issuers utilizing the federation trust. This process essentially establishes a business relationship or partnership between two organizations.

Federated trusts enable trusted issuers to represent the users on their side of the trust. The benefit of this configuration is that should you need to revoke the trust, you can do so through a single action. Rather than revoking a trust with many individual external users, you can simply terminate the trust with the issuer.

A good example of how this works in practice would be that if you need to authenticate remote users to your environment, a federated trust will remove the requirement to provide direct authentication for those users. Instead, you will have a trust relationship with the remote user from their organization. This enables these remote users to continue using their own single sign-on methodology and provides an efficient, decentralized way for them to authenticate to your organization.

Note

An alternative method of providing many of the features that federation offers is to use pass-through authentication in conjunction with the rich features of Azure AD Premium, such as Conditional Access and Identity Protection.

Although additional licensing may be required within Azure AD to deploy these features, this method offers simplified setup and administration and also removes the requirement for any additional infrastructure.

Azure AD Seamless Single Sign-On

Azure AD Seamless Single Sign-On (Azure AD Seamless SSO) is a free-to-use feature of Azure AD that provides a single set of credentials for your users to authenticate to applications within Azure AD, when connecting to your organization’s network using a business desktop device. This means that once connected to your organization’s network on their Windows 10/11 domain-joined devices, they will not be asked to provide further credentials when opening any Azure AD applications. The principles of Seamless SSO are shown in the following diagram:

Figure 1.11: Seamless SSO

Seamless SSO is configured via the Azure AD Connect wizard or PowerShell and can be used in conjunction with password hash synchronization and pass-through authentication. It is not compatible with federations such as AD FS or PingFederate.

There are some prerequisites to be aware of when planning to implement Seamless SSO. These include the following:

• If you are using Azure AD Connect with password hash sync, ensure that you are using Azure AD Connect Version 1.1.644.0 or later. Further, if possible, ensure that your firewall or proxy is set to allow connections to the *.msappproxy.net URLs over port 443. Alternatively, allow access to the Azure data center IP ranges.
• Be aware of the supported topologies that are shown at https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies.
• Ensure that modern authentication is enabled on your tenant.
• Ensure that the version of your users’ Office desktop clients is a minimum of 16.0.8730.xxxx or above.

Note

Although at the time of writing this book, version 1.1.644.0 is still listed as the minimum required version of Azure AD Connect when using Seamless SSO with password hash synchronization, it is important to be aware that version 1 of AD Connect was retired by Microsoft at the end of August 2022. Further details of this can be found in the Further reading section at the end of the chapter.

Once you have verified these prerequisites, you can go ahead and enable the feature. This is most commonly done when setting up Azure AD Connect for the first time by performing a custom installation using the Azure AD Connect wizard and, from the User sign-in page, ensuring that the Enable single sign-on option is selected:

Figure 1.12: User sign-in methods

It is also possible to use PowerShell to set up Seamless SSO. This is a particularly useful method if you need to specify a particular domain(s) in your AD forest to use the feature.

If you need to enable the feature when you already have Azure AD Connect deployed, then you can rerun the setup wizard and choose the Change user sign-in option under the Additional tasks section:

Figure 1.13: Additional tasks

Note

You will need domain administrator credentials to complete setting up Seamless SSO. However, these credentials are only required to enable the feature and will not be required after the setup is complete.

To verify that the setup of Seamless SSO has been completed successfully, log on as a global administrator to https://portal.azure.com and navigate to Azure Active Directory | Azure AD Connect.

From this page, you will be able to verify that Seamless SSO has the status Enabled:

Figure 1.14: User sign-in settings

Finally, when completing your custom settings installation of Azure AD Connect, you are presented with several additional Optional features, as shown in the following screenshot:

Figure 1.15: Optional features

The most commonly used features are Exchange hybrid deployment and Password writeback. Further information on all of the available optional features can be viewed at https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom#optional-features.

To deploy the Azure AD Seamless single sign-on feature for your users, you need to ensure that the following URL is added to the required user’s Intranet Zone settings by using Group Policy: https://autologon.microsoftazuread-sso.com.

One of the advantages of deploying this setting with Group Policy is that you can roll out Seamless SSO to groups of users at your own pace.

A more recent alternative to Azure AD Connect to accomplish hybrid identity goals is Azure AD Connect cloud sync, which we will discuss in the next section.