[midPoint] Link User during New User Creation
Ivan Noris
ivan.noris at evolveum.com
Tue Dec 9 08:52:31 CET 2014
No problem, as the reconciliation results answered most of them.
Unmatched and Linked are the only expected situations for your case.
I.
On 12/08/2014 10:55 PM, Jason Everling wrote:
> I missed a few of your other questions, the reactions are to only
> match, unlink, or link.
>
> JASON
>
> On Mon, Dec 8, 2014 at 3:53 PM, Jason Everling <jeverling at bshp.edu
> <mailto:jeverling at bshp.edu>> wrote:
>
> Correct! Now when this is actually in production it should change
> to about 1000 from 20, we normally have about 1000 active
> students/faculty/staff every semester. The initial deployment I do
> not plan on importing all accounts, some are from many many years
> ago. That what all the sync conditions were for,
>
> Linked 19 Unmatched 14266
>
> Disputed 0 Unlinked 0 Nothing 0
>
>
> On Mon, Dec 8, 2014 at 3:44 PM, Ivan Noris
> <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>
> 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 <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
--
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/20141209/c9ed0dab/attachment.htm>
More information about the midPoint
mailing list