During the process of development, we discovered the following requirements for the writing to sidHistory to work.
– The process must run on the destination domain. Although the documentation for clonepr.dll says it must be run from the PDC, we did a test and ran it on a DC that can update sidHistory on other DCs. If running it on a DC, sidHistory is only set on that DC and AD replication should move the sidHistory.

– The process must be run from the same PDC that is referenced in the destination DC of the config file. Otherwise, an “Access is denied” error is returned.

– The process must reference the PDC of the source domain. Otherwise, an error will be reported that “The operation is only allowed for the Primary Domain Controller of the domain.”

– The account running the process must also have a foreign security principal in the source domain.

– The account must be an Administrator on the source domain.

– The account must have read write access to the sidHistory attribute destination domain. (A security group can be created to grant the account this right. In our environment, the account was also an ADMA account.)

– The account must have the “Delegate Control”->”Migrate SID” permission.

– The account change auditing needs to be enabled on both servers. (The document clonepr.doc has instructions on how to accomplish this.)

– The source domain needs a domain local security group called “DomainName” + “$$$”. No members need to be added to this group, but the process does add members to this group while it is migrating the SID and then removes the members from the group.

– The service account needs full control over the OU holding the objects that are having their sidHistory attribute populated.

In a FIM sync, without these settings, I was receiving a “permission-denied” error. These settings were for a separate program to migrate sidHistory.