[midPoint] Link User during New User Creation
Ivan Noris
ivan.noris at evolveum.com
Mon Dec 8 22:44:59 CET 2014
Jason,
what actions took place for the reconciliation? I.e. what situations
were configured to to apply what reaction?
If you were only linking (unlinked->linkAccount), not creating new users
in midPoint, I guess only about 20 users were linked and the rest of the
accounts were just searched and skipped after correlation expression has
been applied.
The recon results can be displayed by clicking Configuration - Shadow
Details and selecting the resource, kind and intent. In your case,
kind="account" and intent is almost for sure "default". You will see the
numbers/statistics of the accounts there.
I'd expect about 20 linked and the rest unmatched.
Regards,
I.
On 12/08/2014 10:32 PM, Jason Everling wrote:
> Yeah, I just did another database, our collaboration application, this
> one had almost 15000 records, now I am not sure if when Midpoint also
> has a lot of accounts, my testing environment only has about 20 users.
> Took about 9 minutes, I am pretty sure it is a full recon, I am
> clicking new task, selecting the resource and then running it,
>
> Task run last started Monday, 8. Dec 2014 14:53:57
> Task run last finished Monday, 8. Dec 2014 15:02:58
>
>
> 1000000000000042505
>
> com.evolveum.midpoint.common.operation.reconciliation.ResourceReconciliation
>
> SUCCESS
>
> Processed 14283 account(s), got 0 error(s)
>
>
> On Mon, Dec 8, 2014 at 2:55 PM, Pavol Mederly <mederly at evolveum.com
> <mailto:mederly at evolveum.com>> wrote:
>
> 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 <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
>
>
>
>
>
> 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
--
Ing. Ivan Noris
Senior Identity Management Engineer
evolveum.com evolveum.com/blog/
_____________________________________________
"Semper Id(e)M Vix."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141208/d988d876/attachment.htm>
More information about the midPoint
mailing list