<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">Thank you Ivan and Jason!<br>
<br>
Jason, Thanks for the suggestion of PasswordHK.  I remember seeing that 
years ago, but hadn't thought about it.  I don't have direct Admin 
access to the AD servers, and have to work through other people.  So 
I've been hoping to handle it all without having to make changes to the 
AD servers.  That way there's no risk of "My" software causing 
problems.  :-)  But it's a great idea to have as an option.<br>
<br>
Ivan,  Your suggestion is a bit over my head.  :-)  But I'll dig into if
 I need to.<br>
<br>
I think I've found a solution, but want to make sure I'm not going to 
cause some sort of problem:<br>
<br>
I noticed in the resource configuration that there is a field for the 
Password Hash Algorithm. <br>
<icfcldap:passwordHashAlgorithm>none</icfcldap:passwordHashAlgorithm><br>
<br>
 I have set that to "none" and it works.  I can set the password in 
midPoint to:  {<a class="moz-txt-link-abbreviated" href="mailto:SASL}user@example.com">SASL}user@example.com</a> and it stores it in LDAP correctly 
and works for Pass Through.<br>
<br>
But I only want that type of password for users that come from AD.  So 
my idea is to setup two different resources that point to the same 
OpenLDAP server.  One will be used without hashing for the users coming 
from AD, and the other will use SSHA hashing for "regular" users.  The 
base DN will be set to different OUs the two different resources, so I 
think I'll keep these accounts isolated. <br>
<br>
Do you see any problem with having two resources that point to the same 
server?<br>
Brad<br>
<br>
<br>
<span>Jason Everling wrote:</span><br>
<blockquote 
cite="mid:CAFkZXY49dJi2xGZRHCx8YQx1RSyrdatuOTTnof7ouqRNjAThSQ@mail.gmail.com"
 type="cite">
  <div dir="ltr">You can use a password filter on your domain 
controllers to capture the changed password and use a script to just 
update OpenLDAP, although this would take however long your password 
policies last to fully sync over unless you force everyone to change 
their password.<div><br></div><div>One tool I have used in the past 
previously before google released their own password filter and still 
works to this day is passwdhk, <a moz-do-not-send="true" 
href="http://passwdhk.sourceforge.net/">http://passwdhk.sourceforge.net/</a>
 , it is pretty simple to create the script, the password filter sends 
over two variables, %1 for their username and %2 for the new password. 
So your script would just be a command line ldap operation for the user 
and update password.</div></div>
  <div class="gmail_extra"><br clear="all"><div><div 
class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">JASON</div></div></div>
<br><div class="gmail_quote">On Fri, May 5, 2017 at 4:20 PM, Ivan Noris <span
 dir="ltr"><<a moz-do-not-send="true" 
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><div 
style="font-family:times new roman,new 
york,times,serif;font-size:12pt;color:#000000"><div>Brad,<br></div><div><br></div><div>I
 once tried similar thing, which was not yet deployed into production 
with that customer. So you may try it, it might actually work.<br></div><div><br></div><div>In
 my case I wanted to take/decrypt midPoint password and hash it with 
(MD5 in my example, use something stronger :-) ) function and 
base64-encode. It looked like it works, but it was onyl deployed with my
 prototype (CSV or DB table; not real resource).<br></div><div><br></div><div>  
              <credentials><br>                   
 <password><br>                        <outbound><br>       
                     <expression><br>                           
 <script><br>                                <code><br>import
 com.evolveum.midpoint.prism.<wbr>crypto.Protector<br>import 
java.security.MessageDigest<br>import com.evolveum.prism.xml.ns._<wbr>public.types_3.<wbr>ProtectedStringType<br>import
 javax.xml.bind.<wbr>DatatypeConverter<br><br>Protector protector = 
midpoint.@protector<br><br>MessageDigest md = 
MessageDigest.getInstance("<wbr>MD5") // XXX SHA-2<br><br><a 
moz-do-not-send="true" href="http://log.info" target="_blank">log.info</a>('midpoint
 protector = {}', midpoint.@protector)<br>if (input) {<br>  clr = 
protector?.decryptString(<wbr>input)<br>  <a moz-do-not-send="true" 
href="http://log.info" target="_blank">log.info</a>("XXXXXXXXXXXXXXX 
input = {}, clr = {}", input, clr)<br><br>md.update(clr.getBytes("UTF-8"<wbr>));<br>byte[]
 digest = md.digest()<br><br>base64 = '{MD5}' + DatatypeConverter.<wbr>printBase64Binary(digest)<br><a
 moz-do-not-send="true" href="http://log.info" target="_blank">log.info</a>("XXXXXXXX
 base64 = {}", base64)<br><br><br>  newPassword = base64<br>  return 
protector?.encryptString(<wbr>newPassword)<br>}<br>                   
             </code><br>                           
 </script><br>                            </expression><br>  
                      </outbound><br>                       
 <!-- FIXME this is Default Password Policy --><br>               
         <passwordPolicyRef oid="00000000-0000-0000-0000-<wbr>000000000003"/><br>  
                  </password><br>               
 </credentials><br><br></div><div>Of course my mapping would 
influence all accounts.<br></div><div><br></div><div>Regarding other 
sources for password (like your $user/name), I think it was not 
implemented as the other (attribute) mappings, at least not in older 
versions of midPoint. In 3.6 it might be different.<br></div><div><br></div><div>Maybe
 someone from developers will have anything to add. Or someone from the 
list who actually has such things up and running.<br></div><div><br></div><div>Best
 regards,<br></div><div>Ivan<br></div><div><br></div><hr 
id="m_-5745535036917082979zwchr"><blockquote style="border-left:2px 
solid 
#1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
 </b>"Brad Firestone" <<a moz-do-not-send="true" 
href="mailto:bhotrock@gmail.com" target="_blank">bhotrock@gmail.com</a>><br><b>To:
 </b>"midPoint General Discussion" <<a moz-do-not-send="true" 
href="mailto:midpoint@lists.evolveum.com" target="_blank">midpoint@lists.evolveum.com</a>><br><b>Sent:
 </b>Friday, May 5, 2017 9:44:38 PM<br><b>Subject: </b>[midPoint] 
Construct Password for SASL Pass Through<div><div class="h5"><br><div><br></div>Hi
 All,<br> <br> I have one certain group of users that will be 
provisioned on an OpenLDAP resource.  This group of users needs to use 
SASL Pass Through to Active Directory, so the password stored in 
OpenLDAP userPassword attribute will be in the format of:  <br> {<a 
moz-do-not-send="true" 
class="m_-5745535036917082979moz-txt-link-abbreviated" 
href="mailto:SASL%7Duser@example.com" target="_blank">SASL}user@example.com</a><br>
 Here's some information about SASL Pass Through:  <a 
moz-do-not-send="true" 
class="m_-5745535036917082979moz-txt-link-freetext" 
href="https://ltb-project.org/documentation/general/sasl_delegation" 
target="_blank">https://ltb-project.org/<wbr>documentation/general/sasl_<wbr>delegation</a><br>
 <br> I have this configured and working, if I enter the password 
directly into OpenLDAP.  But I need to have midPoint enter this value 
automatically.<br> <br> I can easily construct this value using Groovy, 
but because it's a "password", I can't seem to work with it in midPoint 
like other attributes.  Here are the things I've tried:<br> <br> 1.  
Tried to generate it using an outbound expression in <credentials>
 for the OpenLDAP resource.  <br> <credentials><br>             
<password><br>                <outbound><br> 
                   <source><br>                         
<path>$user/name</path><br>                     
</source><br>                   <expression><br> 
                     <script><br>                         
<code>'{SASL}' + name</code><br>                      
</script><br>                   </expression><br> 
               </outbound><br>             </password><br> 
         </credentials><br> <br> This doesn't throw any errors, 
but I don't know if it's really generating the right value, because when
 it stores the password on the resource, it hashes it, like normal.  And
 the pass through function doesn't work.<br> <br> 2.  I tried to bypass 
the password hashing function by generating the needed value in the User
 Template, and storing it in midPoint $user/costCenter.  I then tried to
 use outbound mapping in a Role to map $user/costCenter to 
ri:userPassword.  That gave an error of:  <br> <span>Attribute {<a 
moz-do-not-send="true" 
class="m_-5745535036917082979moz-txt-link-freetext" 
href="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3" 
target="_blank">http://midpoint.evolveum.com/<wbr>xml/ns/public/resource/<wbr>instance-3</a>}userPassword
 not found in schema for account type default, resource: Account Testing
 OpenLDAP (OID:d0811790-1d80-11e4-86b2-<wbr>3c970e467874) as definied in
 role: HQ-User (OID:880f1186-2f77-11e7-93c2-<wbr>bfabd497cae2)</span>.<br>
 userPassword is the attribute used in the OpenLDAP resource, but I'm 
guessing it's not treated like other attributes.<br> <br> Is there 
anyway to pass a "plain text" value to a resource userPassword 
attribute?  If so, then I will need to do this for only ONE set of 
users.  The rest of the user accounts on that resource need to be 
handled in a normal way.<br> <br> Thanks for any suggestions!<br> Brad<br><br></div></div>______________________________<wbr>_________________<br>midPoint
 mailing list<br><a moz-do-not-send="true" 
href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br><a
 moz-do-not-send="true" 
href="http://lists.evolveum.com/mailman/listinfo/midpoint" 
target="_blank">http://lists.evolveum.com/<wbr>mailman/listinfo/midpoint</a><span
 class="HOEnZb"><font color="#888888"><br></font></span></blockquote><span
 class="HOEnZb"><font color="#888888"><div><br><br></div><div><br></div><div>--
 <br></div><div><span name="x"></span>Ivan Noris<br>Senior Identity 
Engineer<br><a moz-do-not-send="true" href="http://evolveum.com" 
target="_blank">evolveum.com</a><span name="x"></span><br></div></font></span></div></div><br>______________________________<wbr>_________________<br>
midPoint mailing list<br>
<a moz-do-not-send="true" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><br>
<a moz-do-not-send="true" 
href="http://lists.evolveum.com/mailman/listinfo/midpoint" 
rel="noreferrer" target="_blank">http://lists.evolveum.com/<wbr>mailman/listinfo/midpoint</a><br>
<br></blockquote></div><br></div>


  <pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
</body></html>