[midPoint] Existing Active Directory Users
Jason Everling
jeverling at bshp.edu
Sat Oct 18 03:09:43 CEST 2014
Wow! Thank you for this, I had no idea so much was involved just to pull
the name. I am glad I asked because after much searching I couldn't
understand where to start, I think I am reading too much all over too fast.
I have just now started playing with the scripts more and more and I am
noticing how powerful it could be making it easier to fill in redundant
mandatory fields in AD from using MidPoint. Even using the regular
expressions not just for the distinguishedName but I worked some other
expressions into other fields/attributes.
Yes, the attribute eduPersonEntitlement is a multi-valued string. We use
this attribute for many other applications including Microsoft ADFS and for
Shibboleth SSO so I was wanting to see if later on we could get the roles
assigned in Midpoint into AD so that we could use the information in other
applications or at least standardize the names across applications and it
looks to be possible.
Thanks Again!
JASON
On Fri, Oct 17, 2014 at 4:31 PM, Pavol Mederly <mederly at evolveum.com> wrote:
> Hello Jason,
>
> yes, there is a way to do it. Conceptually, you need to create a mapping
>
> assignment -> target attribute
>
> However, there are three facts to bear in mind:
>
> (1) there can be many roles the user has been assigned -> so either you
> choose one of them (how?) or the target attribute has to be multi-valued;
> let's assume the latter
> (2) assignments can be not only roles, but also accounts and orgs -> so
> there should be some filter based on the kind of assignment
> (3) in the assignment there is only a OID of target roles, and you want to
> have its name -> so there has to be a getObject(...) operation in the
> process to get the name
>
> Conceptually, the solution could look like this:
> (This is a direct mapping from the user roles to a "l" attribute in LDAP
> resource - tailor this to your needs. E.g. if you have to map to a user
> property, you have to put this mapping into a user template.)
>
> <attribute>
> <ref xmlns:ri=
> "http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3>
> >ri:l</ref>
> <outbound>
> <source>
> <path>assignment</path>
> </source>
> <expression>
> <script>
> <code>
>
> import com.evolveum.midpoint.xml.ns._public.common.common_3.RoleType
> if (assignment != null) {
> target = assignment.getTargetRef()
> if (target != null &&
> "RoleType".equals(target.getType().getLocalPart())) { //
> filtering, mentioned in (2)
> role = midpoint.getObject(RoleType.class, target.getOid(), null)
> // getting the object, mentioned in (3)
> return role.getName()
> }
> }
> return null
>
> </code>
> </script>
> </expression>
> </outbound>
> </attribute>
>
> Unfortunately, life's not that easy ... because of a limitation in
> midPoint (MID-2064 <https://jira.evolveum.com/browse/MID-2064>) we cannot
> process individual container values, only the container as a whole - so we
> have to rewrite the mapping to process not item after item, but to process
> all assignments as a whole. It's called absolute mode of evaluation.
>
> The solution is then as follows:
>
> <attribute>
> <ref xmlns:ri=
> "http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3>
> >ri:l</ref>
> <outbound>
> <source>
> <name>assignmentContainer</name> <!--
> just to provide meaningful name to the source -->
> <path>assignment</path>
> </source>
> <expression>
> <script>
> <relativityMode>absolute</relativityMode>
> <code>
> import
> com.evolveum.midpoint.xml.ns._public.common.common_3.RoleType
> rv = new ArrayList()
> if (assignmentContainer != null) {
> for (assignment in
> assignmentContainer.getValues()) {
> target =
> assignment.asContainerable().getTargetRef()
> if (target != null &&
> "RoleType".equals(target.getType().getLocalPart())) {
> role =
> midpoint.getObject(RoleType.class, target.getOid(), null)
> rv.add(role.getName().getOrig())
> }
> }
> }
> return rv
> </code>
> </script>
> </expression>
> </outbound>
> </attribute>
>
> Of course, there should be some error handling around getObject method,
> because the role that the user has might have been already deleted - so a
> simple try {...} catch {...} should be there.
>
> But I hope you get an overall idea from this sample.
>
> Best regards,
> Pavol
>
>
>
> On 17. 10. 2014 21:43, Jason Everling wrote:
>
> Ok thanks again, I still have a lot of testing with incoming and outgoing
> attributes, trying to get them just right before I move onto Roles/Orgs and
> such..
>
> Quick question,
>
> Is there a way to get the assigned role name, like the default role "end
> user" into a user attribute field? For instance, the user is assigned the
> role "end user" and I wanted to get the role name "end user" into the
> attribute eduPersonEntitlement in AD. as long as I can get that name "end
> user" into a field on the user details page I can move it into AD.
>
>
> JASON
>
> On Fri, Oct 17, 2014 at 5:28 AM, Ivan Noris <Ivan.Noris at evolveum.com>
> wrote:
>
>> Hi Jason,
>>
>> I'm not sure if I understand, but if you are asking if you can create
>> (import) organization structure in midPoint according to your existing AD
>> structure, the answer is yes.
>>
>> If you are asking if you can provision your existing midPoint
>> organization structure to AD, the answer is double-yes. You can actually
>> see this in our generic-sync scenarios. For more simple cases where
>> organization structure is maintained in midPoint (and not in some kind of
>> authoritative source such as CSV) this is very simple and I'm using this
>> just now in current projects.
>>
>> It's all just configuration in midPoint (resource, roles, object
>> templates). The inbound (from AD to midPoint) organization synchronization
>> is a little more difficult than the outbound (midPoint to AD), but
>> certainly doable.
>>
>> Regards,
>> Ivan
>>
>> ------------------------------
>>
>> *From: *"Jason Everling" <jeverling at bshp.edu>
>> *To: *"midPoint General Discussion" <midpoint at lists.evolveum.com>
>> *Sent: *Thursday, October 16, 2014 10:07:34 PM
>> *Subject: *Re: [midPoint] Existing Active Directory Users
>>
>> That is great! I was testing this and it seems to be working. I was
>> thinking about this more also and down the road once I move into Orgs and
>> such.
>>
>> I am almost certain, correct me if I am wrong, but I could also base
>> the DN by pulling information from the Orgs in Midpoint. I would pretty
>> much be building out the Orgs in the same manner that our AD orgs are setup.
>>
>> JASON
>>
>> On Thu, Oct 16, 2014 at 10:27 AM, Ivan Noris <Ivan.Noris at evolveum.com>
>> wrote:
>>
>>> Hi Jason,
>>>
>>>
>>> AD only needs to be authoritative during the initial deployment since
>>> we have thousands of accounts in AD, after that, all accounts will be
>>> modified/added using midpoint.
>>>
>>> I think using the method I outlined last to build the DN is more or
>>> less what I am moving towards. I have looked through AD attributes and the
>>> attribute, "ou" in AD is not used and would make sense to populate that
>>> attribute with the actual OU. I can simply use a powershell script to add
>>> the correct value to this attribute based on the users current ou and then
>>> build the DN in midpoint off this value.
>>>
>>> Using the "ou" attribute in AD might also be the best way since later
>>> on I can use the attribute in roles and orgs, I have been looking to the
>>> orgsync story test on github for inspiration.
>>>
>>>
>>> You can use PS script in AD to fill "ou" attribute in accounts and
>>> then import it to midPoint, but you can construct the value directly during
>>> initial import in inbound expression with no changes in AD. Roughly -
>>> something like this:
>>>
>>> <attribute>
>>> <ref>icfs:name</ref>
>>> <displayName>Distinguished Name</displayName>
>>> <inbound>
>>> <expression>
>>> <script>
>>> <code>
>>> // parse OU value from variable named
>>> *input* (represents DN) using groovy regular expressions
>>> // e.g. from OU=The
>>> Student,DC=TEST,DC=LOCAL take "The Student" value
>>> // please fix the regular expression
>>> according to your setup, this is just a rough example
>>>
>>> re =
>>> /(?i)^.*OU=(.*),DC=TEST,DC=LOCAL$/
>>> matcher = (input =~ re)
>>> if (matcher.matches()) return
>>> matcher[0][1]
>>>
>>> // will be stored in
>>> *user/organization* attribute, modify as needed
>>> </code>
>>> </script>
>>> </expression>
>>> <target>
>>> <path>$user/organization</path>
>>> </target>
>>> </inbound>
>>> </attribute>
>>>
>>> This is also to show you the power of the expressions in the mappings.
>>>
>>> Regards,
>>> Ivan
>>>
>>> --
>>> Ing. Ivan Noris
>>> Senior Identity Management Engineer
>>> evolveum.com
>>> ___________________________________________
>>> "Idem per idem - semper idem Vix."
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>>
>>
>> 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 list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer
>> evolveum.com
>> ___________________________________________
>> "Idem per idem - semper idem Vix."
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>
>
>
> 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 list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
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/20141017/21051bf3/attachment.htm>
More information about the midPoint
mailing list