Azure AD Connect and account replication from On-Premises AD DS

Introduction to Azure AD Connect

In the internal network, we need a server where we will install Azure AD Connect and where data synchronization will take place. It has access to sensitive data both locally and in the cloud, so we need to secure it well. If we need higher availability, we can also install another server, which is however passive (Staging mode) Provide High Availability for Azure AD Connect

Communication is initialized from the server with AAD Connect, so there is no need to open any ports inside the network. Previously, it was possible to create a Site to Site VPN and operate synchronization through it, which Microsoft no longer supports.

There are many installation guides on the internet. For example, videos Setup On Premise Active Directory Sync to Office 365, Azure AD - #2 - AzureAD Connect. Detailed images How to Install and Configure Azure AD Connect. Guides in Czech Synchronizace AD do Azure Active Directory: přehled možností. And a lot of official documentation Azure AD Connect sync: Understand and customize synchronization.

At the beginning, it is necessary to decide and prepare several important things. We will look at some of them further. Basic preparation is Prerequisites for Azure AD Connect, Hybrid Identity Required Ports and Protocols.

User Authentication

An important decision is how users will authenticate (log in). Azure AD Connect user sign-in options

Authentication options (user login methods) are

• Password hash synchronization (PHS) - with accounts, the password hash is also synchronized to the cloud, so authentication takes place in the cloud, after changing the password, synchronization must occur, it can also be synchronized back to AD DS
• Pass-through authentication (PTA) - agents run in the local network that authenticate users against on-premises AD DS, so communication must always work (it is initiated from the internal network to the online environment)
• Federated authentication - we must have a federation system in place, primarily Active Directory Federation Services

The first two options PHS and PTA are referred to by Microsoft as Cloud Authentication. Azure AD processes the authentication process.

Seamless Single Sign-On

For PHS and PTA we can enable Single Sign-On. Azure Active Directory Seamless Single Sign-On: Quickstart. When accessing cloud applications from domain computers, there is no need to enter a password (only the username is entered), Kerberos SSO occurs. In browsers, the address https://autologon.microsoftazuread-sso.com is added as allowed for Kerberos. A computer account AZUREADSSOACC is created in the local domain.

Pass-through authentication (PTA)

For PTA, the AzureAD Authentication Agent (Pass-through Authentication Agent - PTA) is installed. One instance is installed together with Azure AD Connect. It is recommended to have 3 instances (it is also downloaded from the Azure AD Admin Center). People often ask if it is possible to install the agent on a domain controller. Microsoft does not officially state this anywhere, but many people use it that way.

Microsoft guides

• Tutorial: Integrate a single AD forest using pass-through authentication (PTA)
• Microsoft 365 integration with on-premises environments
• Azure Active Directory Pass-through Authentication: Quickstart

Password Hash Synchronization (PHS)

Microsoft recommends this method and states that it is secure. Passwords do not get into Azure AD, but only specially created hashes (more secure than those in On-Premises AD DS). Password hash synchronization does not occur together with directory synchronization, but separately every 2 minutes. Synchronization overwrites existing passwords in the cloud.

If the password is changed in On-Premises, it should be reflected very quickly in the cloud. We can also enable Password Write-Back, which ensures synchronization when changed in the cloud. Then we can use, for example, self-service password reset in Azure AD.

Enabling PHS does not affect the current session (current user login), it will take effect only on the next authentication request. We need to increase password policies (Password complexity policy, Password expiration policy). Passwords that do not meet the complexity requirements in Azure AD are also synchronized (and work) in Azure AD. Users who have synchronized password hashes are standardly without expiration (Never Expire). By default, Force Password Change on Next Logon is also not functional.

More information Implement password hash synchronization with Azure AD Connect sync

Changing the user login method

We can easily change the methods over time. We run Azure AD Connect and use the task Change user sign-in. It should be trouble-free, possibly more complicated when changing with AD FS. Some documentation contains info that user conversion occurs. Newer ones state that this no longer happens.

Documentation Changing the user sign-in method, Migrate from federation to password hash synchronization for Azure Active Directory

On-premises AD DS with a non-public (non-routable) domain

It used to be recommended to use a non-public name for the Active Directory domain, for example, company.local. Compared to the domain used on the internet, for example, company.com. Some time ago, the opinion changed, and mainly due to the use of cloud services, it is generally recommended to use the same name for the internal AD domain and the company's public domain, for example, company.com. Each variant has its advantages and disadvantages. The same domain is simpler for users, often they then have the same username as the email address. But it is also easier for attackers. In both cases, we need to solve DNS records for internal servers vs. publicly available ones in a certain way.

In Azure AD we set up a verified domain (we probably don't want to use the initial default company.onmicrosoft.com), which must be a public domain under our management. It is then used in user login names, email addresses, etc. If we want users to have the same login credentials online in Azure as in the on-premises directory, the Azure AD domain must match the internal UPN suffix. Microsoft describes everything in Prepare a non-routable domain for directory synchronization, Azure AD UserPrincipalName population.

It is stated that only accounts with User Principal Names (UPN) containing a verified domain are synchronized. But if the UPN contains a non-routable (non-public) domain, it is replaced by the initial (default domain). So bouska@company.local becomes bouska@company.onmicrosoft.com.

To avoid using the initial domain for login, we have several options. It might be enough to use an alternative login ID, i.e., choose the on-premises attribute mail as the Azure AD username (User Principal Names). I have not tested this. Another option is to rename the local domain, which is laborious and has many impacts.

New UPN Suffix

There is a relatively simple solution that should not significantly affect anything. It involves adding an Alternative UPN Suffix with a public domain. We simply add it using Active Directory Domains and Trusts by clicking on Properties. Then we need to assign it to user accounts.

Each account can have only one UPN, so there might be a concern that it will no longer be possible to log in with the original form bouska@company.local when we set bouska@company.com. Years ago, I did tests with user accounts and described everything in Kerberos Part 2 - AD user accounts and Service Principal Name.

This results in the following login options:

• only username, if the domain is automatically completed - bouska
• sAMAccountName (NetBIOS logon name) - company\\bouska
• username with domain (Implicit UPN) - bouska@company.local
• User Principal Names (UPN) - bouska@company.com

We can change the UPN for a group of users in one container easily using PowerShell.

$LocalUsers = Get-ADUser -SearchBase "OU=Administrativa,DC=company,DC=local" -Filter "UserPrincipalName -like '*company.local'" -Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@company.local","@company.com"); $_ | Set-ADUser -UserPrincipalName $newUpn}

Microsoft Azure Active Directory Connect

We install AzureADConnect.msi (by default it installs with MS SQL Express) and go through the wizard. The latest version can be downloaded Azure AD connect. We can choose Express installation or more settings using Customize. During the process, we log in with the Global Admin Azure AD account. We connect to the AD Forest and log in as Enterprise Admin. By default, we let a local account be created under which synchronization will take place.

Upgrade Azure AD Connect

Microsoft strictly recommends keeping Azure AD Connect on the latest versions. The document Azure AD Connect: Upgrade from a previous version to the latest describes various methods of performing the upgrade. By default, automatic upgrade should work Automatic upgrade. Using PowerShell, we can check if we have it enabled. However, it did not run for me either in testing or in production. The documentation states that we can check certain events in the application log, but the event source Azure AD Connect Upgrade is not available to me at all. There are also reasons why automatic upgrade is not supported. For example, if we use custom synchronization rules.

Another option is In-place upgrade, the description is in the Microsoft documentation. The process is such that we download the new version of AzureADConnect.msi and run it. Certain installation takes place and the upgrade wizard starts. It updates the engine, configures and updates components, rules, and services. After completion, synchronization starts (in certain cases completely).

Filtering objects for synchronization

An important choice is filtering accounts of users and devices that should synchronize to Azure AD. We can select domains and organizational units (OU) for synchronization. We can also set that only accounts that are included in a defined group are synchronized. I find this nice, at the beginning we want to test on selected accounts, it can also be useful in the future (depends on how well we have organized OUs). The disadvantage is that nested groups are not supported (accounts must be directly in this group). Also, the group is specified using Distinguished Name (DN), so if we move it to another OU, synchronization will stop working.

Optional features

Among the Optional features are several items that depend on our requirements. Important is, for example, Exchange hybrid deployment, if we want to deal with hybrid Exchange in the future. We can change all settings later when we run the installed Azure AD Connect application.

Changing settings

The settings we made during installation can be modified at any time by running the installed Azure AD Connect application. Most options are changed using Customize synchronization options or Change user sign-in. Using View or export current configuration we can view basic information. For example, which domain is synchronized, which account is used, which attribute is used as UPN and Source Anchor, etc. If the on-premises directory schema changes (e.g., Exchange is updated, which changes the schema), the option Refresh directory schema is useful.

Operation of Azure AD Connect

After installing Azure AD Connect we get several applications

• Azure AD Connect
• Synchronization Service
• Synchronization Service WebService Connector Config
• Synchronization Rules Editor

Synchronization control

Using the graphical tool Synchronization Service we can control the synchronization process (or even trigger it). On the Connectors tab, (by default) two connectors are visible, one to on-premises AD DS and the other to Azure AD. We can view basic parameters or trigger individual operations.

On the Operations tab, we see the synchronization history. Initially, Initial Synchronization is performed and then every 30 minutes (we can change it) Delta Synchronization occurs. Synchronization consists of several operations over both connectors. We can click through to individual objects and their details.

Triggering synchronization

The simplest way is to use PowerShell. For the first time, we need to import the module

Import-Module -Name "C:\\Program Files\\Microsoft Azure AD Sync\\Bin\\ADSync" -Verbose

Then we can easily trigger delta synchronization (and monitor the process in the GUI).

PS C:\\> Start-ADSyncSyncCycle -PolicyType Delta
Result
------
Success

We can also view (and change) the scheduler settings. Azure AD Connect sync: Scheduler

PS C:\> Get-ADSyncScheduler
AllowedSyncCycleInterval               : 00:30:00
CurrentlyEffectiveSyncCycleInterval    : 00:30:00
CustomizedSyncCycleInterval            : 
NextSyncCyclePolicyType                : Delta
NextSyncCycleStartTimeInUTC            : 12.08.2020 10:38:59
PurgeRunHistoryInterval                : 7.00:00:00
SyncCycleEnabled                       : True
MaintenanceEnabled                     : True
StagingModeEnabled                     : False
SchedulerSuspended                     : False
SyncCycleInProgress                    : True

Checking status in Azure AD

In the Azure Active Directory Admin Center there is Azure AD Connect. Here we see the main data on synchronization status and user login. There is a link to Azure AD Connect Health, where we can find synchronization errors.

Account Lockout Smart Lockout

In Azure AD we can configure account lockout (enabled by default) Protect user accounts from attacks with Azure Active Directory smart lockout.

Issuing new Kerberos keys for Seamless single sign-on

If we use SSO for Azure AD, Microsoft recommends issuing new keys for the computer account AZUREADSSOACC in the On-Premises AD forest every 30 days. The Azure Active Directory admin center displays a warning if the keys are older. The procedure is found in Azure Active Directory Seamless Single Sign-On: Frequently asked questions chapter How can I roll over the Kerberos decryption key of the AZUREADSSO computer account?

Simplified procedure to perform in PowerShell:

cd 'C:\Program Files\Microsoft Azure Active Directory Connect'
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext
Update-AzureADSSOForest

A dialog first appears to log in to Azure AD. During the update, log in to local AD, where you need to enter the username in the form domain\user.

Principle of user account synchronization

In Azure AD / Microsoft 365 we can combine cloud accounts and synchronized from on-premises. In the user list, there is a column Sync status / Directory synced. This determines where the account is primarily managed (and where selected attributes can be edited).

Source Anchor Attribute

After the first synchronization, the on-premises AD and Azure AD accounts are linked using an ID. Azure writes the value of Source Anchor back to the on-premises directory. By default, the attribute ms-DS-ConsistencyGuid is used (if not used, another attribute can be chosen during the first installation of Azure AD Connect). In Azure AD, this value is stored in the attribute ImmutableId. The value is created from the attribute ObjectGUID using the operation ToBase64String($user.ObjectGUID.tobytearray()).

Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1

Account synchronization

During synchronization, Azure AD Connect loads all accounts and then uses the specified filters. If we have set that only members of a certain group are synchronized, we must add the account to the group. If we later remove the account from the group, it will be deleted in Azure AD during the next synchronization and moved to Deleted users. When returned to the group, it will be restored.

Using PowerShell, we can add all accounts in a certain container to the group.

$LocalUsers = Get-ADUser -SearchBase "OU=Administrativa,DC=company,DC=local" -Filter *
$LocalUsers | ForEach-Object {Add-ADGroupMember -Identity "G AzureAD Users" -Members $_}

During synchronization, it is decided whether it is a new account or already paired using Source Anchor, then any changes are synchronized. For a new account, it is checked whether a corresponding account exists in Azure AD. If not, a new account is created. Most values are transferred only from local AD to Azure AD (only selected attributes, e.g., for Hybrid Exchange, are transferred in the opposite direction).

Linking existing users

Microsoft directly states that it is generally assumed that we start with a new (empty) Azure AD Tenant. In practice, the situation may be that we operate Azure AD, where we have created a number of users. They are included in groups, have assigned licenses, wrote various posts on Sharepoint and Teams, etc. We also have the same users in the local AD. Later, we decide that we want to use Connect and unify the accounts.

Microsoft now has a brief and clear article Azure AD Connect: When you have an existing tenant (a few months ago its content was different).

During synchronization, for each new on-premises AD object, it tries to find a corresponding existing Azure AD object. The corresponding object is searched using the method:

• Hard Match - compares Source Anchor (attribute immutableID), evaluated by Connect and Azure AD
• Soft Match - compares the attribute userPrincipalName and proxyAddresses (primary email address with SMTP in uppercase), evaluated only by Azure AD

If an existing object is found in Azure AD, it changes from cloud-managed to on-premises managed. All object attributes that have a value in on-premises AD and are synchronized are overwritten in Azure AD with the on-premises value. However, the actual account and its associations remain. The password may also change (either overwritten or authentication starts elsewhere), which the user uses to authenticate to the account.

If an account is found using Soft Match, the Source Anchor attribute is added to Azure AD and synchronized back to on-premises AD. Just like when creating a new account.

Azure AD admin role

If an existing cloud account in Azure AD has an assigned admin role, it will not be paired with the corresponding on-premises user. This is a protection to prevent an unauthorized user from accidentally gaining administrative privileges. If synchronization occurs and such accounts exist, it will end with a not very clear error AttributeValueMustBeUnique. The solution is to remove the admin role from the cloud user, perform synchronization, and then return the role.

Soft Match using userPrincipalName

If we have existing users in Azure AD and want to link them with on-premises AD users, we usually want them to have the same login name. Therefore, we have the corresponding userPrincipalName on both sides. Then the first Soft Match occurs completely automatically and without problems. At the beginning of my search, I mainly encountered articles mentioning SMTP matching, such as How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization. And unnecessarily experimented with setting email addresses.

Problems and manual setting of Source Anchor

If we have a non-public domain in on-premises AD and created an alternative UPN suffix with a public domain, we must not forget to change the UPN for users that we will synchronize. If we do not do this, the account will probably not be paired with the existing account in the cloud, but a new one will be created with the UPN name@company.onmicrosoft.com. At the same time, the Source Anchor is assigned to the cloud user and transferred back to the on-premises user. So when we subsequently correct the UPN and delete the cloud user, synchronization will not perform the expected pairing, but an error will occur.

The solution to this and other problematic situations is the manual setting of the Source Anchor attribute in Azure AD. The description is in the article Merge on-premise with existing Azure AD user. In Azure AD, we delete the newly created account and set the local user's ID value to the correct account in Azure AD.

PowerShell for Source Anchor

Below are PowerShell commands for obtaining information and setting locally and in Azure AD.

Connecting to Azure AD

Install-Module -Name AzureAD
Connect-AzureAD

Displaying account information from Azure AD

Get-AzureADUser -ObjectId bouska@company.com | FT DisplayName, UserPrincipalName, Mail, UserType, DirSyncEnabled, ObjectId, ImmutableId

Displaying (comparing) the ID of the user in on-premises AD that was synchronized to Azure AD

$user = Get-ADUser bouska -Properties *
[System.Convert]::ToBase64String($user.'mS-DS-ConsistencyGuid')
sArNGJz9FE1233TVtxmP9w==
[System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())
sArNGJz9FE1233TVtxmP9w==

Finding the Azure AD account by ImmutableId

Get-AzureADUser -Filter "ImmutableId eq 'sArNGJz9FE1233TVtxmP9w=='"

Setting ImmutableId on the account in Azure AD

Set-AzureADUser -ObjectId bouska@company.com -ImmutableId 'sArNGJz9FE1233TVtxmP9w=='

Checking synchronized attributes

Using the Synchronization Service tool, we can also search for objects and view synchronized attributes and rules. On the Metaverse Search tab, we select the object type and enter filtering parameters. The Search button displays the corresponding objects. We can click on them and view the properties.

In the properties, we can switch to Connectors, where we can open the object for the given connector. There is also a Preview button, which shows how synchronization would occur (we choose Full or Delta) for the given object. We can then apply the changes. We see very detailed attributes, rules, what and how changes.

Changing Attribute Mapping

After installing Azure AD Connect, default synchronization rules are set, which define how objects and attributes are synchronized. We can view, create new, or edit rules using the Synchronization Rules Editor. If we need to set an attribute from on-premises AD to be transferred to another attribute in Azure AD, we can do this relatively easily. A detailed description is in the article Azure AD Connect sync: Make a change to the default configuration (more interesting information How to Extract Azure AD Connect Attribute Mapping).

We should not modify existing rules, but to change behavior, we create a new rule and set it to a lower priority (Precedence). In the rule, we specify the source system, object type, filtering of source objects (e.g., to ensure the transferred value is not empty), and the actual transformation. FlowType Direct for direct value transfer or Expression if we add a function, target attribute, source attribute (or expression/function), and join type.

Problems with User Login with Pass-through Authentication - Timeout

A problem suddenly appeared when a user logged into a Microsoft service, where they entered their username and password into a form, it very often failed (they logged in maybe on the 4th attempt). The error or behavior varied. The service on the web repeatedly displayed the login dialog. Some applications showed an error that the username, password, or domain was incorrect. The most information was displayed in PowerShell when logging into cloud services.

New-CsOnlineSession : One or more errors occurred.: AADSTS80014: Validation request responded after maximum elapsed time exceeded.

Basic information on troubleshooting is provided in the article Troubleshoot Azure Active Directory Pass-through Authentication.

Of course, check in the Azure Active Directory admin center that the agents are in Active status. The logs in the Monitoring - Sign-ins section are quite good, either for the entire Azure AD or a selected user. Here you can see the authentication process nicely, including a series of Failure status events. In the details, I found similar information as displayed by PowerShell.

Sign-in error code: 80014
Failure reason: Validation request responded after maximum elapsed time exceeded.

According to the article, a Support Ticket should be created for this error. I went through the logs on individual AzureAD Authentication Agents, but didn't find much.

In the end, I simply restarted the Microsoft Azure AD Connect Authentication Agent service on all servers where the agent runs, and it looks like the problem was solved. Simply turning it off and on again should be the first thing to try.

Appearance of the Login Page

An interesting option is to set company branding for the login page (and several other places). We set the background image, logo, and can change some texts. When a user logs into a Microsoft 365 service (if SSO does not occur). First, they enter their login name (email address), which identifies the Tenant, and the subsequent password entry screen already has company branding. Some services can also be called with a specified Tenant. The logout page also changes, and the set company logo is displayed in several places.

We can also block the option to stay signed in (Keep me signed in), which uses a Cookie and bypasses authentication for 180 days.

More information Add branding to your organization's Azure Active Directory sign-in page. The settings are made in Azure Active Directory Admin Center - Company branding.