• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 20 subscribers
  • Views 4674 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

    Just a few more comments. 

    1. Don't create a new Domain pair to support Target to Source sync. Create a two way sync on the DomainA to DomainB domain pair instead. This can create other issue and supportability can be impacted. 
    2. The MemberOf attribute is a bad idea. It is a read only attribute. As was already posted, using another unicode string attribute is the way to go. Tagging is very common (wwwhomepage=syncme) for example.

    Password sync for application coexistence using QMM AD can be slower then users expect. By default the sleep sync's interval is 15 min and if you have more than one domain pair being services from the same domain pair, it could be longer. Also replication of AD it'self as add to the conveyance time. The best way to do this is i a single Domain pair serviced by a single DSA server. The DSA agent should be configured in the agent control panel to use the PDCE as the preferred DC/GC for each of the domains. 

    The best user experience is to use something like the Active Roles Sync Service or Password Managers sync. Both of these leverage an agent on each DC that captures the password as it is changed and pushes that change to the target. 

    The net impact to a slow password sync is when the target user changes his/her password and tries to access an application that validates his\her password in the source. They will fail to authenicate and have to logon using the old password. You can see how this can be confusing. 

Reply
  • 0 over 5 years ago

    Just a few more comments. 

    1. Don't create a new Domain pair to support Target to Source sync. Create a two way sync on the DomainA to DomainB domain pair instead. This can create other issue and supportability can be impacted. 
    2. The MemberOf attribute is a bad idea. It is a read only attribute. As was already posted, using another unicode string attribute is the way to go. Tagging is very common (wwwhomepage=syncme) for example.

    Password sync for application coexistence using QMM AD can be slower then users expect. By default the sleep sync's interval is 15 min and if you have more than one domain pair being services from the same domain pair, it could be longer. Also replication of AD it'self as add to the conveyance time. The best way to do this is i a single Domain pair serviced by a single DSA server. The DSA agent should be configured in the agent control panel to use the PDCE as the preferred DC/GC for each of the domains. 

    The best user experience is to use something like the Active Roles Sync Service or Password Managers sync. Both of these leverage an agent on each DC that captures the password as it is changed and pushes that change to the target. 

    The net impact to a slow password sync is when the target user changes his/her password and tries to access an application that validates his\her password in the source. They will fail to authenicate and have to logon using the old password. You can see how this can be confusing. 

Children
No Data