• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 20 subscribers
  • Views 4697 views
  • Users 0 members are here
Options
Related
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

One way password sync?

jimcapo_
over 5 years ago

Migration Manager 8.11

We currently have a sync job configured from DomainA ----> DomainB, in the hopes of eventually decommisioning DomainA. There is an external, non-transitive trust set up between the two domains. Currently, when a user changes their password on DomainA, it changes on DomainB (+/- 15 minutes, as that is when the sync does its deltas) as expected. Users are being migrated to new machines that are joined to DomainB. 

We've ran into an issue where users are only changing their passwds on DomainB - therefore, the accounts are going out of sync. We have pushed the fact that they should no longer be using their DomainA accounts, however, it seems they're still using them for whatever reason. 

We have a test lab set up, in an isolated environment:

DomainA - call this test2.lab

DomainB - call this test.lab

I have set up two users in each domain, and have migrated them from DomainB to DomainA using samaccountname matching

My manager has requested that we set up a password only sync - DomainB ----> DomainA. I configured a new sync job, DomainB ---->DomainA I thought of using group membership to filter this - this seems to work on the sync job I've configured in a test lab using an ldap filter on the source scope ((&(memberOf=CN=some-random-group,OU=Test Groups,OU=Domain Groups,DC=test,DC=lab)). However, we would also like to filter the original sync job (DomainA ---> DomainB) to ignore those users that have already been migrated so that the password syncs do not end up in a loop (user changes password on DomainA - this is syncd to DomainB, then the original sync job syncs from DomainB to DomainA, etc. etc.) 

I've tested a few things to filter the original sync job (DomainA ----> DomainB):

The ldap filter ((&(!(memberOf=CN=some-random-group,OU=Test Groups,OU=Domain Groups,DC=test,DC=lab)) on the TARGET scope - this does not work - the number of synchronized objects remains as 2

Syncing the same group DomainB ----> DomainA, then setting the same filter on the original sync  ((&(memberOf=CN=some-random-group,OU=Test Groups,OU=Domain Groups,DC=test2,DC=lab)) - this does not work - the number of synchronized objects goes down to 0 after stopping the job and re-syncing.

I realize this may be a mess, and I'm probably over thinking the solution - what would be the best thing to do here? 

Parents
  • 0 over 5 years ago

    Couple of thoughts here:

    1) QMM will not, by default, overwrite a newer password on a target object

    2) You have the right idea with your scoping but I normally use a simpler (?) approach whereby I use a "tag" attribute on the objects I want to have in scope on each side to drive my LDAP query to filter them in.  For example (wwwhomepage=syncme).  I would use Powershell to apply the tag value to objects I want processed.

    'Hope this helps a bit.

  • 0 over 5 years ago in reply to JohnnyQuest

    Thanks for your reply - where would I verify that newer passwds wouldn't be updated on a target object? 

    I thought about using an atrrib as well, one of the extensionattributes - would rather not have to modify any of the source objects in DomainA, though. If QMM will not update a newer passwd on an object, we might be able to get away with filtering the domainB ---> domainA sync - something to test. 

  • 0 over 5 years ago in reply to jimcapo_

    It's the default behavior and requires a Registry setting to change it. i.e. not the sort of thing you could change accidentally.

     Extension attributes are often a good option for "tagging".

  • 0 over 5 years ago in reply to JohnnyQuest

    excellent, thanks again.

Reply Children
No Data