Migrate Active Directory Passwords with RC4 Disabled (Kerberos AES)
If RC4 is disabled in your Active Directory environment as a Kerberos encryption type, migrating passwords during a cross-forest migration can become a challenge. Modern domains often enforce Kerberos AES-only settings, which means password migration needs to handle more than just migrating plain NT hashes (MD4).
This article series shows how to migrate and synchronize passwords reliably even in modern, AES-only Kerberos environments. We start with the simplest setup: unidirectional password replication from one source domain controller to one target domain controller (no redundancy). This is the easiest way to validate connectivity, permissions, and the overall workflow before scaling out.
In the following parts, we build on this foundation and cover redundant deployments, two-way password replication, and more advanced designs such as using proxy domain controllers and star/hub replication topologies for enterprise environments.
Table of Contents:
- Requirements / Prerequisites
- Generating Self-Signed Certificates (Source and Target)
- Installing and Configuring the Password Synchronization (One-Way)
- Testing the Setup
- Conclusion
Requirements / Prerequisites
Before you start, you need a working source and target Active Directory environment with at least one domain controller on each side. In this first part, we intentionally keep the setup minimal: one source DC replicates password changes in one direction to one target DC, without redundancy. This makes it easy to validate that the filter, connectivity, and encryption setup are working correctly before you scale out.
For the setup itself, you only need to install the Password Synchronization Add-On on both domain controllers and have administrative access to complete the installation and configuration steps. Since password changes are transferred over a secured channel, a certificate is required, and for this guide, a self-signed certificate is perfectly sufficient.
This approach works both in classic environments where RC4 is still allowed and in hardened domains where RC4 has been disabled and only Kerberos AES encryption types are permitted.
Trial limitation: The trial version replicates up to 10 password changes. Please contact us at support@sys-manage.com to request an extended evaluation key.
Generating Self-Signed Certificates (Source and Target)
The Password Synchronization Add-On uses certificate-based encryption to securely transfer password change events between domain controllers. While creating self-signed certificates is not strictly required, it is often the easiest way to get started and makes the setup fully self-contained.
If you already have a Microsoft Windows Certification Authority (CA) in place and Group Policies are configured accordingly, your domain controllers may already have a suitable certificate automatically enrolled and deployed by Windows. In that case, you can simply re-use the existing DC certificate instead of creating a new one.
For this guide, we will create one self-signed certificate on the source domain controller and one self-signed certificate on the target domain controller. Both certificates will later be pinned during configuration, which allows the communication to remain secure without relying on Windows certificate chain trust.
To make the certificates easy to identify, it is recommended to use the computer name (DNS FQDN) as the certificate subject. You can create the self-signed certificate on Windows using PowerShell (no OpenSSL required). Run the following commands on each domain controller:
$fqdn = "$env:COMPUTERNAME.$env:USERDNSDOMAIN"
$cert = New-SelfSignedCertificate -Subject "CN=$fqdn" -CertStoreLocation "Cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddYears(5)
Export-Certificate -Cert $cert -FilePath "C:\Temp\$fqdn.cer"
Create and export the public certificate (.cer).
After the certificate has been created, you can view it in the local certificate store under:
Certificates (Local Computer) > Personal > Certificates
While the certificate can be selected directly using the Select certificate... dialog, it is still recommended to make a note of the certificate thumbprint. This can help avoid confusion in environments where multiple certificates with the same subject name (for example the same DNS FQDN) exist in the local certificate store.
For this first part, we will configure a simple one-way password synchronization from the source domain controller to the target domain controller. The goal is to replicate password changes from the source domain to the target domain without any redundancy or proxy servers.
Step 1: Install the Password Synchronization Add-On
Start by installing the Password Synchronization Add-On on both the source and the target domain controller. Run the PwdSyncAddon.msi package that matches the system bitness (64-bit or 32-bit).
During setup, select the Password Filter Add-On module for installation. Once the installer has completed, choose not to reboot yet — we will first complete the configuration on both systems and reboot afterwards.
Password Filter Installation
Step 2: Configure the Source Domain Controller (Sending)
On the source domain controller, launch the Password Filter Configuration tool.
On the first page, switch from Password hash migration (NT-Hash) to Password synchronization (NT-Hash and additional keys such as AES).
Password Filter Settings Source
Next, open the Synchronization Partners (Sending) tab to configure the replication partner on the target side.
Since this is a minimal setup without any proxy servers in the source environment, uncheck Allow incoming proxy connections.
Click Add... and add the target domain controller (for example dc02.target.com). You will also need to provide authentication information. The account used must have sufficient permissions in the target Active Directory to update user passwords for the synchronized users. This can be a delegated administrator account. In addition, it requires the necessary permissions to create user objects in the selected target OU/container if the option to automatically create users is enabled. For simplicity, we will use the built-in Administrator account in this example.
Recommendation: In production environments, use a dedicated account with delegated permissions.
After the partner has been added, open the Synchronization Encryption tab and click Select certificate... to select the self-signed certificate that was previously generated on the source DC.
Finally, click Import CA certificate and import the partner certificate that was previously exported on the target domain controller (for example dc02.target.com.cer from C:\Temp). This enables certificate pinning and ensures that the source DC only communicates with the intended replication partner.
Password Filter Encryption Source
Click OK to confirm the changes. When prompted, reboot the source domain controller to activate the password filter.
Step 3: Configure the Target Domain Controller (Receiving)
After the source DC has been configured, repeat the configuration on the target domain controller.
Launch the Password Filter Configuration tool and enable Password Synchronization. Then select the Receive password changes option.
Password Filter Settings Target
Next, open the Synchronization Encryption tab and click Select certificate... to select the self-signed certificate that was previously generated on the target DC.
Click Import CA certificate and import the partner certificate that was previously exported on the source domain controller (for example dc01.source.com.cer from C:\Temp). This completes the mutual certificate pinning between source and target.
Password Filter Encryption Target
Click OK and reboot the target domain controller when prompted.
Testing the Setup
After both domain controllers have been configured and rebooted, you can verify the setup by performing a simple password change in the source domain and confirming that the new password works in the target domain.
Create or select a test user that exists in both domains (or will be created automatically in the target container during synchronization). Then change the user password on the source domain controller.
Once the password change has been processed, try signing in with the same username and the new password in the target domain. If the login succeeds, the one-way password synchronization is working as expected.
You can also verify the password information on the target side by querying the user account with the built-in net user command. This can be helpful to confirm that the user exists in the target domain and that the account status looks correct:
net user <User-SAMAccount-Name> /domain
Note: Windows will not display the actual password, but the output provides useful information such as password set time and account status.
If the password does not work immediately, wait a short moment and try again. Password change events are processed asynchronously and may take a few seconds depending on network conditions and system load.
Tip: If password changes cannot be delivered temporarily (for example due to connectivity issues or certificate changes), the events can be queued and replayed once the connection has been restored.
Conclusion
You have now configured a simple one-way password synchronization from a single source domain controller to a single target domain controller. This setup is ideal for initial testing and for validating that password change events can be transferred securely, even in environments where RC4 is disabled and only Kerberos AES encryption types are permitted.
In the next parts of this series, we will build on this foundation and cover how to add redundancy, configure two-way password replication, and design larger synchronization environments using proxy domain controllers and star/hub replication topologies.