The Microsoft Press Store

Skill 4.1: Prepare on-premises Active Directory for Azure AD Connect


Date: 11/7/2017

Return to the article

Azure Active Directory Connect is Microsoft’s replacement for DirSync and Azure Active Directory Sync tools. In Skill 4.1 from Exam Ref 70-346 Managing Office 365 Identities and Requirements, 2nd Edition, explore how to prepare your on-premises Active Directory environment for synchronization of user accounts, group accounts, and more.

This skill deals with preparing your on-premises Active Directory environment for synchronization of user accounts, group accounts, and mail-enabled contacts to the Azure Active Directory instance that supports the Office 365 tenancy. To master this skill, you’ll need to understand the different Active Directory synchronization tools, the steps needed to prepare an on-premises Active Directory instance for Azure AD Connect, what to do if your on-premises Active Directory uses a non-routable domain name, what to think about when it comes to planning filtering of user account objects for synchronization, and what to do if you have a multiple forest environment.

Azure Active Directory Connect

Azure Active Directory Connect is Microsoft’s replacement for DirSync and Azure Active Directory Sync tools. Azure AD Connect is designed to streamline the process of configuring connections between on-premises deployment. Rather than perform some of the complex tasks outlined in this chapter and the next, 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 4-1:


FIGURE 4-1 Azure Active Directory Connect optional features

Cleaning 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:

Prior to deploying Azure AD Connect, you should ensure that you have performed the following tasks:

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

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


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 Office 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 4-2 displaying an account detected with an incorrectly configured userPrincipalName.


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


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 only able to modify the attribute of one object at a time. For example, Figure 4-3 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.



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

Using UPN suffixes and non-routable domains

Prior to performing synchronization between an on-premises Active Directory environment and an Azure Active Directory instance used to support an Office 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 is able to function for both the on-premises environment and Office 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 or 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 4-4 shows the adatum346ER.internal non-routable domain.


FIGURE 4-4 Non routable domain

If a domain is non-routable, the default routing domain—for example,—should be used for the Office 365 UPN suffix. This requires modifying the UPN suffix of accounts stored in the on-premises Active Directory instance. Modification of UPN after initial synchronization has occurred is not supported. This means that you need to ensure that on-premises Active Directory UPNs are properly configured prior to performing initial synchronization using Azure AD Connect.

To add a UPN suffix to the on-premises Active Directory in the event that the Active Directory domain uses a non-routable namespace, perform the following steps:

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

  2. On the Action menu, click Properties.

  3. On the UPN Suffixes tab, enter the UPN suffix to be used with Office 365. Figure 4-5 shows the UPN suffix of


    FIGURE 4-5 Non routable domain

  4. Once the UPN suffix has been added in Active Directory Domains And Trusts, you can assign the UPN suffix to user accounts. You can do this manually as shown in Figure 4-6 by using the Account tab of the user’s properties dialog box in Active Directory Users And Computers.


    FIGURE 4-6 Configure UPN

  5. You can use tools like ADModify.NET to reset the UPNs of multiple accounts as shown in Figure 4-7.


    FIGURE 4-7 ADModify.NET

  6. You can also use 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 adatum346ER.internal domain to

    Get-ADUser -Filter {UserPrincipalName -like "*@adatum346ER.internal"} -SearchBase
    "DC=adatum346ER,DC=internal" |
    ForEach-Object {
    $UPN =
    Set-ADUser $_ -UserPrincipalName $UPN

Planning for filtering Active Directory

When you use Azure AD Connect to synchronize on-premises Active Directory to an Azure Active Directory instance, the default setting is to have all user accounts, group accounts, and mail-enabled contact objects synchronized up to the cloud. For some organizations, synchronizing everything is exactly what they want. Other organizations want to be more selective about which objects are synchronized from the on-premises Active Directory environment to the Azure Active Directory instance that supports the Office 365 tenancy.

With Azure AD Connect, you can choose to filter based on the following options as shown in Figure 4-8:

You can also configure filtering on the basis of group membership, as shown in Figure 4-9. You can configure separate group based filters for each forest or domain synchronized using Azure AD Connect.


FIGURE 4-9 Filter Users And Devices

While Azure AD Connect will address most organization’s synchronization requirements, the most comprehensive tool that you can use to filter synchronization is the Synchronization Rules Editor, shown in Figure 4-10. You can use this tool to modify existing synchronization rules, but also to create new rules. Rather than configuring synchronization on a per-domain or per-OU basis, you can tailor rules for individual objects and specific Active Directory attributes.


FIGURE 4-10 Synchronization Rules Editor

Supporting multiple forests

The Azure Active Directory Connect tool also supports synchronization from multiple on-premises Active Directory forests to a single Azure Active Directory instance. Multiple forest synchronization to a single Azure AD instance is supported only when a single Azure AD Connect server is in use. Microsoft does not support multiple Azure AD Connect servers synchronizing with a single Azure AD instance, whether there is one or multiple forests being synchronized.

By default, Azure AD Connect will assume that:


FIGURE 4-11 Uniquely identify users

Azure AD Connect Sign-on options

Azure AD Connect supports a variety of sign in options. You configure which one you want to use when setting up Azure AD Connect as shown in Figure 4-12. The default method, Password Synchronization, is appropriate for the majority of organizations who will use Azure AD Connect to synchronize identities to the cloud.


FIGURE 4-12 User sign-in

Password synchronization

Hashes of on-premises Active Directory user passwords synchronize to Azure AD and changed password synchronize to Azure AD immediately. Actual passwords are never sent to Azure AD and are not stored in Azure AD. 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 write-back 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-though 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 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.

In addition, 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 username to help them securely access cloud resources.

Active Directory Federation

This allows users to authenticate to Azure AD resources using on-premises credentials. It also requires the deployment of an Active Directory Federation Services infrastructure. You will learn more about this in Chapter 5, “Implement and manage federated identities for single sign on.”