One of the most useful features of QMM Active Directory synchronization is the ability to synchronize the password of user objects between Active Directory Domains. While Microsoft’s Forefront Identity Manager (FIM) first needs to capture the user password on the Domain Controller when the user actual changes the password, QMM can transport the password hash directly at any time. While FIM needs to install an agent on every Domain Controller to capture the password changes, QMM places an agent “on the fly” on only one dedicated Domain Controller. This can make a big difference in large Active Directory infrastructures.
However, running a long term “ongoing continous” Active Directory synchronization often shows one or many errors like this (snippet from Migration Manager GUI) and fails to update the password to the actual value:
The error is a bit misleading here. QMM is purely transporting the password hash and therefore cannot measure the length of the user password nor can QMM prove the complexity. That means, we have to deal with a password history problem. Assuming we have the same password policies in source domain and target domain and an ongoing password synchronization, this error may never come up, because the password history policy of the source domain would prevent the user to change the password to a value that is still in the password history store.
But there is a second method of changing passwords: The admin reset of passwords. When an admimistrator changes (resets) the password on behalf of a user, he can set the password to a value that is in the password history store. An administrative reset can bypass the password policy. Our investigations showed that several users bypassed the password history policy by calling the help line …
After the administrative reset of the password in source domain, QMM directory synchronization agent (DSA) recognizes a change of the password of the user object and tries to replicate the password hash to the target domain user object. But the DSA has to go “through” the password policy check like a standard user password change which finally results in the password error message above.
You also can find specific error codes in the DSA log file:
05/07/13 08:32:45 (GMT+01:00) Common AcAdSwitches Error 0xe100004f. Cannot synchronize passwords, source user: “<user name>”, target user: “<user name>” Error 0x8007052d. Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.
In part 2 of this post, we will show ways to work around the password sync error.
Cloudy Migration Life 
Highly energetic article, I liked that a lot. Will there be a part 2?
Good post. I have come across this before in migrations – though this really summarizes it quite well.
I have also come across another scenario where password sync was “appearing” to fail. pwdlastset value was a newer value in source versus target domain by months on certain accounts. Curious indeed. Accounts were still in scope of DSA and had not been mis-matched accidentally to different target accounts or anything of that nature.
Looking at the DSA logs though, the password switch was attempted shortly after pwdlastset value date/time though the sequence ends with “passwords are already in sync”. Huh? Interesting.
What I found was that the IT Admins in some cases were checking “User must change password at next logon” and then un-checking this immediately. They were bypassing the password expiration in some cases for users who were remote and could not change their password that had recently expired, so had lost access to their e-mail on their mobile device. They were helping the user in a pinch, though forgoing security policies. While this helps the source user avoid resetting their password in the source domain – it does change the pwdlastset value in the source domain.
QMM DSA picks up the change and realizes source password is newer than target password based on the newer pwdlastset value when in fact – the password is the same. However, the logic of the Password Sync in QMM (Quest KB 13871) is such that it will not ‘sync/set’ the pwdlastset value on the target object unless it actually synchronizes the password.
1. Compare source and target “pwdLastSet” attribute and migrate password only if source value is newer
2. Get current password from target
3. Reset target “pwdLastSet” to 0 (set up “User must change password at next logon”) as this is required to workaround the “Minimum password age” policy
4. Get password from source
5. Set target password
6. Copy and set value of “pwdLastSet” from source
Makes sense. Though in this case, the target password will be considered ‘expired’ eventually even though the source expiry has essentially been bypassed… and likely when the user logs into the target domain for the first time they’ll be forced to change their password.