• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 8342 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Password Sync in delta

anees.hussain
over 6 years ago

 Hi Team,


We have source and target forest in sync and currently delta sync is going as expected, though sometime I suspect issues in password sync.


Both new and Old domain supported by SD team and hence access have been given to them to reset password for users with instruction to reset password in source domain for non-migrated users, so that it can be sync in next delta sync to target.


The question here is if my SD team reset non-migrated user's password in target instead of source or reset in both, what will be issue?
Is password get sync from source to target domain when it gets expired next time as per policy if they reset password in target domain ?
Note: target to source domain sync is not enabled as of now.

  • 0 over 6 years ago
    If your users aren't being synchronized by the product "Non-Migrated" then we won't touch them at all. If they are being synchronized, but the target to source isn't enabled, then anything done in target won't synchronize back to source. If you reset password on both sides, it will know that they are same, and ignore that, and leave them as is.

    Hope this helps?
  • +1 over 6 years ago

    If you suspect issues in password sync, I would review the DSA log files for more info. Usually the problem is not the DSA itself.

    1.) Record the 'pwdlastset' attribute value of the source user object in question
    2.) Navigate to C:\Program Files (x86)\Quest Software\Migration Manger\DSA\CONFIGS
    3A) If the pwdlastset value is very recent, you might be able to open DSA.LOG to view the realtime log file
    3B.) If the pwdlastset value is older, you will need to open the child folder LOGARCHIVE and then extract the log from one of the .GZ files that is close to your date/time in question.
    4.) Search for the username (by samaccountname perhaps) in question - and you should find when the password sync was attempted.

    You might find an error like "cannot synchronize passwords.... unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain"

    One thing to note, is that even if you have the exact same values for the Password Policies between your source/target domains - you can still experience this error. How you ask?

    Password History! If you have an IT Administrator (your Service Desk) reset a source user account's password on their behalf - they have the ability to override 'remembered passwords'. So if you have an IT Admin who sets the password to a value that was in the user's password history, despite them being successful in the source domain - the DSA will be denied to set this value in the target.

    My advice would be to ensure source/target password policies are the same - and ensure your Service Desk asks users to reset their passwords on their own, so the value is unique/new.

    As for what will happen if they force a reset in the target as well... the DSA will not attempt to sync the source password if the pwdlastset value is greater (newer) in the target domain. This likely may not matter for you if both passwords are in fact the same (as set by your SD analyst). This is default behavior - though you can review this @ support.quest.com/.../password-copy-sync-process-and-password-setting-behavior-in-quest-migration-manager