[midPoint] Question about syncing situation

Pavol Mederly mederly at evolveum.com
Tue Jun 14 13:55:57 CEST 2016


Aivo,


yes. But if the sync operations go in another order (e.g. CSV import 
first, then reconciliation of AD groups, then AD users, and then perhaps 
again CSV import), is the problem fixed? Or midPoint ends in a wrong state?


Pavol


On 14.06.2016 13:54, Aivo Kuhlberg wrote:
>
> Hi Pavol,
> Thanks for the answer. Don't know if this is a bug or my bad syncing 
> configuration. I can avoid it by syncing in following order:
> First, doing reconciliation of AD groups -> this restores the deleted 
> AD group
> Second, doing reconciliation of AD/Exchange users -> this restores AD 
> group user membership
> Third, doing CSV import of users -> this reimports all users data to 
> midPoint and provisions the changes to  AD/Exchange
>
> Regards,
> Aivo Kuhlberg
>
> ------------------------------------------------------------------------
> *Saatja:* midPoint <midpoint-bounces at lists.evolveum.com> nimelPavol 
> Mederly <mederly at evolveum.com>
> *Saadetud:* 14. juuni 2016 14:28
> *Adressaat:* midpoint at lists.evolveum.com
> *Teema:* Re: [midPoint] Question about syncing situation
>
> Hello Aivo,
>
>
> midPoint should be able to resolve such situations; although maybe not 
> in one iteration (of CSV import). It might be possible that a sequence 
> of operations, like:
>
> - import from CSV
>
> - AD reconciliation or user/role recomputation
>
> is necessary to completely recover from such situations.
>
>
> If there's a sequence of these operation that results in a wrong 
> midPoint state (i.e. state that requires manual intervention), it is a 
> bug.
>
>
> From your mail I'm not sure if manual intervention is really 
> necessary, or if a sequence of import + reconciliation operations 
> would solve the problem.
>
>
> If the former, I would suggest inspecting your synchronization 
> settings (in particular, correlation search filter, including matching 
> rules).
>
>
> (My personal experience with midPoint failing to recover from similar 
> strange situations is just like that; after correcting the correlation 
> rules midPoint was able to recover from those, although not within one 
> import operation.)
>
>
> Hope this helps.
>
> Pavol
>
>
> On 07.06.2016 10:10, Aivo Kuhlberg wrote:
>
>> Hi,
>>
>> I have question about one syncing situation. I import users from 
>> CSV-file and use Exchange connector to sync both AD/Exchange user 
>> accounts and groups (as roles). I am testing following situation:
>>
>>  1. I create a new group "testgroup" in AD
>>  2. I run reconciliation of AD groups and I see that new midPoint
>>     role "testgroup" is created from AD group.
>>  3. Now I assign this newly created role to midPoint user "testuser".
>>     I see that the same AD user account is now group member of
>>     testgroup in AD.
>>  4. Now I delete in AD group testgroup. This should be OK as midPoint
>>     is able to restore deleted AD group and its members.
>>  5. After that I do import of users from CSV file. I understand this
>>     is unusual situation and I probably should have done before that
>>     reconciliation of AD groups and users but I just wanted to see
>>     what happens. What happens is that after CSV file import AD group
>>     is restored in AD but AD user is not member of this group.
>>     Another thing what happens is that I see following error:
>>
>> 2016-06-06 15:04:01,881 [RESOURCE_OBJECT_CHANGE_LISTENER] 
>> [midPointScheduler_Worker-7] ERROR 
>> (com.evolveum.midpoint.model.impl.lens.ChangeExecutor): Error 
>> executing changes for (entitlement (group) on 
>> resource:c2c5a39d-44ca-4b84-8cba-82e906cf3564(Exchange)): Couldn't 
>> add object. Object already exists: Object already exists on the 
>> resource: 
>> org.identityconnectors.framework.common.exceptions.AlreadyExistsException(The 
>> object already exists.??: when creating 
>> LDAP://server.my.domain/CN=testgroup,OU=Service1,OU=Services,OU=TEST2,DC=my,DC=domain)->org.identityconnectors.framework.impl.api.remote.RemoteWrappedException(The 
>> object already exists.??: when creating 
>> LDAP://server.my.domain/CN=testgroup,OU=Service1,OU=Services,OU=TEST2,DC=my,DC=domain)
>>
>> When I look at the shadow information of testgroup and testuser then 
>> I see that they have now following attributes:
>> For testgroup:
>> <dead>true</dead>
>> <synchronizationSituation>deleted</synchronizationSituation>
>>
>> and for testuser:
>> <dead>true</dead>
>> <synchronizationSituation>linked</synchronizationSituation>
>>
>> I have to fix this situation by deleting manually testgroup and 
>> testuser shadows and do reconciliation of AD groups and users.
>>
>>
>> Has anybody tested that situation and should midPoint 3.3.1 be able 
>> to resolve that situation automatically or is it too complex 
>> situation and I just have to avoid it by doing AD groups and users 
>> reconciliation every time before importing users fom CSV file?
>>
>> Thanks,
>> Aivo Kuhlberg
>>
>>
>> ------------------------------------------------------------------------
>> Käesolev e-kiri võib sisaldada asutusesiseseks kasutamiseks 
>> tunnistatud teavet.
>> This e-mail may contain information which is classified for official 
>> use.
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> ------------------------------------------------------------------------
> Käesolev e-kiri võib sisaldada asutusesiseseks kasutamiseks 
> tunnistatud teavet.
> This e-mail may contain information which is classified for official use.
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160614/f15f426f/attachment.htm>


More information about the midPoint mailing list