A few weeks back I was looking at migrating users between forests using ADMT when the source and target domain names are similar. It worked in my virtual environment but when we went to put it into practice there were some issues caused by different people’s perception of what the sIDHistory attribute will do.

sIDHistory will not avoid the need to enter the correct password to access resources in the original domain.

If there is a trust in place, then the trusting domain will trust users in the trusted domain.

If there is no longer a trust (or as in my client’s case, where there was no direct trust but a sequence of non-transitive external trusts) then sIDHistory will allow migrated users security credentials to be compared with the access control entries (ACEs) in the access control list (ACL) for a resource and if there is a match then they will be authorised; however they still need to be authenticated.

If the passwords are the same in the new and the old domains, then there will be no password prompt (as the hashes will match and the user will authenticate transparently); however if there are different passwords in use, then the correct password for the user’s old account in the resource domain will still need to be supplied.

Further reading

Unable to browse users in trusted domain (Microsoft knowledge base article 263956).
How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003 (Microsoft knowledge base article 326480).
How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2 (Microsoft knowledge base article 322970).