Issue #357 has been updated by Sébastien Bahloul. Status changed from New to Assigned Assigned to set to Sébastien Bahloul
What you describe is exactly what is done in the code. So the bad news is that if we want to do it in one pass, we have to change quite a lot the synchronization core code. The good news is you already found the workaround: launching LSC twice. By launching the code the first time without modrdn and then with modrdn, you should get a behavior closer to what you are looking for. And you get a second issue that is related with the duration of the LSC task which is amazingly long. May I ask you 1. if you have tried to do some searches with a filter based on employeeNumber=AVALUE to see if the search is really fast (i.e. indexed) ? 2. if you measured how long it takes from a simple directory tool to rename and modify AD entries ? Then it will be either a LSC issue or a Active Directory performance problem, the latter cannot be addressed by the LSC tool itself. ---------------------------------------- Bug #357: synch of RDN in DN only with modrdn set as true? http://tools.lsc-project.org/issues/357 Author: Gaylord Josupeit Status: Assigned Priority: High Assigned to: Sébastien Bahloul Category: Core Target version: 1.2.0 Problem in version: 1.2.0 Hello, we try to synchronize OpenLDAP to AD. The first synch to the "empty" AD is working correctly. When synching after having changed several Users, those RDN's according to the DN are not changed, if modrdn is set on false, while all other attributes get changed correctly! synching the RDN's of the DN's can only be done by setting modrdn to true, but requires two starts of the same script! On first run the specific RDN's in the AD are set to "newentry" with the new value, while the "oldentry" is deleted! This happens to all RDN's that have to be changed. After that the script stops and a second start becomes necessary to synchronize the complete dataset in the end! And that seems to be potentially dangerous, for what happens to users, that are being changed and want to log in to the system? They seem to be closed out until the synch is done. with the 2 test-users we used in the test-environment this all took about 2 minutes, but what if setting this up on the productive-environment with severals thousands of users? According to the documentation the script should work, even with or without setting modrdn as true, but it doesn't. So, why is it necessary to set modrdn to true? Thanks, G.Josupeit -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://tools.lsc-project.org/my/account
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-dev mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-dev
