[midPoint] DBTable - Users in Midpoint already exist in database
Jason Everling
jeverling at bshp.edu
Thu Dec 4 15:22:35 CET 2014
Thanks for the explanation, very helpful. I think I will add the capability
statements for create and delete, I do want updates. This resource
currently imports users from Active Directory but it is a one time thing
and changes made later to the account in AD are not updated and also
passwords are not sync'd. Having it in midpoint, the password/email
address/ and a few other attributes will be updated as the changes are made
in Midpoint.
I am just now looking at all the other possibilities from just syncing with
our student system!
Thanks Again!
JASON
On Thu, Dec 4, 2014 at 1:59 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 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"
> <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> 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>
>> 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>
>>> 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 listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer
> evolveum.com evolveum.com/blog/
> _____________________________________________
> "Semper Id(e)M Vix."
>
>
> _______________________________________________
> midPoint mailing list
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141204/7bce6f9f/attachment.htm>
More information about the midPoint
mailing list