[midPoint] Construct Password for SASL Pass Through
Brad Firestone
bhotrock at gmail.com
Mon May 8 22:20:55 CEST 2017
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
> <mailto: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 <http://log.info>('midpoint protector = {}',
> midpoint. at protector)
> if (input) {
> clr = protector?.decryptString(input)
> log.info <http://log.info>("XXXXXXXXXXXXXXX input = {}, clr = {}",
> input, clr)
>
> md.update(clr.getBytes("UTF-8"));
> byte[] digest = md.digest()
>
> base64 = '{MD5}' + DatatypeConverter.printBase64Binary(digest)
> log.info <http://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-000000000003"/>
> </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
> <mailto:bhotrock at gmail.com>>
> *To: *"midPoint General Discussion"
> <midpoint at lists.evolveum.com <mailto: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 <mailto:SASL%7Duser at example.com>
> Here's some information about SASL Pass Through:
> https://ltb-project.org/documentation/general/sasl_delegation
> <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 <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 <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>
>
>
>
> --
> Ivan Noris
> Senior Identity Engineer
> evolveum.com <http://evolveum.com>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <http://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/20170508/e79e75db/attachment.htm>
More information about the midPoint
mailing list