[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