Azure ADConnect Installation and Configuration (Single AD Forest)

Azure ADConnect Installation and Configuration (Single AD Forest)

The following article will walk you through creating a hybrid identity environment using password hash sync for signle AD forest. This environment can then be used for testing or for getting more familiar with how a hybrid identity works.

On-premises datacenter has single AD forest (cloudepict.local) distributed 3 different sites and locations using 4 physical AD servers.

We’re strongly recommending to install IdFix before starting Azure ADSync Tool configuration. IdFix identifies errors such as duplicates and formatting problems in your directory before you synchronize to Office 365.

Now it is time to download and install Azure AD Connect. A small reminder that we’re alreday using Office 365 and Microsoft Azure as well. Our custom domain name which is defined on Office 365 and Microsoft Azure too.

Firstly, connect to and go to Azure Active Directory in left panel.

Then connect to with your current credential and go to Azure Active Directory at the bottom left of the screen.

Here is our Local Active Directory server and Organizational Unit for migrated users.

Before you install Azure AD Connect

Before you install Azure AD Connect, there are a few things that you need.

Azure AD

  • An Azure AD tenant. You get one with an Azure free trial. You can use one of the following portals to manage Azure AD Connect:
  • The Azure portal.
  • The Office portal.
  • Add and verify the domain you plan to use in Azure AD. (public domain names)
  • An Azure AD tenant allows by default 50k objects. When you verify your domain, the limit is increased to 300k objects. If you need even more objects in Azure AD, then you need to open a support case to have the limit increased even further. If you need more than 500k objects, then you need a license, such as Office 365, Azure AD Basic, Azure AD Premium, or Enterprise Mobility and Security.

Prepare your on-premises data

  • Use IdFix to identify errors such as duplicates and formatting problems in your directory before you synchronize to Azure AD and Office 365.
  • Review optional sync features you can enable in Azure AD and evaluate which features you should enable.

On-premises Active Directory

  • The AD schema version and forest functional level must be Windows Server 2003 or later. The domain controllers can run any version as long as the schema and forest level requirements are met.
  • If you plan to use the feature password writeback, then the Domain Controllers must be on Windows Server 2008 R2 or later.
  • The domain controller used by Azure AD must be writable. It is not supported to use a RODC (read-only domain controller) and Azure AD Connect does not follow any write redirects.
  • It is not supported to use on-premises forests/domains using “dotted” (name contains a period “.”) NetBios names.
  • It is recommended to enable the Active Directory recycle bin.


  • An Azure AD Global Administrator account for the Azure AD tenant you wish to integrate with. This account must be a school or organization account and cannot be a Microsoft account.
  • If you use express settings or upgrade from DirSync, then you must have an Enterprise Administrator account for your on-premises Active Directory.
  • Accounts in Active Directory if you use the custom settings installation path or an Enterprise Administrator account for your on-premises Active Directory.

Hardware requirements for Azure AD Connect

The table below shows the minimum requirements for the Azure AD Connect sync computer.

Number of objects in Active Directory



Hard drive size

Fewer than 10,000

1.6 GHz

4 GB

70 GB


1.6 GHz

4 GB

70 GB


1.6 GHz

16 GB

100 GB

For 100,000 or more objects the full version of SQL Server is required


1.6 GHz

32 GB

300 GB


1.6 GHz

32 GB

450 GB

More than 600,000

1.6 GHz

32 GB

500 GB

The minimum requirements for computers running AD FS or Web Application Servers is the following:

  • CPU: Dual core 1.6 GHz or higher
  • MEMORY: 2 GB or higher
  • Azure VM: A2 configuration or higher

Today, businesses, and corporations are a becoming more and more a mixture of on-premises and cloud applications. Users require access to those applications both on-premises and in the cloud. This requirement has become a challenging scenario.

Microsoft’s identity solutions span on-premises and cloud-based capabilities. These solutions create a common user identity for authentication and authorization to all resources, regardless of location. We call this hybrid identity.

To achieve hybrid identity, one of three authentication methods can be used, depending on your scenarios. The three methods are:

  • Password hash synchronization (PHS)
  • Pass-through authentication (PTA)
  • Federation

These authentication methods also provide single-sign on capabilities. Single-sign on automatically signs your users in when they are on their corporate devices, connected to your corporate network. Lets start to connect azure portal to download Azure AD Connect. To download the AD Connect software, log on to Azure AD, navigate to Azure Active Directory -> Azure AD Connect -> Download Azure AD Connect.

Or you can download from the following link.

After downloaded now on your nominated AD Connect server, double click AzureADConnect and Install. Then agree to the license terms and privacy notice. Click Continue.

In this page we’ll select Customized installation. Click Customize

Check the appropriate options for your organisation. Some of these options are:

  • Use an existing service account – If you opt to use a full SQL server or AD Connect must route through a proxy that requires authentication, you need to use a service account from your on-premises domain that you know the password too, or use a managed service account. If this option is not checked, AD Connect uses a virtual service account for the synchronisation services to use.
  • Specify custom sync groups – Four local groups are created on the AD Connect server. If you instead prefer to specify your own groups, you can do so here. The groups must be local groups, and not domain groups. The default groups created by AD Connect are ADSyncAdmins, ADSyncBrowse, ADSyncOperators, ADSyncPasswordSet.

Click Install.

Authentication options with AD Connect:

When running through the AD Connect installation wizard, there are a number of different methods you can enable that change how your users authenticate to cloud services in Azure.

Password Hash Synchronization

The Password Hash Synchronization method is enabled by default when using the Express installation option, and is recommended to be used by Microsoft when you are just wanting to enable user sign-in to Office 365, SaaS applications, Intune, or other Azure AD based resources.

With this method, hashes of user’s passwords are synchronised from on-premises Active Directory to Azure AD without the need for any additional infrastructure.

You cannot use a password hash to sign in to your on-premises network, nor can the hash be converted to plain text. Before the password hash is synchronised to the Azure AD authentication service, extra security processing is applied.

If a user changes his or her password, new password hashes are synchronised to Azure AD immediately. Otherwise, passwords are synchronised to Azure AD every two minutes, which is more frequent than the synchronisation of other attributes. This frequency cannot be modified either, nor can you choose which users will have/not have their password synchronised.

When a user’s password is synchronised to Azure AD, their cloud account password is set to Never Expire. This means that users can potentially authenticate to cloud resources using an expired password, which will not change until that user updates their password on-premises. Also, if you use the Account expires feature as part of user account management, the corresponding accountExpires attribute is not synchronised to Azure AD, so expired accounts will remain active on Azure AD. Microsoft recommend that you use automation to trigger a PowerShell script that will disable the account in Azure AD using the Set-AzureADUser cmdlet and vice-versa when an account is enabled.

Given that you always have to authenticate to Azure AD, even when on the corporate network, you can boost user experience by enabling password write-back which enables self-service password reset capabilities in Azure AD. Furthermore, you can enable single sign-on so users only need to enter a username when accessing cloud resources from the corporate network. If KMSI (Keep me signed in) is enabled in Azure AD, users will have the option of bypassing authentication for 180 days, as a session cookie will be stored on their computer and used for future authentication attempts during this time. You even have the option of bypassing username insertion by using Seamless SSO, which automatically signs users in when they are on the corporate network and on a corporate device.

Pass-through authentication

This method uses on-premises software agents to validate passwords, which may be a requirement in organisations that have strict security and compliance policies. When users authenticate to cloud resources, their credentials are validated against the on-premises domain controller, negating the need to present the password to Azure AD. Using this method also allows you to deploy on-premises password policies such as logon hour restrictions.

There is no additional license requirement to use this method.

This method, like PHS, can be integrated with Seamless SSO so that users do not need to type in their passwords to authenticate, when inside the corporate network. It can also integrate with self-service password management, password write-back and password protection, which bans commonly used passwords.

The on-premises agent must be deployed to a Windows Server 2012 R2 or higher server that is joined to your corporate domain.

No inbound ports are required to be open and no outbound connections are made by the agent, making it non-essential to be hosted in a DMZ.

The agent automatically receives updates and fixes to eliminate any management overhead.

High availability can be achieved by deploying multiple agents.

This method works with all browser based web applications and into Microsoft Office client-side applications that use modern authentication, such as Outlook.

As pointed out by Leee Jeffries in the comments, Password Hash Synchronization can be used as a backup method in the event that pass-through authentication agents fail.

Federation with AD FS

When authenticating to cloud resources, users are redirected to AD FS to complete sign-in. If AD FS fails, you could use Password Hash Synchronization as a backup method.

Federation with PingFederate

Using this method, users are redirected to on-premises PingFederate servers.

Do not configure

Use this method if you have another 3rd party federation server or solution in place.

Note: The Enable single sign-on option is available when you choose Password Hash Synchronization or Pass-through authentication. This SSO option allows you to authenticate to cloud services seamlessly from corporate devices, from the corporate network.

Choose the method that is right for your organisation, and click Next.

Enter credentials to your Azure global administrator account. These credentials will be used to create a service account in Azure AD. If you selected to use Federation with AD FS as your sign-in method, Microsoft recommend you specify credentials here. Click Next.

Enter the forest name you want to connect Azure AD Connect with, and click Add Directory.

Either create a new on-premises AD account, or specify an existing one that will be used for periodic synchronisation. If you are creating a new account, you will be required to specify credentials to an enterprise admin account that will be used to create the new account. If you specify to use an existing AD account, the account only needs the default read permissions, so can be a regular user account. If you have enabled Password Hash Synchronization, you should assign the Replicate Directory Changes and Replicate Directory Changes All to this account.

If your domain is verified in Azure AD, you will see a Verified status appear under Azure AD Domain. If not, you need to verify the domain. In this screen we also selecting User principial name as mail.

Under USER PRINCIPAL NAME, Microsoft recommend that you keep the default value of userPrincipalName. If you had used the Express option, this is the attribute automatically chosen. This attribute will be what users use to sign in to Azure AD or Office 365. You must make sure the value of this attribute matches one of the verified custom domain in Azure AD. For example, if you want on-premises users to authenticate with, add that domain to Azure AD, verify it, then make sure your on-premises user accounts have the userPrincipalName attribute populated with this custom domain as the prefix, for example

Note: If during an Express installation AD Connect notices you use a non-routable domain on-premises, it will warn you. In this case, you can instead run through a Custom installation, and specify another attribute as the sign-in attribute, such as mail. Click Next.

Domain and OU filtering allows you to be specific about which objects you want to synchronise to Azure AD. By default, all users, contacts, groups and Windows 10 computers are synchronised.

For example, maybe you only want users from particular Organizational Units to be synchronised, or only selected domains in a forest. Note that you can tweak filtering at any time by re-running the AD Connect wizard.

Note: Microsoft do not recommend synchronising users with administrator roles to Azure AD.

If planning to use group filtering, you can only configure that during initial installation of AD Connect. Keep in mind that group based filtering is intended for pilots stages only. If using group based filtering, be sure to not exclude the groups home Organizational Unit from synchronisation.

On the Uniquely identifying your users page, specify if users exist only once across all your directories, or if they exist across multiple directories and should be matched using attributes such as mail, or other specific attributes.

  • If users exist only once, they will be created as individual objects in the metaverse, and not joined to any other object.
  • If they exist in multiple directories, and for example you choose to match using the mail attribute, user objects and contacts will be joined in the metaverse if they have the same mail attribute. If the mail attribute is not populated for a user object, they will not be synchronised to Azure AD.
  • If you choose to match identities by ObjectSID and msExchMasterAccountSID/msRTCSIP-OriginatorSID attributes, an enabled user account in an account forest will be joined to a disabled user account in the resource forest, which as an example would be hosting Lync and/or Exchange.
  • If you pick a specific attribute, make sure it is populated for your users, or they won’t be synchronised to Azure AD. It is advised that you pick an attribute that is already present in the metaverse.

The final options are around how users should be identified with Azure AD. It is recommended to let Azure manage the source anchor for you. This will normally be the ms-DS-ConsistencyGuid attribute as previously mentioned. Alternatively you can pick a specific attribute to act as sourceAnchor, but you should make sure that it does not change if for example you move users between forests. objectGUID would not be a good example here, as it changes as users are moved to a different forst. This was one of the reasons Microsoft changed the default sourceAnchor attribute. Select your options and click Next.

The Optional features page allows you to enable additional features to support your environment. If for example a hybrid Exchange model was detected in your environment, you are given the option of selecting the Exchange hybrid deployment option, which synchronises a set of attributes from Azure AD back to your on-premises environment.

Other options such as Device writeback and Group writeback can be enabled that allows devices and groups created in Azure AD to be synchronised back to on-premises.

Select “Start the synchronization process when configuration completes” and click install.

Go to c:\ Program Files\ Microsoft Azure AD Sync \ UIShell and find miisclient

On the Configuration complete page, take note of which attribute has been selected as the sourceAnchor. This can also be viewed at a later stage via the View current configuration page. Click Exit.

Check all operations on Sync Service Manager

A synchronisation is scheduled to run every 30 minutes. There are two scheduler processes, one for user objects and attribute synchronisation, and one for password synchronisation.

To disable the scheduler, run command Set-ADSyncScheduler -SyncCycleEnabled $false

To show synchronisation schedule information, run command Get-ADSyncScheduler

PS C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync> import-module .\Adsync.psd1

PS C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync> Get-ADSyncScheduler

To customise the synchronisation schedule, run a command such as Set-ADSyncScheduler -CustomizedSyncCycleInterval 01:00:00 which for example will run a synchronisation every hour.

To run a synchronisation in-between the default times, run either Start-ADSyncSyncCycle -PolicyType Initial or PolicyType Delta for a delta synchronisation. We’ll setup sync for 15 min.

Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:15:00

For manuel sync please do the following

Start-ADSyncSyncCycle -PolicyType Initial

Leave a Reply

Your email address will not be published. Required fields are marked *

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