[midPoint] DBTable - Users in Midpoint already exist in database
Ivan Noris
ivan.noris at evolveum.com
Thu Dec 4 15:30:44 CET 2014
Hi,
having updates enabled, but create/delete disabled is a valid
combination. I have used this during migration/upgrade of rules recently
to push the values generated in midPoint to other systems.
Regards,
Ivan
On 12/04/2014 03:22 PM, Jason Everling wrote:
> 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
> <mailto: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 <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 <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/20141204/3d7c309c/attachment.htm>
More information about the midPoint
mailing list