[midPoint] when does outbound credentials happen?

Jason Everling jeverling at bshp.edu
Mon Jul 6 18:09:17 CEST 2015


Thanks for sample, I think for this next recon I will just comment it out
again and then I will add in the channel config. I don't imagine I would be
doing a lot of reconciliation after these next few since Live Sync will be
doing the rest, I just had a lot of cleaning up to do after the initial
import.

I should have just tested the below before which I ran 3 tests a few
minutes ago, I did a recon in my test environment and the passwords are not
updated, the only time I could see the password being updated during a
recon is when a change in the password has occurred.
        <credentials>
                <password>
                        <outbound>
                                <expression>
                                    <asIs/>
                                </expression>
                     </outbound>
                </password>
        </credentials>

Thanks,
JASON


On Mon, Jul 6, 2015 at 1:31 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:

>  Hi Jason,
>
> as Pavol has pointed out, the behaviour of the password is a bit tricky,
> as midPoint does not have the original value and would send the repository
> value to AD, which is probably not what you wish to do while reconciling,
> if AD passwords are set and reset in AD, not through midPoint.
>
> The channel trick should work for you, if you can say in which channel(s)
> you wish to use the mapping (or the opposite: the channel(s), in which you
> don't wich to use the mapping). In my experience, the list of channels can
> be different during the initial setup and after. E.g. if you leave only
> LiveSync channel through the password outbound mapping, it should be OK for
> almost all situations. But if some AD accounts get accidentaly deleted and
> you would like midPoint to recreate, I doubt the password will be set
> correctly, because reconciliation or GUI use different channels as LiveSync.
>
> So, either use the <channel> restriction, or comment the whole mapping
> during the reconciliation (which is what I do, as a paranoid setting, which
> is fine for me, but off course nobody is able to send the password to AD
> when I'm playing :) ).
>
> The channel limitation for LiveSync and maybe for GUI (to allow password
> change when requested from GUI) is probably a good start, but just like
> Pavol I recommend you to try this out.
>
> An *example* from one of my projects (this is not AD, but it does not
> matter) to allow password changes during initial import, during LiveSync
> and from GUI:
>
>         <credentials>
>                 <password>
>                         <outbound>
>                                 <description>Do not change passwords
> unless using GUI or import (initial) or LiveSync from OpenLDAP through
> midPoint</description>
>                                 <channel>
> http://midpoint.evolveum.com/xml/ns/public/provisioning/channels-3#import
> </channel>
>                                 <channel>
> http://midpoint.evolveum.com/xml/ns/public/model/channels-3#user</channel>
>                                 <channel>
> http://midpoint.evolveum.com/xml/ns/public/provisioning/channels-3#liveSync
> </channel>
>                                 <expression>
>                                     <asIs/>
>                                 </expression>
>                      </outbound>
>                 </password>
>         </credentials>
>
> Regards,
> Ivan
>
>
> On 07/04/2015 03:39 PM, Pavol Mederly wrote:
>
> Hello Jason,
>
> mapping strength influences how the mapping is applied, either during
> normal operation or during reconciliation.
> I'm sure you have already seen this:
> https://wiki.evolveum.com/display/midPoint/Mapping#Mapping-MappingStrength
>
> In your case, I assume the outbound mapping for password is specified with
> strength of "normal" (the default) or "weak".
> According to the documentation, both are used if the target attribute does
> not have any value.
>
> So far so good. But in AD the password always has no value, because the AD
> clients are not allowed to retrieve it (for obvious reasons).
> So I'm almost sure that the AD password would get overwritten by the one
> stored in the repository.
>
> This is what the theory says. Maybe Ivan (or anyone with practical
> experiences in this respect) would correct me.
>
> Back to your case; it is possible to enable/disable a mapping for example
> depending on a channel that caused the mapping to fire.
> See the <channel> element directly under <mapping>. In your case, you
> could try to include a limitation to LiveSync channel, with
> an assumption that changes from your CSV file would come through LiveSync.
> But please try in the test environment before
> using this advice :)
>
> Best regards and nice weekend!
> Pavol
>
>
> On 3. 7. 2015 21:06, Jason Everling wrote:
>
> I just wanted to confirm, before I un-comment outbound credentials for my
> AD resource,
>
>  The only time a password is sent outbound is when the password in
> midPoint is changed correct?
>
>  I need to run a reconcile against AD after making a few changes but I
> wanted to make sure that this will not send out passwords for all users? I
> am correct in assuming not?
>
>  Users in midPoint will authenticate via CAS, the outbound password
> mapping is for when a user is created from CSV and a password is generated.
>
>  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
>
>
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
>   Ing. Ivan Noris
>   Senior Identity Management Engineer & IDM Architect
>   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
>
>


-- 
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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150706/af4c8c89/attachment.htm>


More information about the midPoint mailing list