<div dir="ltr">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.<div><br></div><div>I am just now looking at all the other possibilities from just syncing with our student system!<br><div><br></div><div>Thanks Again!</div><div>JASON</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 1:59 AM, Ivan Noris <span dir="ltr"><<a href="mailto:ivan.noris@evolveum.com" target="_blank">ivan.noris@evolveum.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Jason,<br>
<br>
yes, the reconciliation task is what you want to correlate the
users.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<a href="https://wiki.evolveum.com/display/midPoint/Synchronization" target="_blank">https://wiki.evolveum.com/display/midPoint/Synchronization</a><br>
<a href="https://wiki.evolveum.com/display/midPoint/Synchronization+Flavors" target="_blank">https://wiki.evolveum.com/display/midPoint/Synchronization+Flavors</a><br>
<br>
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.<br>
<br>
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.<br>
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".<br>
<br>
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.<br>
<br>
. . .<br>
</schemaHandling><br>
<br>
<capabilities
xmlns:cap=<a href="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3" target="_blank">"http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3"</a>><br>
<configured><br>
<cap:create><br>
<cap:enabled>false</cap:enabled><br>
</cap:create><br>
<cap:update><br>
<cap:enabled>false</cap:enabled><br>
</cap:update><br>
<cap:delete><br>
<cap:enabled>false</cap:enabled><br>
</cap:delete><br>
</configured><br>
</capabilities><br>
<synchronization><br>
. . .<br>
<br>
But it all depends on how much authoritative the resource is and if
you really do not want to update data there.<br>
<br>
Regards,<br>
Ivan<div><div class="h5"><br>
<br>
<div>On 12/04/2014 01:46 AM, Jason Everling
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Nevermind! I got it going by using a reconciliation
task which linked all existing accounts!
<div><br>
</div>
<div>JASON</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 3, 2014 at 5:33 PM, Jason
Everling <span dir="ltr"><<a href="mailto:jeverling@bshp.edu" target="_blank">jeverling@bshp.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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
<div><br>
</div>
<div>For example:</div>
<div><br>
</div>
<div>John Doe is already in DBTable Resource</div>
<div>John Doe is already in Midpoint</div>
<div><br>
</div>
<div>Correlation will match employeeNumber.</div>
<div><br>
</div>
<div>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.</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 3, 2014 at 3:15
PM, Jason Everling <span dir="ltr"><<a href="mailto:jeverling@bshp.edu" target="_blank">jeverling@bshp.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">*wanted to double-check, not
wouldn't, was a typo</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 3, 2014
at 3:14 PM, Jason Everling <span dir="ltr"><<a href="mailto:jeverling@bshp.edu" target="_blank">jeverling@bshp.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I wouldn't to
double-check this,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I attached the resource, please
when you have time take a look at
it.</div>
<span><font color="#888888">
<div><br>
</div>
<div>JASON</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
</div></div><font><br>
<br>
CONFIDENTIALITY NOTICE:<br>
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. </font><br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
midPoint mailing list
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Ing. Ivan Noris
Senior Identity Management Engineer
<a href="http://evolveum.com" target="_blank">evolveum.com</a> <a href="http://evolveum.com/blog/" target="_blank">evolveum.com/blog/</a>
_____________________________________________
"Semper Id(e)M Vix."
</pre>
</font></span></div>
<br>_______________________________________________<br>
midPoint mailing list<br>
<a href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
<br></blockquote></div><br></div>
<br>
<font size="2"><br><br>CONFIDENTIALITY NOTICE:<br>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. </font><br>