When migrating with the option Add source members to the corresponding target groups and after checking the target group, it can be noticed that not all source members are present in the target migrated group. Specifically, not all of the source members coming from the other trusted domains and represented as FSP (Foreign Security Principals) in the source are added to the target groups.
The behavior is by design - please refer to the resolution for more details.
In this particular example, based on the LinksResolver.log entries, the DSA is matching the source FSP to the existing target user that happens to already have this FSP's SID in the SIDHistory attribute:
AM4764852 Resolving external domain links to corresponding target objects or to external domain links (2 link(s))
AM57365744 Resolving links by domain
AM57365744 Start paging search: dn = DC=target,DC=local
AM57365744 search filter (&(objectClass=user)(objectCategory=user)(|(SIDHistory=\01\05\00\00\00\00\00\05\15\00\00\00\99\81\88\fb\d2\e9\62\71\2a\2e\d1\5f\43\0a\00\00)(SIDHistory=\01\05\00\00\00\00\00\05\15\00\00\00\99\81\88\fb\d2\e9\62\71\2a\2e\d1\5f\30\05\00\00)))
..............
AM57365744 resolved CN=S-1-5-21-4220027289-1902307794-1607544362-1328,CN=ForeignSecurityPrincipals,DC=source,DC=local -> CN=User1,OU=Users,OU=Test,DC=target,DC=local (GUID = 8024064316D6E54989930000A28DF6FB).
As a result, the DSA considers such instance as this source FSP, as already present as a member. This happens as a result of multiple migrations where the source domain was the migration target for the FSPs originating domain in the past. The correct procedure in this case would be to clean the SIDHistory on the originating source users so that the values from the previous migrations do not interfere with the current project.
