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

Populate SIDHistory attribute with SID from old domain - no trust in place (QMM for AD)

I've got a peculiar set of circumstances that require me to populate the SIDHistory attrubiute.

 

Example - User John has an account in Old.Domain, and already has an account provisioned in new.domain.
There is no trust in place.

I need to write SID.John.Old.Domain into the SIDHistory attribute for John.new.domain

 

I have no need for anything else. I understand its a woeful under-utilization of the tool. Whats the best way to fulfill my scenario, in terms of setting up the tool?

  • I dont know whether i am correct or wrong in answering this question but to my understanding this is what i came up with hope it is helpful,
    if the sid history is not set then you need to do following things
    1) Disable SID filtering and enable the trust between the source and target domain
    2) Remigrate the objects using the tool then you can easily populate the SIDHistory

    Note: The powershell commands should enable sid history and quarantine is set to no

    finally do this After this migrate a user account or right click on existing user migration session and perform it again and this time select merge option (you selected never merge skip option first i believe).

    Thank u
  • Hi,
    Thanks for your input, but unfortunately this is not what I am looking for.
    I CANNOT put a Trust in place.

    All I need to do is : Write SID.John.Old.Domain into the SIDHistory attribute for John.new.domain
  • With Migration manager for AD, all you have to do is check the box and sidhistory will migrate. Migration Manager for AD supports Trustless migration. All the trust does is allow sidhistory to be used to access resource in the source. It has not bearing on if the tool can write it. How useful it will be once written is another question.

    So to configure the domain pair, the source will use an account from the source and the target will use account from the target. The target account will have to be a member of the Target "Administrators" group to install and use the agent that migrates sidhistory. Once that is done, a migration session or directory sync can set Sidhsitory when the check box is checked. If you get an error, review the log and query the error at support.quest.com
  • Jeff, can this trustless migration be done "offline" - i.e. for staging prior to the establishment of connectivity between domains or must this be executed with connectivity between domains?  I'd presume the latter?  I guess, IOW, is it possible to take the SID history from source and sneakernet it to the target domain and apply it to existing security principals in the target domain?

  • No, and Yes. The Directory Sync Agent (DSA) connects directory to both domain controllers at the same time. So that is the NO. 

    Now you could do a two hop migration, Source to Stage, sneaker the Stage DC to Target. Then migrate Stage to Target. Then you could run Active Directory Processing Wizard (ADPW) to remove the Stage SIDs from sidHistory. 

    Now I don't see a reason to do what you are asking as sidhistory is know to cause some well known applications issues once the trust is in place. So having the sids in the directory is going to deliver what functional? 

  • Thanks, Jeff.   

    Yeah, don't disagree that having the SIDs without connectivity and trust is useless.  Kind of in a similar situation and peculiar circumstances as the OP.

    Let me follow where I failed to articulate originally.  

    Would we have the ability to write Source SID on EXISTING ID's in target domain, non-destructively to those existing target IDs?  Our peculiar situation is that new identities have been provisioned in the target domain way before we ever thought of integrating them properly.  We're looking for the ability to write sidHistory from the source domain onto those existing IDs without having to burn them down and start over...  Any precedent here?