Install and configure Azure AD Connect

Azure AD Connect is the replacement for DirSync and Azure AD Sync, and it in simple terms allows you to integrate your on-premises Active Directory with Azure Active Directory, keeping both directories in sync with each other. This enables you to provide identities that are consistent across your on-premises services, and services in the cloud such as Office 365, or other SaaS applications without the need for separate logon credentials to private and public cloud resources.

A connected data source/connected directory organises its data in a database-like format, and provides a standard way to access that data. Examples of such data sources are SQL Server and Active Directory. These connected data sources work with Azure AD Connect, and they allow the AD Connect sync engine to hook in and synchronise data from them.

AD Connect is most commonly known to manage identities, and has the ability to manage the synchronisation of identities from multiple connected data sources. Various rules come pre-built with AD Connect, and it is these rules that determine how identity information is processed. As information from the data sources is processed, an integrated view of objects from multiple data sources can be achieved.

Synchronising on-premises identities to Azure AD via AD Connect is free. It doesn’t require that you have a subscription to Azure AD Basic or Premium for example. If you do have such subscriptions, licenses are not automatically assigned to synchronised users. This keeps you in control of license consumption. If you are an Office 365 customer, you can use both the Office 365 and Azure portals without the need for any extra subscription.

Contents:

• AD Connect/Azure AD requirements and limits
• AD Connect CPU, RAM and HDD requirements
• AD Connect components
• How are identities synchronised?
• Default synchronisation
• Information about the sync engine
  • The connector space (CS)
  • The metaverse (MV)
• The sourceAnchor
• The Active Directory Recycle Bin and the Prevent Accidental Deletes feature
• Azure AD installation options
  • Express
  • Custom
• AD Connect automatic upgrades
• Authentication options with AD Connect
  • Password Hash Synchronization
  • Pass-through authentication
  • Federation with AD FS
  • Federation with PingFederate
  • Do not configure
• Synchronisation rules
• Synchronization Service Manager
• Changing the synchronisation schedule
• Multiple forests and staging servers
• Installing AD Connect using the Custom option

AD Connect/Azure AD requirements and limits:

• An Azure AD tenant allows for up to 50k objects by default. If you verify your domain, that limit is increased to 300k. Any further limit increases up to 500k can be gained by contacting Microsoft Support, and limits above 500k require an Office 365 license, Azure AD Basic/Premium license or Enterprise Mobility and Security licensing.
• Your on-premises AD schema version and forest functional level (FFL) must be set to Server 2003 or higher.
• If you plan to use the password writeback feature, Domain Controllers must be running Server 2008 with the latest service pack, or later.
  • Note: If running Server 2008, you must also apply hotfix KB2386717.
• If you plan to use the password synchronisation feature, AD Connect must be installed on Server 2008 R2 SP1 or higher.
• As a recommendation, you should enable the AD Recycle Bin.
• AD Connect can be installed on Server 2008 Standard or higher. Server Core is not supported.
  • The server can be a Domain Controller, or simply a member server.
  • If you are planning to install AD Connect on Server 2008 or 2008 R2, make sure they are fully patched or the installation of AD Connect will fail.
• If you plan to use a Group Managed Service Account as your synchronisation account, AD Connect must be installed on Server 2012 or higher.
• The AD Connect server must run .NET 4.5.1 and PowerShell 3.0.
  • PowerShell Transcription should not be enabled via Group Policy.
• If you plan to use AD FS with AD Connect, AD FS roles must be installed on Server 2012 R2 or higher.
  • SSL certificates and name resolution also needs configured.
• SQL Express can be used and a 2012 Express LocalDB is installed by default. This database allows you to manage approximately 100k objects. You can also use a full SQL server edition.
• All versions from SQL Server 2008 with latest service pack to 2016 SP1 are supported.
• Azure SQL database is not supported.
• Sync engines cannot share a SQL instance. There must be one dedicated instance per sync engine.
• Case-insensitive SQL collations must be used.
• An Azure AD Global Administrator is required to integrate AD Connect with Azure AD.
• If running the Express installation of AD Connect, a local Enterprise Administrator account must be used.
• Firewall rules from AD Connect to Azure AD should be configured as per: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-ports
• Traffic to the URLs and IPs listed here must be allowed through your firewall or proxy servers.
  • If using Microsoft Cloud in Germany or Azure Government Cloud, refer to this list instead.
• As per this article, if your AD Connect server routes through a proxy which requires authentication, you need to modify the machine.config .NET file before installing AD Connect.
• Do not deploy multiple AD Connect servers to serve a single Azure AD tenant, this is not supported. You can deploy a staging server.

AD Connect CPU, RAM and HDD requirements:

• If you have less than 10k objects in AD:
  • 1.6GHz CPU, 4GB RAM, 70GB HDD.
• If you have 10k-50k objects in AD:
  • 1.6GHz CPU, 4GB RAM, 70GB HDD.
• If you have 50-100k objects in AD:
  • 1.6GHz CPU, 16GB RAM, 100GB HDD.

AD Connect components:

Three primary components make up AD Connect.

• Sync services – These services make sure that identity information from your connected data sources match what is in your Azure AD tenant. Two sync services exist:
  • Azure AD Connect sync – This component resides on-premises.
  • Azure AD Connect sync service – This component resides in Azure AD.
• ADFS – Optional component that can be used if you want to make use of 3rd party multi-factor authentication solutions for example.
• Health – Monitors your on-premises AD infrastructure and the synchronisation services.

How are identities synchronised?

In AD Connect, a connector connects to a connected data source. For example, maybe you have a single forest that you pull identity information from. Within AD Connect, you will have a single connector connected to this data source (the forest). API calls are made to exchange identity information between the data source and the AD Connect sync engine. When you install AD Connect, you configure a connector by defining the object types you want to synchronise, and the attributes, which becomes known as the attribute inclusion list. Attribute synchronisation is handled by a mixture of synchronisation rules, which you can alter. For example, in a default configuration of AD Connect, some rules will be created which looks for certain attributes stored in your identities and if found, those objects are not exported to Azure AD. An example is the IsPresent([isCriticalSystemObject]) attribute which represents built-in objects in AD. These objects are not synchronised to Azure AD.

For groups, computers, contacts and user objects to be synchronised to Azure AD using the default configuration, a certain criteria must be met as per the object type.

For user objects, they must:

• Have a sourceAnchor attribute set which does not change. If the value does change, synchronisation for that object stops until the value is corrected back to the known state.
• Have the accountEnabled attribute populated.

For contacts, they must:

• Have the proxyAddresses or mail attribute populated with a value that contains the @ symbol. This defines the object as being mail-enabled.

For groups, they must:

• Have less than 50k members. If the group exceeds 50k members after some time with being synchronised to Azure AD, further synchronisation stops until the count is lower than 50k.
• If the group is a Distribution Group, it must also be mail-enabled.

For computers, they must:

• Have a userCertificate ISNOTNULL attribute, which only applies to Windows 10 computers.

Default synchronisation:

Keep in mind that for a default configuration:

• Built-in security groups are not synchronised to Azure AD.
• Primary group membership synchronisation is not supported.
• Dynamic distribution group synchronisation is not supported.
• Mail-enabled distribution groups are synchronised if:
  • The proxyAddress or mail attribute has a value.
    • If the proxyAddress has a value, it must be in SMTP format, for example: user@domain.com.
• Disabled accounts are synchronised, given that these accounts could represent resources in Exchange such as a conference room. If another active account is later found, the userPrincipalName and sourceAnchor values of the active account overrides that of the disabled account.
  • Exception: A linked mailbox will not be synchronised

Information about the sync engine:

Two namespaces exist within the sync engine that store identity information. They are:

⮩ The connector space (CS)

Each connector managed by the sync engine has its own connector space. The connector space provides a way for the sync engine to compare what has changed in a connected data source so that it can correctly stage incoming changes or outgoing changes. This is possible due to the connector space holding a representation of each object from a connected data source, and the attribute inclusion list for that data source. When new objects or data is received by the sync engine, existing data from the connector space is evaluated to determine if it has already been synchronised. If new identity information is received, a representation of the identity object is created in the connector space. Each object must have two attributes:

• A Globally Unique Identifier (GUID).
• A Distinguished Name (DN).

A third attribute, known as the sourceAnchor, is used on each identity object and allows each object to be uniquely identified in the connected data source and connector space.

There are two types of objects in the connector space:

• Staging object
  • These objects have a DN, a GUID, and a value that indicates the object type. The staging object can be an import object or export object. Each object has a sourceAnchor value.
• Placeholders are used for two things
  • Directories such as Active Directory are designed with a hierarchical namespace architecture, which is not what the sync engine uses. The sync engine uses a flat namespace to store objects. Due to these facts, the sync engine uses placeholders which simply preserve the hierarchy. For example, a placeholder may represent an Organizational Unit in Active Directory.
  • Used for values of an object that has not yet been imported to the connector space. Sometimes attribute values of identities can be synchronised to the connector space before the actual attribute itself. A placeholder in this case is used to hold the value until the attribute is imported at a later time. The placeholder object is then overwritten by the staging object that represents the attribute.

As identity information received by the sync engine, decisions must be made around what to do with that data. Three steps are used here:

• Import – Identity information is received from a connected data source to the sync engine, at which time that data is evaluated by comparing to what staging objects are already stored in the connector space. Should existing staging objects be updated, or should new staging objects be created and then synchronised to Azure AD? In the example of a staging update, the sync engine tries to identify a staging object based on the sourceAnchor attribute. If that it not possible, the Distinguished Name is used. Once a match has been found, evaluations are made as to what changes to apply to the object. For example, attributes may need updated. Objects are marked as pending import, for which there are different types:
  • None – No changes are available.
  • Add – An existing staging object has not been found. This object is a new import object in the connector space.
  • Update – An existing staging object has been found, and an update is required on that object.
  • Delete – An existing staging object has been found, and a deletion is required on that object.
  • Delete/Add – An existing staging object has been found, and a recreation is required for that object.
• Synchronisation – Changes to staging objects in the connector space prompt an update to be provides to the metaverse or vice-versa. There are two types of synchronisations available:
  • Inbound synchronisation – Content of the metaverse is updated using data from the connector space. The metaverse contains a single view of all identity information from all connected data sources.
  • Outbound synchronisation – Content of the connector space is updated using data from the metaverse.
• Export – Staging objects that are flagged as pending export due to changes being staged on them are exported by the sync engine to a connected data source. For example, if an attribute had changed on a staging object, that attribute change could be exported to the connected data source. The sync engine keeps a record of successful exports, and can repeat an export if it later realises that during a comparison of identity information between the connected data source and connector space, an attribute had been reset by the connected data source.

⮩ The metaverse (MV)

The metaverse holds identity information from all connected data sources in a single view. Each object from every forest is represented once in the metaverse and synchronised to your target Azure AD tenant.

The sourceAnchor:

The sourceAnchor, also known as the immutableId, is a unique attribute assigned to each object so that an object can be uniquely identified by the sync engine. In cases where you use AD FS with AD Connect, the sourceAnchor is used alongside the userPrincipalName attribute in SAML claims, or when a new sync server is built or an existing one is rebuilt, the sourceAnchor attribute is used to link existing objects in Azure AD with objects on-premises.

The value of sourceAnchor remains the same across both Azure AD and on-premises directories, and its value should not change. The value of sourceAnchor is provided by the forest where that account is in an enabled state. The sourceAnchor attribute is generated for each imported object to AD Connect.

If you install AD Connect using the Custom wizard, you can manually specify which attribute should become the sourceAnchor, or you can have Azure manage the sourceAnchor for you, in which case some logic similar to running AD Connect using the Express wizard is applied.

If selecting the attribute manually, Microsoft recommend you use the ms-DS-ConsistencyGuid attribute for user objects (AD Connect 1.1.524.0+), and objectGUID for other object types. Previously when AD Connect did not support the aforementioned attribute, you were recommended to use the objectGUID attribute for user objects too, especially when you ran single forest deployments, or had multiple forests with no user object movement between those forests.

If you need to pick a different attribute to act as sourceAnchor, make sure that it is:

• globally unique,
• holds a string value, integer, or binary,
• is not case-sensitive,
• does not contain special characters,
• is less than 60 characters in length.

A good candidate may be the employeeID attribute.

If on the other hand you install AD Connect using the Express wizard, it is likely that attribute ms-DS-ConsistencyGuid will be selected as the sourceAnchor for user objects, and objectGUID for other object types. However, during an AD Connect installation, your Azure AD tenant is queried and if an existing sourceAnchor attribute is found on your Azure AD tenant, this attribute will be used instead.

Also, if ms-DS-ConsistencyGuid is already being used on objects on-premises, for example by an application, the AD Connect wizard will instead use objectGUID. You are informed which attribute was chosen as the sourceAnchor at the end of an AD Connect installation.

After a sourceAnchor is set, it cannot be changed. If you re-run the AD Connect wizard, you will notice the attribute for sourceAnchor can no longer be edited. If you do change the sourceAnchor attribute, you will encounter errors in AD Connect until resolved.

For user accounts that have no value populated for the ms-DS-ConsistencyGuid attribute, AD Connect writes the objectGUID value back to the ms-DS-ConsistencyGuid attribute in your on-premises AD environment. After the attribute is populated, the object is exported to Azure AD.

The Active Directory Recycle Bin and the Prevent Accidental Deletes feature:

Microsoft recommend that you enable the Active Directory Recycle Bin in your on-premises deployments that act as connected data sources to AD Connect and are synchronised to Azure AD. If you delete a user object from your on-premises directory, Azure AD places the corresponding Azure AD object in a soft-deleted state for 30 days. Using the AD Recycle Bin feature, you can restore the user object on-premises if it was accidentally deleted, and Azure AD will perform the same operation to the corresponding Azure AD user object.

The prevent accidental deletes feature is enabled on Azure AD Connect by default, and has a job of alerting you if more than 500 objects have been flagged for deletion in a single synchronisation job. This feature is designed to protect you from large accidental deletions of objects. For example, you may have:

• accidentally de-selected an Organizational Unit,
• accidentally deleted all objects from an OU,
• renamed an OU, which causes the OU to be out-of-scope for synchronisation.

If more than 500 objects are staged for deletion in Azure AD, the export stops and you receive an email informing you that a large number of deletions have been detected. It is then up to you to confirm if this was a legitimate deletion. If you need to check which objects are staged for deletion, you can do so by opening the Synchronisation Service, clicking on Connectors, selecting Active Directory, clicking Search Connector Space and then under scope clicking Disconnected Space followed by defining a search time and clicking on Search.

If you want to proceed with the deletes, run command Disable-ADSyncExportDeletionThreshold and then Enable-ADSyncExportDeletionThreshold to enable it again.

If you want to lower or raise the 500 object value, run command Set-ADSyncExportDeletionThreshold

Azure AD installation options:

⮩ Express:

Microsoft state that the Express installation option is used by around 90% of organisations, and this statistic can be aligned to the fact that it works for the most common customer deployments. That is, the Express option assumes you have a single Active Directory forest on-premises with less than 100k objects, and you can provide details to an Enterprise Administrator account used for the installation.

Using the Express option, the following features and options are configured:

• Password hash synchronisation is enabled, which eventually allows your users to authenticate to cloud services such as Office 365 using the exact same credentials they use on-premises.
• Users, groups, contacts and Windows 10 computer object types that are eligible for synchronisation across all domains in your forest will be configured for synchronisation.
• AD Connect will be configured for automatic upgrades, ensuring it is always on the latest version.

Note that if you want to enable some other features, or tweak the synchronisation of certain Organizational Units, it is possible to later run through the wizard again.

⮩ Custom:

Use this option if you have multiple forests you:

• want to synchronise with Azure AD,
• have more than 100k objects to synchronise,
• need to use full SQL server,
• plan to use group-based filtering rather than just OU filtering – note that this is intended only for proof of concepts,
• plan to use federation or do not have access to an Enterprise Administrator account.

AD Connect automatic upgrades:

Automatic upgrades of AD Connect are enabled when:

• You upgrade from DirSync.
• You run through an Express installation of AD Connect.
• You are using SQL Express for the database.
• The AD account is the default MSOL_, created when using Express.
• You have less than 100k objects in the metaverse.

To check the status of automatic upgrades, run cmdlet Get-ADSyncAutoUpgrade

Three states are available:

• Enabled
• Suspended – This should be set by the system only. You should not set the state to suspended.
• Disabled

Make sure the AD Connect server is allowed to contact the AD Connect Health URLs as documented in https://docs.microsoft.com/en-gb/office365/enterprise/urls-and-ip-address-ranges

Other points to note:

• If you have customised your filtering of objects in any way, you should make sure those filtering options are still in place after an upgrade.
• If the Synchronization Service Manager is opened and running on the AD Connect server, upgrades are suspended until the tool is closed.
• Automatic upgrade errors are logged in Event Viewer.
  • Automatic upgrades can fail if you have:
  • more than 100k objects in the metaverse,
  • your AD Connect server is low on disk space,
  • you have added custom synchronisation rules to the configuration,
  • you have enabled the device, group, or user writeback feature.

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.

Documentation on pass-through authenticaiton: https://jgspiers.com/azure-ad-pass-through-authentication/

• 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.

Synchronisation rules

Azure AD Connect comes with various pre-configured synchronisation rules that handle synchronisation of objects to Azure AD. The actual rules created depend on the detected schema in AD. For example, a schema that contains Exchange results in Exchange related rules being created, and different rules will be created based on the Exchange version.

To describe some of the default rules, the Out to AAD – Contact Join synchronisation rule handles contact synchronisation by checking the metaverse attribute sourceObjectType to see if it is set to Contact. If the attribute is instead set to User, the Out to AAD – User Join rule is triggered instead, which creates a user object in Azure AD.

If other directories are synchronised to Azure AD at a later time and a previously imported contact is found to be a user object in another directory, the contact is promoted to a user object.

The Synchronization Rules Editor (SRE) is a GUI tool located on the AD Connect server that allows you to edit, add and remove synchronisation rules. Microsoft state that the only time you should ever need to change a default synchronisation rule is when you want to change the join rule. If this is required, make a copy of the rule and then disable the default rule, continuing on with editing your newly copied rule. If you need to change an attribute flow via Transformations, create a new rule with higher precedence than the default rules.

To use the SRE, you must be a member of the ADSyncAdmins group, which is a local group on the AD Connect server. The user who installed AD Connect is automatically made a member of this group. Anyone else must be manually added afterwards.

Each rule comes with four different configuration sections:

• Description – Here, things such as the:
  • rule name is set including an optional description of the rule,
  • what connected system the rule applies to,
  • if the rule is disabled,
  • what the metaverse object type is, for example person if object is a user or contact, or group if the object is a group,
  • what the link type is such as Provision, Join, or StickyJoin. This setting works with the Join rules section.
• Scoping filter – When the synchronisation rule should apply is configured here. For example, the In from AD – User Join rule applies when a user accounts isCriticalSystemObject attribute does not equal TRUE and the adminDescription attribute does not start with User_.
  • Multiple filter groups can be defined for a rule. If so, a logical OR is evaluated between the groups. One of the groups has to be satisfied for the rule to apply. Multiple clauses can be defined within a single group, a logical AND takes place inside a group.
• Join rules – Here you can see how objects in the connector space relate to objects in the metaverse. For example, the In from AD – User Join rule has the Source Attribute set to mS-DS-ConsistencyGuid and the Target Attribute set to sourceAnchorBinary. Some rules do not have join rules defined. Synchronisation rules can have multiple groups of join rules defined. Objects from the connector space and the metaverse are joined if a match has been found on one of the join rules. If all rules have been evaluated and there is no match, then the link type on the Description page is used, for example that would be Provision in the case of the In from AD – User Join synchronisation rule. With this link type set, and no join rules evaluated, the object from your connected data source would be created/provisioned to the metaverse. If multiple synchronisation rules with join rules are found for a single object, an error is thrown. It is recommended to have only one synchronisation rule with join rules defined when multiple synchronisation rules apply to a single object. In the default configuration of AD Connect, synchronisation rules which have the word Join in their name are rules created to join objects together, when other synchronisation rules without any join rules defined apply attribute flows to objects.
• Transformations – Defines all attribute flows that apply to the target object when the objects are joined and the scope filter is satisfied. For example, the In from AD – User AccountEnabled synchronisation rule has several transformations defining which attributes will flow from the connected data source to Azure AD. A transformation can have different flow types:
  • Constant – This flow hardcodes target attribute values. For example, you may have a constant flow type that sets a specific target attribute to True. This is regardless of any source attributes and attribute values. If the rule is evaluated, then certain attributes in the target may be hardcoded by constant transformations.
  • Direct – Attribute values from the connected data source are kept as-is, as it is flowed to the target attribute.
  • Expression – Allows for advanced configurations.

Target object attributes could potentially be set by multiple synchronisation rules. In this case, synchronisation rule precedence is used to determine which synchronisation rule the attribute value will come from.

Synchronization Service Manager:

The Synchronization Service Manager is a tool available on the AD Connect server that can be used for advanced configuring of the synchronisation engine and view operational aspects of the service. For example, you can view the status of recent synchronisations, imports and exports including which objects were processed and so on. 

You can also manage connectors from the Connectors tab, allowing you to reset the synchronisation password, manage the attributes or object types that are processed and so on.

Changing the synchronisation schedule:

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

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.

Multiple forests and staging servers:

Regardless if you have a single forest or multiple forests, if you plan to synchronise all of these directories to a single Azure AD tenant, you can only have one AD Connect server/sync engine. That means that for multiple forest scenarios, they all must be able to contact the same single AD Connect server.

If you do have multiple forests, it is assumed that AD Connect will only find one enabled account for each user. This assumption is required for password hash synchronisation, pass-through authentication and federation capabilities. If a user is found on multiple forests with an enabled account, the sync engine picks one and ignores the other. It is also assumed that each user only has one mailbox, and the forest that hosts the mailbox will provide the best data quality for attributes visible in the Exchange GAL.

Besides having a single AD Connect server, you can have a second staging server. This server reads data from all connected data sources, but it does not perform any writes. If the primary AD Connect server fails, you can fail over to the staging server via the AD Connect wizard. If you make any configuration changes to the primary AD Connect server, you must perform the same on the staging server.

A staging server is useful if wanting to test new configuration changes and what effect they would have on your data, or if performing a migration/upgrade to newer operating system via the swing migration method.

Installing AD Connect using the Custom option:

Before installing AD Connect into your environment, you should run IdFix to prepare your directory before you synchronise objects to Azure AD. This tool was originally scoped to Office 365 customers.

By default, AD Connect versions 1.1.614.0 and higher use TLS 1.2 for encrypting communication between the sync engine and Azure AD as standard. As such, you should install Azure AD on the newest operating system possible to ensure they support this TLS version. The software can also fall back to TLS 1.1 and 1.0, however in the future that is likely to change as Microsoft deprecate support for older TLS versions.

To download the AD Connect software, log on to Azure AD, navigate to Azure Active Directory -> Azure AD Connect -> Download Azure AD Connect.

Click Download.

Now on your nominated AD Connect server, right-click AzureADConnect -> Install.

Agree to the license terms and privacy notice. Click Continue.

Rather than using the Express option which is explained throughout the article, 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 methods have already been explained.

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 onmicrosoft.com 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 planning to use Password Hash Synchronization, navigate to Active Directory Users and Computers, right-click your domain FQDN and click Properties.

Click on the Security tab -> Add.

Enter the name of the account you plan to use for synchronisation. Grant Allow access against the Replicating Directory Changes and Replicating Directory Changes All permissions. Click OK.

Return back to the AD Connect installation wizard, enter credentials to your existing account and click OK.

Click Next.

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.

Log on to the Azure AD portal. Navigate to Azure Active Directory -> Custom domain names -> Add custom domain.

Enter your custom domain name and click Add Domain.

You need to verify you are the domain owner. To do so, create for example a TXT DNS record on your authoritative domain name servers and click Verify once DNS propagation has taken place.

If successful, you will be returned the Verification succeeded! message. You can now set the custom domain as primary.

Return to the AD Connect installation wizard and click the refresh button to update the Azure AD Domain to Verified.

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 @yourdomain.com, 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 user.one@yourdomain.com.

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.

To configure filtering, I suggest you read here for pointers.

Click Next.

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.

Unless you have a desire to use group filtering, 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.

Click Next.

Finally, click Install.

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.