Quest OnDemand Migration for AD: Learn about these 3 Ways to Sync Passwords

Password synchronization is a key functionality of every AD/Entra migration product. And lately, it’s becoming more challenging to keep up with all Microsoft security enhancements while still providing the same password sync capabilities. Mostly due to that fact, just during this year alone two (!) newer ways to sync passwords have been introduced into the Quest OnDemand Migration product. In the current article, we will review how they are all compared to each other.

If sync engine is configured to create a new user account vs merge, the initial password is set per the job’s template configuration. This remains in the directory for a short while, until password sync comes along and overwrites it with the actual user’s password from Source. And the way the password is synced may come in three flavours.

  • 1st and 2nd Pwd Sync Options in Quest OnDemand Migration: RC4 Encryption-based, relying on LSASS Windows security subsystem

    • Legacy Password Sync (BTPass Service)
    • Modern Password Sync (Password PlugIn)

The first two password sync options have a lot in common (although do also share some key differences) and therefore will be described together.  The main difference is how the password agent is talking to the DC. Legacy password sync in Quest OnDemand Migration is accessing DC_NAME\ADMIN$ share to create/update BTpass folder with binaries, then using remote execution BTPAExec (similar to PSEXEC) to start BTpass utility remotely as a service. This service is then injecting btpassasm.dll into the LSASS process to work with the password hashes. This may cause some known issues like sudden  computer (DC!) reboots if more than one process is accessing lsass at the same time. Also, once Microsoft Advanced LSA protection is enabled on Domain Controllers, legacy password sync is no longer possible.

Modern password sync is installing a password plugin as LSASS Notification Package (credentials provider), which performs much the same function but in a different, more MS native fashion which is still allowed after Microsoft Advanced LSA protection blocked legacy lsass access.

After that, Quest OnDemand Migration (ODM) Sync Agent and Modern Password Filter Plugin are communicating over the shared pipe (encrypted with passphrase) to transfer password hashes. The rest of the functionality is essentially the same.

IMPORTANT: The terms “Password Filter Plugin” sometimes used in the context of both Modern Password Sync and Password Propagation Service. Please watch for the context very closely when reading various technical articles

      • For both Legacy and Modern (!) you must select a monitoring Quest OnDemand Migration (ODM) Sync Agent on the source and target sides, which will then interact with password service (agent) doing the rest. So in a way, Quest OnDemand Migration GUI regards these two password sync methods as “Legacy”.

Quest OnDemand Migration

      • “Allow password changes from other environments” is checked in the target environment. If 2-way password sync is in place, also check it in source.
      • User account is matched from source to the target. If 2-way password sync is in place, also match accounts from target back to source.
      • For Modern Password Sync in Quest OnDemand Migration:
        – Corresponding option has to be selected on each Domain controller under the Environment settings.
        Note: Make sure that ALL DCs in the environment’s Domain Controllers list are using the same pwd sync method
        – Quest OnDemand Migration (ODM) Sync Agent and Modern Password Plugin need to have the same passphrase specified during installation
        – At least one Modern Password Plugin needs to be installed per Domain.
        IMPORTANT: It installs directly on DC and reboot is required!
      • Password sync works in two modes and both are inseparable: through the workflow and using a background sync process. You cannot make it work only one way and not the other, once all password sync options are set per above descriptions, both background and workflow itself (when executing) will be syncing passwords.
      • Background and workflow password sync modes each have their own scopes. While workflow can select their own objects to sync via OU picker and LDAP filters, background password sync has Source Password Monitor LDAP filter (!) on the corresponding Source Environment.
        IMPORTANT: When these filters are modified, Sync Agent Service has to be restarted for the changes to take effect!
      • There are no specific password-related attributes in templates except unicodePwd, which will only be responsible for populating users password with the default one during user account creation. Whether you select unicodePwd attribute or not, password sync will still be happening in background and workflow modes.
      • The background password sync is working like this:
        – Every two minutes, Quest OnDemand Migration (ODM) Sync Agent is monitoring source domain by reading usnChanged attribute of AD objects and comparing it to the same value in the backend SQL database for those objects that were Read by workflow. This is logged on corresponding Agent Host in Application Log.
        – Once usnChanged is different, Sync Agent will perform a remote call to DC (BTpass or Modern PlugIn) to perform password hash extraction. This process will be recorded in pwlistener log files in the same BTpass folder in C:\Windows\ or under c:\ProgramData\Quest\PwCopy\ folder on DC
        – Extracted password hash will be compared to stored user’s password hash in the SQL database
        – If hashes are different, they’ll be updated in the SQL database and passed to the target environment Sync Agent, following matching direction and whether “Allow” checkbox is checked for the target or not. This is captured in the environment’s password sync logs.
        – Target Sync Agent will perform same actions with DC, this time applying changed password hash to the target userNotes / Useful Tips:
        – BTpass folder can be safely deleted on DC as it’ll be recreated again on demand. This is also used as a troubleshooting technique, when password sync is not working properly. Please make sure to stop Sync Agent service before deleting BTpass folder.
        – When switching from legacy to modern, it’s recommended to delete the BTpass folder on DC, otherwise Sync Agent may start using the legacy method even when DC is marked for modern
        – Every time Sync Agent is installed or reinstalled, it still force-deploys the legacy agent which can cause issues as multiple agents reaching to LSASS process can cause DC server reboot .. to get around this 1) stop the agent after install 2) delete the BTPASS folder 2) start it again or else it will push legacy agent to the DC. This is currently recognized as a defect and will be resolved in Q1 2025
        -Passphrase is encrypted and saved in the registry on Agent Host and DC. The value itself, although encrypted, can still be compared to ensure same passphrase is used in the environment. An alternative to agent reinstall when passphrase has to be updated could be exporting this registry value and re-importing on the DC itself, then restarting the agent service.

        LocalEntropy: This exists on Agent host and Domain Controller and different / unique.

        ServerSharedKey: This exists only on the Agent hosts .. does not exist on the DC.

        SharedKey: This exists on Agent Hosts and DC and is a passphrase in an binary encrypted value.

Quest OnDemand Migration

  • 3rd Pwd Sync Option in Quest OnDemand Migration: PPS – Password Propagation Service

Password Propagation Service is a component of Directory Sync that allows password synchronization in environments without RC4 Encryption. Unlike the Legacy Password Monitor Service, which requires RC4 Encryption, Password Propagation Service simply copies the password from the source to the target much like some other Quest products like Active Roles Sync Services.

When a password changes in the source, the password filter installed on every domain controller in the source environment will capture the password and use the Password Propagation Service to set the password in the target using LDAPS security

Installing and configuring the Password Propagation Service requires the following actions:

    • Enabling the Password Propagation Service option on the Environment Passwords Setting page and downloading the Password Propagation Service Download.
    • Installing the Password Change Service in the source environment.
    • Configuring the Password Propagation Server for the target environment where the passwords will be changed.
    • Note: The Password Propagation Service must be preconfigured with Windows Internet Information Server (IIS) and certificate provisioned.
    • Manually installing Password Filter on every Domain Controller in the source Active Directory forest.

By Alex Pavlenko