none
ObjectSID as Anchor? RRS feed

  • Question

  • Hi,

    We need to sync a Source Forest (few thousand users) to a Target Resource Forest (on-going basis).

    UPNs, samaccountNames, and most other identifying attributes in the Source Forest can change over time...so using any of these as the anchor won't work.

    Can we use something like the ObjectSID in the Source Forest, and export that ObjectSID into a custom attribute in the Target Forest - to be used as the anchor on the AD MAs?

    Thank you,

    SK

    Wednesday, March 29, 2017 12:53 AM

Answers

  • Hello Shim,

    Using ObjectSID as anchor is not a good idea as User's SID can change. If you don't want to use DN (which also can change over time when you move user from one OU to another) I would recommend using Active Directory's GUID. As long as object exists in AD, GUID is kept.

    Of course it would be useful to migrate ObjectSID to SIDHistory in another forest so access to various places will be maintained. But as anchor/join attribute I would use ObjectGUID flown to some attribute in the final forest  - extensionAttribute1 or another not used attribute.

    /DT


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    • Marked as answer by Shim Kwan Thursday, March 30, 2017 10:15 PM
    Wednesday, March 29, 2017 5:48 AM
  • I'd use objectGUID as well here given the choice. Keep in mind this is only necessary if you are joining existing accounts or need to rebuild the sync engine metaverse from scratch.

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Shim Kwan Thursday, March 30, 2017 10:15 PM
    Wednesday, March 29, 2017 4:04 PM
    Moderator

All replies

  • Hello Shim,

    Using ObjectSID as anchor is not a good idea as User's SID can change. If you don't want to use DN (which also can change over time when you move user from one OU to another) I would recommend using Active Directory's GUID. As long as object exists in AD, GUID is kept.

    Of course it would be useful to migrate ObjectSID to SIDHistory in another forest so access to various places will be maintained. But as anchor/join attribute I would use ObjectGUID flown to some attribute in the final forest  - extensionAttribute1 or another not used attribute.

    /DT


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    • Marked as answer by Shim Kwan Thursday, March 30, 2017 10:15 PM
    Wednesday, March 29, 2017 5:48 AM
  • I'd use objectGUID as well here given the choice. Keep in mind this is only necessary if you are joining existing accounts or need to rebuild the sync engine metaverse from scratch.

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Shim Kwan Thursday, March 30, 2017 10:15 PM
    Wednesday, March 29, 2017 4:04 PM
    Moderator
  • Thank you for the advice!
    Thursday, March 30, 2017 10:15 PM
  • Hi all,

    would like to add some thoughts on this topic:

    Why can't we stop talking about "anchor/join attribute" as if they were the same?? Adding the same confusion regarding this terms in almost every thread...

    "Anchor" is the term (and attribute) which is used to maintain the "connection" between an external system (aka "connected data source") and the MIM "connector space" for that particular data source. AFAIK for the AD management agent this anchor attribute is NOT changeable and it is objectGUID.

    "Join rule": the attribute(s) here are used to link a "connector space" object to an already existing "metaverse object". And even this is a "one-time linking action" as the Join rule is executed only if the object isn't already joined to the metaverse (aka "Disconnector"). In the case of a "Connector" the relationship between the "connector space" and the "metaverse" is maintained internally at DB level.


    67567

    Thursday, April 13, 2017 2:36 PM