[midPoint] Link User during New User Creation
Pavol Mederly
mederly at evolveum.com
Mon Dec 8 21:55:31 CET 2014
Jason,
are you sure it was really a full recon? :-) E.g. wasn't that a dry run
in your case?
In my case, I have a testing OpenDJ LDAP server, a local PostgreSQL
database, and a full recon takes approximately 80 milliseconds per user:
Finished resource part of object:...(Localhost OpenDJ) reconciliation:
Processed 1004 account(s), got 0 error(s) Average time for one object:
66.80677 ms (*wall clock time average: 77.61056 ms*).
Yours 27 minutes = 40,5 milliseconds per user seems to be quite
impressive :)
Best regards,
Pavol
> I did a reconcile already from that last time I figured out how to do
> it from one of the previous discussions. I just didn't know if it were
> a standard to do a daily recon on a resource.
>
> It took 27 minutes to do a full Recon, I only have 6 attributes which
> 3 are outbound and 3 is both in/out. Name, Last, Phone, Email,
> Department, Profile (extension). This is a VMware VM on my workstation
> also, so surprisingly fast because the virtual disk is on the same
> disk as 10 other running VMs.
>
> I have almost 6 different resources now, various types, 2 of which are
> this type where the resource already has the accounts.
>
> I also upgraded to 3.1 Snapshot, just so I am creating all the objects
> on the latest version.
>
>
> On Mon, Dec 8, 2014 at 1:27 PM, Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>> wrote:
>
> Hi Jason,
>
> 40.000 accounts is not an issue itself. Just be adwised that
> performance strongly depends not only the number of users, but
> also on configuration of mappings, logging, tracing etc. In other
> words, linking the account is one thing, provisioning changes
> during the recon takes more time.
>
> Anyway we appreciate any information about the performance in your
> case when it's finished.
>
> And don't forget to run the dry-run recon first to be sure about
> your correlation rules.
>
> Thanks,
> Ivan
>
>
> On 12/08/2014 06:45 PM, Jason Everling wrote:
>> Ok thanks, that is what I figured so I just wanted to make sure
>> that was the case. I am going to remove that configuration, it
>> should never create anyways, users will always be listed on that
>> resource first way before midpoint would ever even create the
>> midpoint user account.
>>
>> I could also just leave that and run Reconcile on the resource
>> nightly, it has 40,000 objects, that should not be an issue right?
>>
>> JASON
>>
>> On Mon, Dec 8, 2014 at 11:42 AM, Ivan Noris
>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>>
>> Hi Jason,
>>
>> as the error states, and based on what you've written earlier
>> about disabling creates, it's because the create capability
>> is disabled (deliberately). midPoint tries to create (add)
>> account and the decision that it should be converted to an
>> update comes just after the collision is detected.
>>
>> I.
>>
>>
>> On 12/08/2014 06:26 PM, Jason Everling wrote:
>>> I figured that this was the case and I read on the wiki..
>>>
>>> "Technically, when midPoint user is assigned a role that
>>> should provision account on target system and the account
>>> already exists (= can be correlated), it will be updated.
>>> But the decision is made upon the provisioning request."
>>>
>>> But it does not work, it errors out. Maybe because my
>>> resource has create and delete disabled? Midpoint will never
>>> create or delete accounts in this resource.
>>>
>>> <cap:create>
>>> <cap:enabled>false</cap:enabled>
>>> </cap:create>
>>> <cap:delete>
>>> <cap:enabled>false</cap:enabled>
>>> </cap:delete>
>>>
>>> Starting error,
>>>
>>> com.evolveum.midpoint.util.exception.SystemException:
>>> com.evolveum.midpoint.util.exception.SystemException:
>>> java.lang.UnsupportedOperationException: Resource does not
>>> support 'create' operation
>>>
>>> This is when I have a role that has an inducement for this
>>> resource which I would have thought would just link since it
>>> already exists, the correlation is employeeNumber like all
>>> of my other resources.
>>>
>>> JASON
>>>
>>> On Mon, Dec 8, 2014 at 10:52 AM, Ivan Noris
>>> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>>
>>> wrote:
>>>
>>> Hi Jason,
>>>
>>> in general, the deployment is as follows:
>>>
>>> 1. import/reconcile from source system(s) to create
>>> identities (users) in midPoint. This may also create
>>> additional accounts in other systems (i.e. that were not
>>> provisioned before).
>>> 2. create reconciliation tasks for all other systems,
>>> where the accounts already exists and should be linked
>>> to midpoint identities.
>>>
>>> Based on the mappings in your resources, the
>>> reconciliations may modify the data on the reconciled
>>> resources (outbound mappings).
>>>
>>> Technically, when midPoint user is assigned a role that
>>> should provision account on target system and the
>>> account already exists (= can be correlated), it will be
>>> updated. But the decision is made upon the provisioning
>>> request.
>>>
>>> So I'd recommend to setup the reconciliation tasks, and
>>> start them first with the "dry-run" flag to see how many
>>> accounts can be correlated to midPoint users.
>>>
>>> Regards,
>>> Ivan
>>>
>>>
>>> On 12/08/2014 04:51 PM, Jason Everling wrote:
>>>> So here is the scenario,
>>>>
>>>> There is a DBTable resource that already has all the
>>>> accounts, midpoint will not create or delete from this
>>>> resource.
>>>>
>>>> The user does not exist yet in Midpoint, The users are
>>>> created in midpoint using another DBTable resource.
>>>>
>>>> How can I link the newly created user in Midpoint to
>>>> their account in the other resource,
>>>>
>>>> I can do this by running a reconcile task on the
>>>> resource but is there any other way to link users to
>>>> accounts on other resources since they already exist
>>>> without having to run reconcile on the resource everytime?
>>>>
>>>> Thanks,
>>>> JASON
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE:
>>>> This e-mail together with any attachments is
>>>> proprietary and confidential; intended for only the
>>>> recipient(s) named above and may contain information
>>>> that is privileged. You should not retain, copy or use
>>>> this e-mail or any attachments for any purpose, or
>>>> disclose all or any part of the contents to any person.
>>>> Any views or opinions expressed in this e-mail are
>>>> those of the author and do not represent those of the
>>>> Baptist School of Health Professions. If you have
>>>> received this e-mail in error, or are not the named
>>>> recipient(s), you are hereby notified that any review,
>>>> dissemination, distribution or copying of this
>>>> communication is prohibited by the sender and to do so
>>>> might constitute a violation of the Electronic
>>>> Communications Privacy Act, 18 U.S.C. section
>>>> 2510-2521. Please immediately notify the sender and
>>>> delete this e-mail and any attachments from your computer.
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>> --
>>> Ing. Ivan Noris
>>> Senior Identity Management Engineer
>>> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
>>> _____________________________________________
>>> "Semper Id(e)M Vix."
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE:
>>> This e-mail together with any attachments is proprietary and
>>> confidential; intended for only the recipient(s) named above
>>> and may contain information that is privileged. You should
>>> not retain, copy or use this e-mail or any attachments for
>>> any purpose, or disclose all or any part of the contents to
>>> any person. Any views or opinions expressed in this e-mail
>>> are those of the author and do not represent those of the
>>> Baptist School of Health Professions. If you have received
>>> this e-mail in error, or are not the named recipient(s), you
>>> are hereby notified that any review, dissemination,
>>> distribution or copying of this communication is prohibited
>>> by the sender and to do so might constitute a violation of
>>> the Electronic Communications Privacy Act, 18 U.S.C. section
>>> 2510-2521. Please immediately notify the sender and delete
>>> this e-mail and any attachments from your computer.
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer
>> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
>> _____________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE:
>> This e-mail together with any attachments is proprietary and
>> confidential; intended for only the recipient(s) named above and
>> may contain information that is privileged. You should not
>> retain, copy or use this e-mail or any attachments for any
>> purpose, or disclose all or any part of the contents to any
>> person. Any views or opinions expressed in this e-mail are those
>> of the author and do not represent those of the Baptist School of
>> Health Professions. If you have received this e-mail in error, or
>> are not the named recipient(s), you are hereby notified that any
>> review, dissemination, distribution or copying of this
>> communication is prohibited by the sender and to do so might
>> constitute a violation of the Electronic Communications Privacy
>> Act, 18 U.S.C. section 2510-2521. Please immediately notify the
>> sender and delete this e-mail and any attachments from your
>> computer.
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer
> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
> _____________________________________________
> "Semper Id(e)M Vix."
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and
> confidential; intended for only the recipient(s) named above and may
> contain information that is privileged. You should not retain, copy or
> use this e-mail or any attachments for any purpose, or disclose all or
> any part of the contents to any person. Any views or opinions
> expressed in this e-mail are those of the author and do not represent
> those of the Baptist School of Health Professions. If you have
> received this e-mail in error, or are not the named recipient(s), you
> are hereby notified that any review, dissemination, distribution or
> copying of this communication is prohibited by the sender and to do so
> might constitute a violation of the Electronic Communications Privacy
> Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender
> and delete this e-mail and any attachments from your computer.
>
>
> _______________________________________________
> 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/20141208/3f5eb652/attachment.htm>
More information about the midPoint
mailing list