[midPoint] AD account duplication
Radovan Semancik
radovan.semancik at evolveum.com
Wed Jul 15 11:29:01 CEST 2015
Hi,
This is an interesting issue. We haven't expected that provisioning will
be slower than livesync.
The proper solution would be to implement what we call "asynchronous
provisioning". At least some parts of it. Specifically we should store
shadow before we attempt operation on resource. The asynchronous
provisioning is on midPoint roadmap for quite a long time. However
midPoint subscribers are asking for other features. Therefore the
asynchronous provisioning has been moved out on the roadmap several times.
Therefore, you have the usual options:
https://wiki.evolveum.com/display/midPoint/I+Need+New+Feature
I have created jira issues to track this:
https://jira.evolveum.com/browse/MID-2458
--
Radovan Semancik
Software Architect
evolveum.com
On 07/14/2015 01:25 PM, Pavol Mederly wrote:
> Илья, Алексей,
>
> yes, this is a strong reason.
>
> If immediate reaction to illegitimate situation is not required, it is
> possible to use the reconciliation task, running e.g. nightly. The
> race condition would be still there, but with a lot smaller
> probability. (Having said that, it is possible to run LiveSync as
> well, but with a longer interval - e.g. 1 hour - to minimize this risk
> of conflict.)
>
> Anyway, the serious solution is to log this issue into our jira, and
> we have to fix it. If you could attach log with model=TRACE,
> provisioning=TRACE, covering the two colliding operations, it would be
> perfect.
>
> But I feel the fix will not be very easy [unless someone has a very
> bright idea how to do it :)], so if you would need this in a specific
> time frame, please contact Igor Farinic.
>
> Best regards,
> Pavol
>
>> Hi Pavol,
>>
>> But how am I supposed to track, for instance, illegitimate
>> associations between account and groups performed directly in target
>> system if not by means of synchronization mechanism?
>>
>> Ilya
>>
>> *From:*midPoint [mailto:midpoint-bounces at lists.evolveum.com] *On
>> Behalf Of *Pavol Mederly
>> *Sent:* Tuesday, July 14, 2015 1:06 PM
>> *To:* midpoint at lists.evolveum.com
>> *Subject:* Re: [midPoint] AD account duplication
>>
>> :-( That's unfortunate. But in other installations it usually takes
>> only a few hundred milliseconds (except for initial connection
>> opening, which could take 20-30 seconds indeed).
>>
>> Is your connector opening a new remote PowerShell connection each
>> time? Because if not, subsequent operation should be much quicker.
>>
>> Anyway, couldn't you avoid using Live Sync from Exchange resource?
>>
>> We can fix this "race condition" issue in midPoint, but I'm not sure
>> how quickly.
>>
>> Pavol
>>
>> Power shell works very slow. It’s work takes about 35 second from
>> console.
>>
>> *From:*midPoint [mailto:midpoint-bounces at lists.evolveum.com] *On
>> Behalf Of *Pavol Mederly
>> *Sent:* Tuesday, July 14, 2015 12:35 PM
>> *To:* midpoint at lists.evolveum.com
>> <mailto:midpoint at lists.evolveum.com>
>> *Subject:* Re: [midPoint] AD account duplication
>>
>> Hello Alexej,
>>
>> are you sure you need Live Synchronization for Exchange resource?
>> If a resource is a target and a source at the same time, problems
>> may occur. It is best to avoid this, it it's not strictly necessary.
>>
>> However, 40 seconds for user creation process is a waaaaay too
>> long. Have you any idea why it takes so long?
>>
>> Pavol
>>
>> On 14. 7. 2015 11:28, Ващенков Алексей wrote:
>>
>> Hi, we have one more problem with Exchange.
>>
>> We create live synchronization task with Exchange connector.
>> And it bring us one problem.
>>
>> Too many iterations (6) for account(ID
>> {http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3}uid
>> = [ <GUID=af020927ab893540bf7ca32f4ad86f30> ], type
>> 'default',
>> resource:8790e490-326a-46e9-ba35-9e0c1dcbb41d(Exchange))
>> <resource:8790e490-326a-46e9-ba35-9e0c1dcbb41d%28Exchange%29%29>:
>> cannot determine values that satisfy constraints: Found more
>> than one object with attribute
>> {http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3}uid
>> = [ <GUID=af020927ab893540bf7ca32f4ad86f30> ], Found more
>> than one object with attribute
>> {http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3}name
>> = [ CN=abaulin.d.v,OU=????????????
>> ????,OU=inrights,DC=isim,DC=local ]
>>
>> I see this situation like “Live synchronization” task was
>> started after user creation process (it take about 40
>> seconds) and finished before creation process ends. In this
>> case “Live synchronization” see “new” AD account which
>> already created with “Creation process” (but doesn’t ends
>> because waiting for ends of Exchange creation) and create new
>> shadow. After that “Creation process” ends and returns UID of
>> “new” shadow but it doesn’t know that shadow already exists
>> (in “Live synchronization” process).
>>
>> What can we do with this situation?
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> midPoint mailing list
>>
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> _______________________________________________
>>
>> midPoint mailing list
>>
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> 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/20150715/47a4c784/attachment.htm>
More information about the midPoint
mailing list