Manage user identity and roles

Skill 2.2: Plan identity synchronization by using Azure AD Connect

This skill section deals with planning the implementation of identity synchronization using Azure AD Connect as the synchronization solution. To master this skill, you’ll need to draw on some of the information you learned about in the previous skill as well as how to implement an appropriate Azure AD Connect sign-on option.

Design directory synchronization

Azure AD Connect is designed to streamline the process of configuring connections between on-premises deployment and an Azure AD instance. The Azure Active Directory Connect tool is designed to make the process of configuring synchronization between an on-premises Active Directory deployment and Azure Active Directory as frictionless as possible.

Azure Active Directory Connect can automatically configure and install simple password synchronization or Federation/single sign-on, depending on your organizational needs. When you choose the Federation with AD FS option, Active Directory Federation Services is installed and configured, as well as a web application proxy server to facilitate communication between the on-premises AD FS deployment and Microsoft Azure Active Directory.

The Azure Active Directory Connect tool supports the following optional features, as shown in Figure 2-2:

FIGURE 2-2 Azure Active Directory Connect optional features

• ■ Exchange hybrid deployment This option is suitable for organizations that have an Office 365 deployment in which there are mailboxes hosted both on-premises and in the cloud.

• ■ Exchange Mail Public Folders This feature allows organizations to synchronize mail-enabled public folder objects from an on-premises Active Directory environment to Microsoft 365.

• ■ Azure AD app and attribute filtering Selecting this option gives you the ability to be more selective about which attributes are synchronized between the on-premises environment and Azure AD.

• ■ Password synchronization This synchronizes a hash of the user’s on-premises password with Azure AD. When the user authenticates to Azure AD, the submitted password is hashed using the same process, and if the hashes match, the user is authenticated. Each time the user updates their password on-premises, the updated password hash synchronizes to Azure AD.

• ■ Password writeback Password writeback allows users to change their passwords in the cloud and have the changed password written back to the on-premises Active Directory instance.

• ■ Group writeback With this option, changes made to groups in Azure AD are written back to the on-premises AD instance.

• ■ Device writeback Here, information about devices registered by the user in Azure AD is written back to the on-premises AD instance.

• ■ Directory extension attribute sync This option allows you to extend the Azure AD schema based on extensions made to your organization’s on-premises Active Directory instance.

Clean up existing Active Directory objects

Before you deploy Azure AD Connect, it is prudent to ensure that your on-premises Active Directory environment is healthy. You should also have an excellent understanding of the current state of the Active Directory environment. This should include performing an audit to determine the following:

• ■ Do any Active Directory objects use invalid characters?

• ■ Do any Active Directory objects have incorrect Universal Principal Names (UPNs)?

• ■ What are the current domain and forest functional levels?

• ■ Are any schema extensions or custom attributes in use?

Before deploying Azure AD Connect, you should also ensure that you have performed the following tasks:

• ■ Remove any duplicate proxyAddress attributes.

• ■ Remove any duplicate userPrincipalName attributes.

• ■ Ensure that blank or invalid userPrincipalName attribute settings have been altered so that the setting contains only a valid UPN.

• ■ Ensure that for user accounts the cn and samAccountName attributes have been assigned values.

• ■ Ensure that for group accounts, the member, alias, and displayName (for groups with a valid mail or proxyAddress attribute) are populated.

• ■ Ensure that the following attributes do not contain invalid characters:

  • ■ sn

  • ■ samAccountName

  • ■ givenName

  • ■ displayName

  • ■ mail

  • ■ proxyAddress

  • ■ mailNickName

UPNs that are used with Office 365 can only contain the following characters:

• ■ Letters

• ■ Numbers

• ■ Periods

• ■ Dashes

• ■ Underscores

Rather than having to perform this operation manually, Microsoft provides some tools that allow you to automatically remediate problems that might exist with attributes before deploying Azure AD Connect.

IdFix

The IdFix tool, which you can download from Microsoft’s website, allows you to scan an Active Directory instance to determine if any user accounts, group accounts, or contacts have problems that will cause them not to synchronize between the on-premises instance of Active Directory and the Microsoft 365 instance of Azure Active Directory. IdFix can also perform repairs on objects that would otherwise be unable to sync. IdFix runs with the security context of the currently signed-on user. This means that if you want to use IdFix to repair objects in the forest that have problems, the security account you use to run IdFix must have permissions to modify those objects. The IdFix tool is shown in Figure 2-3, displaying an account detected with an incorrectly configured userPrincipalName attribute.

FIGURE 2-3 IdFix finds a user with a problematic UPN.

ADModify.NET

ADmodify.NET is a tool that allows you to make changes to specific attributes for multiple objects. If you are using ADSIEdit or the Advanced mode of the Active Directory Users and Computers console, you are able to modify the attribute of only one object at a time. For example, Figure 2-4 shows ADModify.NET used to modify the format of the userPrincipalName attribute for a number of user accounts so that it conforms to a specific format.

FIGURE 2-4 ADModify.NET

You can also use ADModify.NET to perform other system administration tasks, such as configuring a large number of accounts so that users have to change their password at next logon or to disable multiple accounts.

Use UPN suffixes and nonroutable domains

Before performing synchronization between an on-premises Active Directory environment and an Azure Active Directory instance used to support a Microsoft 365 tenancy, you must ensure that all user account objects in the on-premises Active Directory environment are configured with a value for the UPN suffix that can function for both the on-premises environment and Microsoft 365.

This is not a problem when an organization’s internal Active Directory domain suffix is a publicly routable domain. For example, a domain name such as contoso.com or adatum.com that is resolvable by public DNS servers will suffice. Things become more complicated when the organization’s internal Active Directory domain suffix is not publicly routable. For example, Figure 2-5 shows the adatum346ER.internal nonroutable domain.

FIGURE 2-5 Nonroutable domain

If a domain is nonroutable, the default routing domain, such as adatum346ER.onmicrosoft.com, should be used for the Microsoft 365 UPN suffix. This requires modifying the UPN suffix of accounts stored in the on-premises Active Directory instance. Modification of the UPN after initial synchronization has occurred is not supported. So, you need to ensure that on-premises Active Directory UPNs are properly configured before performing initial synchronization using Azure AD Connect.

Perform the following steps to add a UPN suffix to the on-premises Active Directory in the event that the Active Directory domain uses a nonroutable namespace:

1. Open the Active Directory Domains and Trust console and select Active Directory Domains and Trusts.

2. On the Action menu, select Properties.

3. On the UPN Suffixes tab, enter the UPN suffix to be used with Microsoft 365. Figure 2-6 shows the UPN suffix of epistemicus.com.

   

   FIGURE 2-6 Routable domain

4. Once the UPN suffix has been added in Active Directory Domains and Trusts, you assign the UPN suffix to user accounts. You can do this in one of three ways:

   • ■ Manually, as shown in Figure 2-7, by using the Account tab of the user’s Properties dialog box in Active Directory Users and Computers.

     

     FIGURE 2-7 Configuring the UPN

   • ■ Using tools like ADModify.NET to reset the UPNs of multiple accounts, as shown in Figure 2-8.

     

     FIGURE 2-8 ADModify.NET

   • ■ Using Microsoft PowerShell scripts to reset the UPNs of multiple user accounts. For example, the following script resets UPN suffixes of all user accounts in the epistemicus.internal domain to epistemicus.onmicrosoft.com:

     Get-ADUser -Filter {UserPrincipalName -like "*@epistemicus.internal"}
     -SearchBase
     
     "DC=epistemicus,DC=internal" |
     
     ForEach-Object {
     
     $UPN =
     
     $_.UserPrincipalName.Replace("epistemicus.internal","epistemicus.
     onmicrosoft.com")
     
     Set-ADUser $_ -UserPrincipalName $UPN
     
     }

Implement directory synchronization with directory services, Federation services, and Azure endpoints by using Azure AD Connect

Azure AD Connect supports a variety of user sign-in options, which are related to the method you use to synchronize directory information from Active Directory Domain Services to Azure AD. You configure which sign-in option you will use when setting up Azure AD Connect, as shown in Figure 2-9. The default method, password sync, is appropriate for the majority of organizations that will use Azure AD Connect to synchronize identities to the cloud.

FIGURE 2-9 User sign-in

Password synchronization

Hashes of on-premises Active Directory user passwords synchronize to Azure AD, and changed passwords immediately synchronize to Azure AD. Actual passwords are never sent to Azure AD and are not stored in Azure AD. This allows for single sign-on for users of computers that are joined to an Active Directory domain that synchronizes to Azure AD. Password synchronization also allows you to enable password writeback for self-service password reset functionality through Azure AD.

Pass-through authentication

When authenticating to Azure AD, the user’s password is validated against an on-premises Active Directory domain controller. Passwords and password hashes are not present in Azure AD. Pass-through authentication allows for on-premises password policies to apply. Pass-through authentication requires that Azure AD Connect have an agent on a computer joined to the domain that hosts the Active Directory instance that contains the relevant user accounts. Pass-through authentication also allows single sign-on for users of domain-joined machines.

With pass-through authentication, the user’s password is validated against the on-premises Active Directory controller. The password doesn’t need to be present in Azure AD in any form. This allows for on-premises policies, such as sign-in hour restrictions, to be evaluated during authentication to cloud services.

Pass-through authentication uses a simple agent on a Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, or Windows Server 2022 domain-joined machine in the on-premises environment. This agent listens for password-validation requests. It doesn't require any inbound ports to be open to the internet.

You can also enable single sign-on for users on domain-joined machines that are on the corporate network. With single sign-on, enabled users only need to enter a user name to help them securely access cloud resources.

Active Directory Federation

Active Directory Federation allows users to authenticate to Azure AD resources using on-premises credentials. It also requires the deployment of an Active Directory Federation Services infrastructure. This is the most complicated identity synchronization configuration for Microsoft 365 and is only likely to be implemented in environments with complicated identity configurations.

Azure Endpoints

The Azure AD Connect endpoint V2 API provides performance improvements over the original endpoint API. The V2 API supports syncing groups with more than 250,000 members. If you want to use the V2 API endpoint, Azure AD Connect must be upgraded to or installed as version 1.5.30.0 or later.

If your organization has deployed an earlier version of Azure AD Connect, the V1 API might still be in use. To switch to the V2 API, perform the following steps:

1. On the server on which Azure AD Connect is installed, open the PowerShell prompt as an administrator.

2. Disable the sync scheduler by running the following PowerShell command:

   Set-ADSyncScheduler -SyncCycleEnabled $false

3. Import the new PowerShell module that will be made available with the installation of the updated version of Azure AD Connect using the following command:

   Import-Module 'C:\Program Files\Microsoft Azure AD Sync\ExtensionsAADConnector.psm1'

4. Switch to using the V2 endpoint by running the following commands:

   Set-ADSyncAADConnectorExportApiVersion 2
   Set-ADSyncAADConnectorImportApiVersion 2

5. Reenable the sync scheduler by running the following command:

   Set-ADSyncScheduler -SyncCycleEnabled $true