# [2026 Edition] How to Sync Identities to Entra ID Using AWS Managed Microsoft AD and Entra Connect Sync v2 (Pass-Through Authentication)
This page has been translated by machine translation. View original
Shibata here.
About 4 years ago, I wrote an article on the procedure for integrating AWS Managed Microsoft AD with Entra Connect Sync (known at the time as Azure AD Connect).
Since there have been changes on both the AWS side and the Entra side between then and today, I've decided to compile the latest procedures as of today.
Major Changes Over 4 Years
The main changes over these 4 years are as follows.
Changes on the AWS Side
The major changes in AWS Managed Microsoft AD are:
- The internal OS was updated from Windows Server 2012 R2 to Windows Server 2019
- The domain and forest functional levels were updated to Windows Server 2016
These two points can be noted.
With both the internal OS version and functional level updated, features that were previously unsupported should now be available.
The most obvious example is password writeback, which requires Windows Server 2016 or later OS as mentioned in the previous article, but based on publicly available information online, unfortunately even if the OS version requirement is met, the permission-related settings cannot be configured, and password writeback apparently still cannot be used in AWS Managed Microsoft AD environments. (Unverified)
Also, a new Hybrid Edition has been introduced.
This involves a fairly specialized environment with unique constraints arising from assessments, making it difficult to make general statements.
For this reason, this article will not cover the Hybrid Edition.
Changes on the Entra Side
Regarding Entra, I think the biggest change is the rebranding from Azure AD to Entra ID.
And this year, Microsoft has formally started encouraging migration from Entra Connect Sync (formerly Azure AD Connect) to Entra Cloud Sync (formerly Azure AD Connect Cloud Sync).
Older versions of Microsoft Entra Connect prior to Ver.2.5.79.0 are scheduled for retirement at the end of September this year.
(Newer versions will continue to be available)
Mandatory upgrade required: All synchronization services for Microsoft Entra Connect Sync will stop working on September 30, 2026 if they are not using version 2.5.79.0 or later. We released this version in May 2025 due to backend service changes to enhance the service. Please upgrade before this deadline to avoid service interruptions.
That said, even today there are functional differences between Entra Connect Sync and Entra Cloud Sync, and they cannot simply be switched.
The situation where both need to be used depending on the case will likely continue for a while longer.
Also, the fact that installing Entra Cloud Sync requires domain administrator privileges remains unchanged, so it should still not be usable in AWS Managed Microsoft AD environments.
I plan to verify this in a separate article.
Trying It Out
From here, I will proceed with building the environment as in the previous article.
Last time, the AWS Security Blog was the reference, but now the build procedure is documented in the official documentation.
This time, I will refer to the official documentation procedures.
1. Initial Conditions
In this article, I will create the configuration shown below in my verification AWS account.

I will build AWS Managed Microsoft AD and a Windows Server 2025 EC2 instance with Entra Connect Sync v2 installed in a private subnet of a pre-prepared VPC environment.
In addition, I will also prepare a bastion server for managing Active Directory.
The specific build procedures for the VPC, AWS Managed Microsoft AD, and each EC2 are omitted.
The EC2 uses the latest Japanese AMI as of today (ami-0196295f45708836d : Windows_Server-2025-Japanese-Full-Base-2026.08.12).
1-1. Initial State of Entra ID
There are certain initial conditions required on the Entra ID side when using Entra Connect Sync.
This time I'm using my personal Azure environment's Entra ID tenant[1], and I have already configured a custom domain called example.shibata.tech.

1-2. Initial State of AWS Managed Microsoft AD
To match the conditions from last time, I prepared an Active Directory environment with the non-recommended domain name shibata.local and set the alternative UPN suffix to example.shibata.tech.
This time I created it with the AWS CLI like this:
# Create a Standard Edition directory environment with the AWS CLI
aws ds create-microsoft-ad \
--edition 'Standard' \
--name 'shibata.local' \
--short-name 'corp' \
--password 'P@ssword' \
--vpc-settings 'VpcId=vpc-xxxxxxxx,SubnetIds=subnet-xxxxxxxx,subnet-yyyyyyyy'


Alternative UPN Suffix has been configured

Example of using the alternative UPN Suffix with the admin user
1-3. Initial State of the Bastion Server
The bastion server is created using the AWS Managed Microsoft AD feature.
When creating from the management console UI, English Windows Server 2019 is used, so I slightly modified the generated CLI command to create a Windows Server 2025 environment.
# Change AmiId to /aws/service/ami-windows-latest/Windows_Server-2025-Japanese-Full-Base and create a management instance
aws ssm start-automation-execution --document-name "AWS-CreateDSManagementInstance" --document-version "\$DEFAULT" \
--parameters '{"DirectoryId":["d-0000000000"],"KeyPairName":["your-keypair"],"IamInstanceProfileName":["AmazonSSMDirectoryServiceInstanceProfileRole"],"SecurityGroupName":["AmazonSSMDirectoryServiceSecurityGroup"],"AmiId":["{{ssm:/aws/service/ami-windows-latest/Windows_Server-2025-Japanese-Full-Base}}"],"InstanceType":["t3.medium"],"MetadataOptions":["{\"HttpEndpoint\":\"enabled\",\"HttpTokens\":\"required\"}"]}' --region ap-northeast-1
2. Prerequisites for Entra Connect Sync
Next, let's confirm the prerequisites for Entra Connect Sync.
Not much has changed from last time, but I'll list the key points.
2-1. Prerequisites for Entra ID
You need to have an Entra ID tenant and configure a custom domain.
Adding a custom domain apparently increases the default limit of 50,000 objects up to 300,000 objects.
2-2. Prerequisites on the Active Directory Side
The Active Directory functional level must be Windows Server 2003 or later, and if you want to use password writeback, the domain controller OS must be Windows Server 2016 or later — this remains unchanged.
2-3. PowerShell Execution Policy
The need to change the PowerShell execution policy in order to run PowerShell scripts during Entra Connect Sync installation remains unchanged.
Running Set-ExecutionPolicy with -Scope CurrentUser should suffice.
# No administrator privileges required since scope is specified
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
2-4. OS Specs and Other Requirements for Entra Connect Sync
The current latest version needs to be installed on Windows Server 2019 or later, and it is recommended to install it on Windows Server 2022 through Windows Server 2025.
The OS must be a full installation, not Server Core.
Also, the OS specs required depend on the scale of Active Directory, with minimum requirements defined as follows:

Compared to last time, the minimum required memory size has increased to 6GB.
The point about using SQL Server Express LocalDB 2019 by default remains unchanged, so please be aware of the upper limit on CPU core count.
(When using SQL Server Express 2019, the licensing upper limit is 4 CPU cores)
This time I'll use t3.large (2 vCPU, 8GiB memory) and EBS 70GB as the minimum specs.
For other detailed conditions, please check the documentation.
2-5. Communication Requirements
The communication requirements for environments using Entra Connect Sync are summarized in the following document:
Please check the document for details, but the important points are as follows:
- Open the communication ports from Entra Connect Sync → Active Directory
- In the case of AWS Managed Microsoft AD, ports are open by default, so there's basically no issue
- Open outbound communication (HTTP, HTTPS) from Entra Connect Sync → Entra ID
- Inbound communication is basically not used. Opening RDP is about all you need
- The default security group allows all outbound traffic, so there's basically no issue
3. Installing Entra Connect Sync
From here, we begin the installation of Entra Connect Sync.
Please make sure the EC2 is already joined to the domain.
All subsequent work is performed with the administrator user admin@example.shibata.tech (admin@shibata.local).
3-1. Preparing the Synchronization Domain User
A dedicated domain user is required when performing ID synchronization with Entra Connect Sync.
This user can be created automatically during Entra Connect Sync installation, but automatic creation requires "Enterprise Admin" privileges, which AWS Managed Microsoft AD lacks, so it needs to be created manually in advance.
Since the AWS documentation does not specify a username for the user to create, following the previous article, I will create a new user named EntraConnectSvc.
Please create the user using the following PowerShell command or through the GUI.
# Creating the synchronization user
# Run from an environment where AD can be managed, such as a bastion server
# ※ It's fine to create manually instead of using PowerShell
$params = @{
Name = 'EntraConnectSvc';
UserPrincipalName = 'EntraConnectSvc@example.shibata.tech';
Description = 'Entra Connect Sync account'
AccountPassword = ConvertTo-SecureString 'P@ssword' -AsPlainText -Force;
PasswordNeverExpires = $true;
Enabled = $true;
}
New-ADUser @Params

The default user permissions are fine.
Permissions will be configured later.
3-2. Downloading and Installing Entra Connect Sync
While the AWS documentation has a procedure to install the latest version of Entra Connect Sync from the URL below, as of today the direct distribution of the installer has been discontinued, and it has been changed to download from the Entra admin center after agreeing to the terms.
Please read the PDF and other materials at the link above and download the MSI installer (AzureADConnect.msi) from the Entra admin center.

This time I was able to download the Ver.2.6.84 installer.

Run the MSI installer and wait until the software installation of Entra Connect Sync is complete.

After installation, the initial setup wizard will start, but since there are things to do before proceeding with the wizard, leave it as is for now.
3-3. Configuring Permissions for the Synchronization Domain User
With the initial setup wizard stopped, perform the initial configuration of the EntraConnectSvc user.
Unlike last time, the AWS documentation now includes the content of the initial configuration script.
Although there is slightly more error handling, what it actually does is the same as last time:
- Add read permissions for the domain using the
Set-ADSyncBasicReadPermissionscommand - Add write permissions for the Entra ID source anchor using the
Set-ADSyncMsDsConsistencyGuidPermissionscommand
Since this script uses Active Directory module features, install RSAT-AD-Tools first.
# (Requires administrator privileges) RSAT-AD-Tools must be installed in advance
Install-WindowsFeature RSAT-AD-Tools
Then save the following script content to an appropriate directory.
This time, following the AWS documentation, I'll save it to C:\temp\entra.ps1.
# For the latest version, see https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_connect_ms_entra_sync.html
$modulePath = "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
try {
# Attempt to import the module
Write-Host -ForegroundColor Green "Importing Module for Azure Entra Connect..."
Import-Module $modulePath -ErrorAction Stop
Write-Host -ForegroundColor Green "Success!"
} catch {
# Display the exception message
Write-Host -ForegroundColor Red "An error occurred: $($_.Exception.Message)"
}
Function Set-EntraConnectSvcPerms {
[CmdletBinding()]
Param (
[String]$ServiceAccountName
)
#Requires -Modules 'ActiveDirectory' -RunAsAdministrator
Try {
$Domain = Get-ADDomain -ErrorAction Stop
} Catch [System.Exception] {
Write-Output "Failed to get AD domain information $_"
}
$BaseDn = $Domain | Select-Object -ExpandProperty 'DistinguishedName'
$Netbios = $Domain | Select-Object -ExpandProperty 'NetBIOSName'
Try {
$OUs = Get-ADOrganizationalUnit -SearchBase "OU=$Netbios,$BaseDn" -SearchScope 'Onelevel' -Filter * -ErrorAction Stop | Select-Object -ExpandProperty 'DistinguishedName'
} Catch [System.Exception] {
Write-Output "Failed to get OUs under OU=$Netbios,$BaseDn $_"
}
Try {
$ADConnectorAccountDN = Get-ADUser -Identity $ServiceAccountName -ErrorAction Stop | Select-Object -ExpandProperty 'DistinguishedName'
} Catch [System.Exception] {
Write-Output "Failed to get service account DN $_"
}
Foreach ($OU in $OUs) {
try {
Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN $ADConnectorAccountDN -ADobjectDN $OU -Confirm:$false -ErrorAction Stop
Write-Host "Permissions set successfully for $ADConnectorAccountDN and $OU"
Set-ADSyncBasicReadPermissions -ADConnectorAccountDN $ADConnectorAccountDN -ADobjectDN $OU -Confirm:$false -ErrorAction Stop
Write-Host "Basic read permissions set successfully for $ADConnectorAccountDN on OU $OU"
} catch {
Write-Host "An error occurred while setting permissions for $ADConnectorAccountDN on OU $OU : $_"
}
}
}
With the script saved, run the Set-EntraConnectSvcPerms command as follows.
For the argument, specify the sAMAccountName of the synchronization user (in this case, EntraConnectSvc).
# Import the saved entra.ps1
Import-Module C:\temp\entra.ps1
# Configure permissions for the EntraConnectSvc user. Specify the sAMAccountName as the argument
Set-EntraConnectSvcPerms -ServiceAccountName 'EntraConnectSvc'
The execution result looks like this:


Some warnings are shown, but as long as you see logs like:
Permissions set successfully for CN=EntraConnectSvc,OU=Users,OU=corp,DC=shibata,DC=local and OU=Computers,OU=corp,DC=shibata,DC=local
and
Basic read permissions set successfully for CN=EntraConnectSvc,OU=Users,OU=corp,DC=shibata,DC=local on OU OU=Users,OU=corp,DC=shibata,DC=local
there should be no problem.
3-4. Initial Configuration of Entra Connect Sync
From here, we resume the initial setup wizard that was left on hold.
"Agree to the license terms" and click "Continue".

Next, select "Customize".

Leave the required component installation at default settings and click "Install".
(Customize as needed depending on your environment)

The installation of required components such as SQL Server Express Local DB will begin, so wait for a while.

Once the required component installation is complete, the following screen appears, where you will configure various settings.
This time I'll select "Pass-through Authentication".

Note that the AWS documentation specifies choosing either "Pass-through Authentication" or "Do not configure", and configurations other than these are likely unsupported.
Next, enter the Entra ID global administrator (or Hybrid Identity Administrator) account information.
This information is only used during installation.

Once you successfully sign in, the settings move to the Active Directory side.
With the target forest specified, click "Add Directory".

A dialog for configuring the synchronization user with Entra ID will appear. Select "Use existing AD account" and fill in the information for the EntraConnectSvc user created earlier.

If there are no issues, the domain will appear in the "Configured Directories" field, so click "Next" to proceed.

Next, configure the Active Directory attribute to use as the Entra ID username.
Normally, UPN (userPrincipalName) is used as the Entra ID username, so I'm leaving it as is.
(With this setting, synchronization becomes "Entra ID user's UPN ⇔ On-premises domain user's UPN")

Since we've added the alternative UPN suffix example.shibata.tech to the shibata.local domain, a warning "Continue even if some UPN suffixes do not match verified domains" appears, but since there's no problem, check the box and click "Next".
Next, select the synchronization targets.
Since this is an AWS Managed Microsoft AD environment, I'm configuring it to only sync the "NET BIOS name\Users" OU.

Decide on the identification method for the Active Directory domain side.
The default settings are fine here, so just click "Next".

No filtering settings are needed, so just click "Next".

Leave optional features at default and click "Next".

The final confirmation screen appears. Verify that the configuration is correct and click "Install".

Wait for the installation to complete.

When installation is complete, you'll see the screen below. Click "Finish" to close the wizard.

That completes the installation of Entra Connect Sync.
4. Verification
In this state, checking the Entra ID side shows that users are synchronized as shown below.
As in the previous time, I added a test user Nobunaga Oda and confirmed the synchronization.

As before, a Nobunaga Oda user was prepared and synchronization confirmed

Synchronized users can be identified by the "On-premises sync enabled" field.
Also, the state of Entra Connect Sync looks like this:

The agent information in use looks like this:

Status Check Tools and Manual Sync
To check the status on the Entra Connect Sync server side, it is convenient to use "Synchronization Service Manager".

While it may not be possible to understand the fine details, anyone can determine whether the status is normal or abnormal.
In addition, while the default sync interval is every 30 minutes, it is also possible to trigger an immediate sync from a PowerShell command.
# Run a delta sync immediately
Start-ADSyncSyncCycle -PolicyType Delta
# Run a full sync immediately
Start-ADSyncSyncCycle -PolicyType Initial
This document contains other useful commands as well, so it is worth reading through it.
Finally
That's all.
This is an update after 4 years, but I was able to use Entra Connect Sync in an AWS Managed Microsoft AD environment using almost the same steps as last time.
I hope the content of this article proves useful to everyone.
As of 2026, it has become difficult to casually create a new Entra ID Free tenant, which is unfortunate... ↩︎
