In part 1 of this post we explained why QMM Directory Sync Agent (DSA) might run into problems when sychronizing user passwords that have been resetted by using administrative credentials to a value which is present in the password history. In this post we will show how we can identify affected user accounts and how we can work around the issue.
As we have learned in the first part, there are 3 good methods to identify the password synchronization errors:
- QMM AD GUI – failed objects link in the Status page of the Active Directory synchronization
- QMM Error Reporter Utility – Quest Utility you can download from support site
- DSA Log File Parsing – you can parse the log files with any good Parser/Scripting engine
Methods of resolving the password synchronization Problem:
1. User changes password
The simplest approach to solve the problem is the user himself – maybe after contacting the user. When the user changes the password of his Acive Directory account the default way (e.g. via CTR+ALT+DEL). Changing the password this way will ensure that the password policy of the domain is enforced (instead of bypassed via admin reset). Assumed that password policies between source and target domain are aligned, Quest Active Directory Synchronization Agent (DSA) will successfully set the new password on the target user account.
2. User is forced to change password
Another method similiar to 1. is to force the user to change the password by setting the “User must change password at next logon” flag. This can be achieved by using ADUC for single users.
However, when it comes to mass operations, you can achieve the same goal by setting the attribute “pwdLastSet” to “0” programmatically by using Powershell, VB etc.
Approach 1. and 2. have in common that you have to make sure that users do not call the help line and ask for an admin reset to their “usual” password again.
3. Temporary Fine Grained Password Policy controlled by DSA Parser script
Our customers often complain that they do not like to inform users to change their passwords with messages like “your actual password is not compliant with corporate policies – please change”. Educated users will ask: “How come that you know my password. We have been told, admins do not know users’ passwords …
Well, to workaround this situation, a new approach is possible if your target Active Directory domain is Windows 2008 or higher.
The plan:
- Increase DSA log file size to make sure you have a full DSA cycle in the log (optional). A full cycle will always work once through the failed objects queue and list the password sync Errors.
- Create a group in target domain that will contain user objects with password sync error.
- Create a Fine Grained Password Policy (FGPP) in target domain that contains the same password settings as the default domain policy with the exception of password history which is set to Zero
- Assign the FGPP to the domain group
- Create a script that parses the DSA log and fills the group. Empty the group before filling to remove already processed accounts
As you can see, the idea is to allow DSA temporarily and only once for the users with password sync problems to bypass the password history setting. This way the password transfer is possible and a further user migration will not end up in a logon error for these users.
From a security standpoint one can argue that bypassing the password history setting is not advisable. We share this opinion, but we have to recognize that the bypassing already started in the source domain. We neither improve the situation during migration, nor do we make it more worse. But we will prevent user logon errors to target domain later.
A scripting example (example, not more 😉 ) can be found here:
Powershell Script INPUT PWDUSER
Cloudy Migration Life 