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

2-way directory sync expected behavior

Current config:

Source: AD, 2008 R2, Target: AD 2008 R2

DMM AD v8.13, no Exchange components (using ODME)

My customer has a requirement to sync AD passwords from target to source for legacy application support. I have never done a two-way sync before and have always been advised against it. Needless to say, I've set the tool up, narrowed my sync scope on the source to an OU of test accounts and a single OU on the target. I am using LDAP filters to control exactly what objects will get synchronized. About 90% of the source objects already have an object in the target domain.

In my initial test, I copied/merged a single source/target object. I started my initial sync and my expected behavior would be to see that the "synchronized objects" count would be "1". Instead, it went up to 14 and once I saw that, I stopped the DSA completely as I didn't want to break anything further. See graphic:

I exported the INI file and found the 14 objects in question. My questions are:

1. My understanding is that the DSA on initial sync of source and target environments will enumerate the entire source and target environments. Is that correct?

2. Why would the sync'd objects count increase beyond one? I double-checked my LDAP filter and it only retrieved a single object

3. I spot-checked a few of the 14 "synchronized objects" and they don't appear to be altered but I cannot be sure. Beyond the obvious, are there any other "gotchas" doing a two-way sync? I'd like to convince the customer that it's dangerous.

Sorry to the length of this. Appreciate anyone's assistance.

Regards,

Eric

  • Hi Eric,

    I'll see what I can do to answer your questions, but we may need a Service Request (Support ticket) to get to the bottom of it.
    1, Yes DSA definately does enumerate both source and target domains, unless you have an LDAP filter setup (as it sounds you do) in the "Specify Source Scope">"Set Filter">"Advanced Filter". With this in place it should only look at the objects with the attribute set to trigger the filter.
    2, Honestly, the items synchronized count should not exceed the # of items with the filter attribute set. Keep in mind, this is now a 2 way sync, so that filter would also have to be set in the "Specify Target Scope">"Set Filter">"Advanced" so that onl8y objects in the target with the attribute set are touched.
    3, The concern with 2 way synchronizations is that the target could be overwriting source attributes, so you need to be sure to "Skip Attributes" (Properties of the Synchronization, Advanced Options, Attributes to Skip), and ensure the direction is set target to source if you do not want attributes overwritten in source by target, and vs versa.

    I hope this give you some ideas, but you may want to create a Service Request with our support team to investigate further.
    Luke
    • Hello Luke-
      Thanks for your helpful reply.

      It sounds like the first thing to do is to set the LDAP filter on the target. I didn't think I needed to but it makes sense. My take was that the source is first enumerated, then the target, then any filters in place would limit which objects get synched but the ADLDS instance would contain all source/target objects.

      That said, all I want between target to source is the password - nothing else. Would you suggest I exclude all items in the "Attributes to skip" synchronization properties and set the direction to "Two-way sync"?

      At this point, I don't think I need to open a ticket but will do so if necessary
      Again, thanks for your help.
      Eric
      • HI Eric,

        As long as you are not skipping "UserAccountControl" which you shouldn't be able to out of the box, and not skipping "PWDLastSet" you should be fine to synchronize passwords, otherwise, if you just want to synchronize passwords, yes, you can just set ALL attributes to skip other than above, both ways.
        Luke
        • Great. You've been a tremendous help. Thanks again.
          Eric