[midPoint] DBTable - Users in Midpoint already exist in database

[Ivan Noris]

Jason,

yes, the reconciliation task is what you want to correlate the users.

Basically reconciliation and livesync are very similar, they both do the
same thing, correlate resource objects (i.e. accounts) and midPoint
focal objects (i.e. users). The difference is only WHEN do they do it.
The configuration is common for all, it's the <synchronization> part of
the resource.

While reconciliation task is/can be scheduled and will do everything in
one run, Livesync is for immediate synchronization to react to changes
as they are done in the source resource. There is also Import task,
which can be used to initially import data to midPoint from resource,
but basically it's very similar to reconciliation.

https://wiki.evolveum.com/display/midPoint/Synchronization
https://wiki.evolveum.com/display/midPoint/Synchronization+Flavors

One interesting option is to run the reconciliation with "dry-run" flag
enabled. This can be configured in GUI, Server tasks - edit task (or
while creating new task). The "dry-run" will cause midPoint to evaluate
the resource object and to detect the situation (like UNMATCHED,
UNLINKED etc.). The shadow objects will be created, but nothing else
will be changed on resource or in midPoint. This is great for testing
the "sanity" of the correlation rules. For example if you configure
synchronization for resource with many users that you expect to be
linked with existing midPoint users, and you go to "Configuration -
Shadow details" and lookup the resulting situations, if you have 90% of
UNMATCHED accounts, the correlation expression was probably not correct.

In your situation, where you already have existing accounts and users,
but they were not correlated, updating user in midPoint will do the
correlation as well. midPoint will try to do provisioning, it will fail
because the account already exists and if there is <synchronization>
section on the resource, it will try to correlate the just-discovered
(the conflicting) account and synchronize it. If the owner is the same
user as you were trying to provision, it will be linked and that's it.
Otherwise, the discovered account could even cause to add new user in
midPoint.
In case that there was the conflict AND the already existing account
will not correlate to the same user, iteration, if configured, will be
used to ensure that the original request (to provision account for that
user) is satisfied. Without iterator configuration, the request will
fail with "already exists".

There is one more thing you can do, if you're interested. If the DB
Table resource is only to be authoritative and you never want to
update/create/delete anything there from midPoint, you can use
capabilities in resource to disable create/update/delete operations. Any
attempt to execute that operation will then deliberately fail.

. . .
        </schemaHandling>

                <capabilities
xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3">
                        <configured>
                                <cap:create>
                                        <cap:enabled>false</cap:enabled>
                                </cap:create>
                                <cap:update>
                                        <cap:enabled>false</cap:enabled>
                                </cap:update>
                                <cap:delete>
                                        <cap:enabled>false</cap:enabled>
                                </cap:delete>
                        </configured>
                </capabilities>
        <synchronization>
. . .

But it all depends on how much authoritative the resource is and if you
really do not want to update data there.

Regards,
Ivan

On 12/04/2014 01:46 AM, Jason Everling wrote:
> Nevermind! I got it going by using a reconciliation task which linked
> all existing accounts!
>
> JASON
>
> On Wed, Dec 3, 2014 at 5:33 PM, Jason Everling <jeverling at bshp.edu
> <mailto:jeverling at bshp.edu>> wrote:
>
>     Another question, since the accounts already exists in the
>     application database, midpoint will link the accounts only after
>     the resource account is modified. Is there a way to force link
>     existing accounts without having to wait and modify the resource
>     account
>
>     For example:
>
>     John Doe is already in DBTable Resource
>     John Doe is already in Midpoint
>
>     Correlation will match employeeNumber.
>
>     So far, the only way to get midpoint to link the 2 accounts is to
>     modify the account on the resource, in the database table, I
>     modify some attribute then after I save the link is created in
>     Midpoint.
>
>     On Wed, Dec 3, 2014 at 3:15 PM, Jason Everling <jeverling at bshp.edu
>     <mailto:jeverling at bshp.edu>> wrote:
>
>         *wanted to double-check, not wouldn't, was a typo
>
>         On Wed, Dec 3, 2014 at 3:14 PM, Jason Everling
>         <jeverling at bshp.edu <mailto:jeverling at bshp.edu>> wrote:
>
>             I wouldn't to double-check this,
>
>             I setup database table resource but the database already
>             contains all our students/faculty/staff so I DO NOT want
>             midpoint creating accounts on the resource, all
>             push/update information for existing users.
>
>             I tested it and it seems ok, If I update a user in
>             midpoint it will automatically add the resource and link
>             the accounts. Basically all I am wanting to sync or update
>             to this resource is firstname/lastname and password along
>             with some other attributes that I have not yet defined.
>             Works so far but I wanted to make sure that midpoint would
>             not delete or create on this resource, only update if found.
>
>             I attached the resource, please when you have time take a
>             look at it.
>
>             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
> 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/20141204/4bb085f3/attachment.htm>