[midPoint] Construct Password for SASL Pass Through
Jason Everling
jeverling at bshp.edu
Tue May 9 16:37:07 CEST 2017
You can either have 2 resources or just 1 resource but using different
'intents' for each type of user if you have a way to differentiate between
the two in the correlation and in the object sync sections, Ivan actually
posted a sample a while back using OUs when I set it up for our different
user types.
http://lists.evolveum.com/pipermail/midpoint/2017-February/003316.html
JASON
On Mon, May 8, 2017 at 3:20 PM, Brad Firestone <bhotrock at gmail.com> wrote:
> Thank you Ivan and Jason!
>
> 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.
>
> Ivan, Your suggestion is a bit over my head. :-) But I'll dig into if I
> need to.
>
> I think I've found a solution, but want to make sure I'm not going to
> cause some sort of problem:
>
> I noticed in the resource configuration that there is a field for the
> Password Hash Algorithm.
> <icfcldap:passwordHashAlgorithm>none</icfcldap:passwordHashAlgorithm>
>
> I have set that to "none" and it works. I can set the password in
> midPoint to: {SASL}user at example.com and it stores it in LDAP correctly
> and works for Pass Through.
>
> 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.
>
> Do you see any problem with having two resources that point to the same
> server?
> Brad
>
>
>
> Jason Everling wrote:
>
> 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.
>
> One tool I have used in the past previously before google released their
> own password filter and still works to this day is passwdhk,
> http://passwdhk.sourceforge.net/ , 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.
>
> JASON
>
> On Fri, May 5, 2017 at 4:20 PM, Ivan Noris <Ivan.Noris at evolveum.com>
> wrote:
>
>> Brad,
>>
>> I once tried similar thing, which was not yet deployed into production
>> with that customer. So you may try it, it might actually work.
>>
>> 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).
>>
>> <credentials>
>> <password>
>> <outbound>
>> <expression>
>> <script>
>> <code>
>> import com.evolveum.midpoint.prism.crypto.Protector
>> import java.security.MessageDigest
>> import com.evolveum.prism.xml.ns._public.types_3.ProtectedStringType
>> import javax.xml.bind.DatatypeConverter
>>
>> Protector protector = midpoint. at protector
>>
>> MessageDigest md = MessageDigest.getInstance("MD5") // XXX SHA-2
>>
>> log.info('midpoint protector = {}', midpoint. at protector)
>> if (input) {
>> clr = protector?.decryptString(input)
>> log.info("XXXXXXXXXXXXXXX input = {}, clr = {}", input, clr)
>>
>> md.update(clr.getBytes("UTF-8"));
>> byte[] digest = md.digest()
>>
>> base64 = '{MD5}' + DatatypeConverter.printBase64Binary(digest)
>> log.info("XXXXXXXX base64 = {}", base64)
>>
>>
>> newPassword = base64
>> return protector?.encryptString(newPassword)
>> }
>> </code>
>> </script>
>> </expression>
>> </outbound>
>> <!-- FIXME this is Default Password Policy -->
>> <passwordPolicyRef oid="00000000-0000-0000-0000-0
>> 00000000003"/>
>> </password>
>> </credentials>
>>
>> Of course my mapping would influence all accounts.
>>
>> 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.
>>
>> Maybe someone from developers will have anything to add. Or someone from
>> the list who actually has such things up and running.
>>
>> Best regards,
>> Ivan
>>
>> ------------------------------
>>
>> *From: *"Brad Firestone" <bhotrock at gmail.com>
>> *To: *"midPoint General Discussion" <midpoint at lists.evolveum.com>
>> *Sent: *Friday, May 5, 2017 9:44:38 PM
>> *Subject: *[midPoint] Construct Password for SASL Pass Through
>>
>>
>> Hi All,
>>
>> 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:
>> {SASL}user at example.com
>> Here's some information about SASL Pass Through:
>> https://ltb-project.org/documentation/general/sasl_delegation
>>
>> I have this configured and working, if I enter the password directly into
>> OpenLDAP. But I need to have midPoint enter this value automatically.
>>
>> 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:
>>
>> 1. Tried to generate it using an outbound expression in <credentials>
>> for the OpenLDAP resource.
>> <credentials>
>> <password>
>> <outbound>
>> <source>
>> <path>$user/name</path>
>> </source>
>> <expression>
>> <script>
>> <code>'{SASL}' + name</code>
>> </script>
>> </expression>
>> </outbound>
>> </password>
>> </credentials>
>>
>> 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.
>>
>> 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:
>> Attribute {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}userPassword
>> not found in schema for account type default, resource: Account Testing
>> OpenLDAP (OID:d0811790-1d80-11e4-86b2-3c970e467874) as definied in role:
>> HQ-User (OID:880f1186-2f77-11e7-93c2-bfabd497cae2).
>> userPassword is the attribute used in the OpenLDAP resource, but I'm
>> guessing it's not treated like other attributes.
>>
>> 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.
>>
>> Thanks for any suggestions!
>> Brad
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> Ivan Noris
>> Senior Identity Engineer
>> evolveum.com
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170509/d691ca43/attachment.htm>
More information about the midPoint
mailing list