Inconsistent Password Syncronization when users are migrated by ADMT

Scenario
You have source domain and target domain. PCNS 2010 is set up in the target domain.

Some users have the accounts in both domains. The password of the two accounts are different, for example, Password01! (source) and Password02! (target). You perform the user migration by using ADMT with password exported service (PES). The account with the password (Password01!) in source should be exported to the target. Find the user from target, its account option “User must change password at next logon” was checked. Then the user can login to the target domain with Password01!. It is allowed to login. However if the user tries login to the source domain with Password01!. The request is denied for incorrect password.




You can reproduce the problem by following to the next steps.

Environment

2 domains (Test01.com, Test02.com)

ADMT: Test01 -> Test02

PCNS: Test02 -> Test01

Test01.com:

Domain Functional Level: Windows 2000 Native

Forest Functional Level: Windows 2000

DC: DC1.Test01.com (Window 2003 SP2, PES is installed)

Client: Mem1.Test01.com   (Window 2003 SP2, ADMT 3.0 is installed)

 

Test02.com:

Domain Functional Level: 2008 R2

Forest Functional Level: 2008 R2

DC: DC2.Test02.com (Window 2008 R2, PCNS is configured)

Client: Mem2.Test02.com   (Window 2008 R2,  FIM is installed)

 

Reproduce procedure

1.       Create user account (user1) in Test01 with password (Password01!)

2.       Create user account (user1) in Test02 with password (Password02!)

3.       Run ADMT from Mem1.Test01.com

a.       Migrate the password

b.      Conflict Management: Migrate and merge conflicting objects (Before merging remove user rights for existing target accounts)

c.       Complete

4.       Check the user from DC2.Test02.com, its account option “User must change password at next logon” was checked.

5.       FIM Sync

6.       Manually uncheck the option.

7.       Logon from Mem2.Test02.com, the password (Password01!) can work.

8.       Logon from Mem1.Test01.com, neither the password (Password01!) nor (Password02!) could work.


Root Cause
During the migration in this case, the password in the target domain should be set twice.  FIM only captured the first password set.

The first password is a generated password that is put through the "normal" API's, so it will be captured by the password filter.  The second password reset, is with the already-hashed password from the source domain, which ADMT has to use a private API to write to the user account. The private API used by ADMT to write the password would not actually be caught by a password filter on the domain controller. It is a by design behavior as ADMT uses the private API.



Work Around
1.       Make the Inclusion group for the PCNS Target a group other than Domain Users
-          The ADMT migration should complete before the user was a member of the PCNS inclusion group.

2.       After the migration is complete, add the migrated users to the PCNS inclusion group.
-          All password operations that happen now will be properly synchronized.



Conclusion
There are 2 different password operations that are done via ADMT:

1. Generated password is set on the new account

    > This is the one that is synchronized to the PCNS Target

2. Private API is called by ADMT to write the already hashed password to the new account 

   > This cannot go through the regular password process, or it would end up being double-hashed, and so would not be the same as the source.