[midPoint] Import users from AD

Peter Viskup skupko.sk at gmail.com
Fri May 18 16:17:27 CEST 2018


Thank you, Ivan.
Only line
<icfc:enableFilteredResultsHandler>false</icfc:enableFilteredResultsHandler>
was in resultsHandlerConfiguration, adding the two others solved the
issue. Now the resource objects have all values visible in browsing.

Peter

On Fri, May 18, 2018 at 4:02 PM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> Hi,
>
> think of objectSynchronization condition as a filter - objects not matched
> by condition will not be synchronized (and not marked by intent specified in
> the objectSynchronization). The primary purpose is when having multiple
> account intents, you need to distinguish between them using such conditions.
>
> From the MidPoint Deployment Fundamentals training:
>
>         <synchronization>
>                 <objectSynchronization>
>                     <name>Default account</name>
>                     <description>Normal accounts are NOT in
> ou=_Administrators container</description>
>                     <kind>account</kind>
>                     <intent>default</intent>
>                     <enabled>true</enabled>
>                     <condition>
>                         <script>
>                             <code>
> tmpSuffix = '(?i).*,ou=_Administrators_,ou=ExAmPLE,dc=example,dc=com$'
> re = ~tmpSuffix
> !(basic.getAttributeValue(shadow, "dn") ==~ re)
>                             </code>
>                         </script>
>                     </condition>
>                     <correlation>
> ...
>
> The correlation will not be done for not matching objects.
>
> As the example above is using regexp, it can be used to match "ou=users".
>
> I don't have AD now handy, but from the samples, ri:sAMAccountName is
> correct name of the attribute. Maybe you have some other problem. Can you
> e.g. check if you have this:
>
> ...
>        <icfc:resultsHandlerConfiguration>
>
> <icfc:enableNormalizingResultsHandler>false</icfc:enableNormalizingResultsHandler>
>
> <icfc:enableFilteredResultsHandler>false</icfc:enableFilteredResultsHandler>
>
> <icfc:enableAttributesToGetSearchResultsHandler>false</icfc:enableAttributesToGetSearchResultsHandler>
>                 </icfc:resultsHandlerConfiguration>
>     </connectorConfiguration>
> ...
>
> I remember some "invisible" attributes when the
> enableAttributesToGetSearchResultsHandler was true. For our LDAP connector,
> keep those to false.
>
> Best regards,
> Ivan
>
>
>
> On 18.05.2018 15:39, Peter Viskup wrote:
>
> Yes, only users should be imported from "OU=Users" containers, which
> are located in the search base "OU=COMPANY,DC=company,DC=corp" more
> times and in different depth.
>
> e.g.:
> CN=Name
> Surname,OU=Employees,OU=Users,OU=Bratislava,OU=SK,OU=COMPANY,DC=company,DC=corp
> CN=Name
> Surname,OU=Administration,OU=Users,OU=Singapore,OU=SG,OU=COMPANY,DC=company,DC=corp
> CN=Name Surname,OU=Account Management,OU=Sales,OU=Users,OU=Buenos
> Aires,OU=AR,OU=COMPANY,DC=company,DC=corp
>
> In the same search base there are other objects which are not users
> (resources, groups, computers, ...). Thought this as "efficient"
> pre-filtering of user objects only.
> Is the condition in objectSynchronization better way of doing this?
> Maybe misunderstood something.
>
> With $shadow/attributes/dn the value is taken as expected. The input
> is still null.
> Is the <c:ref>ri:sAMAccountName</c:ref> correct?
> When browsing resource objects, the sAMAccountName is not visible for
> account objects (even with "show empty fields") and the only filled
> attributes are objectGUID and dn.
>
> Object synchronization is configured as follows:
>       <objectSynchronization>
>          <name>CORP User sync</name>
>          <objectClass>ri:user</objectClass>
>          <kind>account</kind>
>          <intent>corp</intent>
>          <focusType>c:UserType</focusType>
>          <enabled>true</enabled>
>          <reconcile>false</reconcile>
>          <correlation>
>              <q:equal>
>                  <q:path>c:name</q:path>
>                  <expression>
>                      <path>$shadow/attributes/sAMAccountName</path>
>                  </expression>
>              </q:equal>
>          </correlation>
>          <reaction>
>             <situation>unlinked</situation>
>             <action>
>
> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</handlerUri>
>             </action>
>          </reaction>
>          <reaction>
>             <situation>unmatched</situation>
>             <reconcile>false</reconcile>
>             <action>
>
> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#addFocus</handlerUri>
>             </action>
>          </reaction>
>       </objectSynchronization>
>
> Peter
>
> On Fri, May 18, 2018 at 11:55 AM, Ivan Noris <ivan.noris at evolveum.com>
> wrote:
>
> Hi,
>
> what do you want to achieve? Import only accounts from ou=users? That
> can be done using condition in <objectSynchronization>...
>
> Ivan
>
>
> On 17.05.2018 15:17, Peter Viskup wrote:
>
> Trying to import users from AD tree to Midpoint without success
> (inbound mapping).
> Not able to define inbound mapping condition with check of the value
> of DN attribute.
>
> This is schema handling for users:
>
>       <objectType>
>          <kind>account</kind>
>          <intent>corp</intent>
>          <displayName>User CORP</displayName>
>          <default>true</default>
>          <objectClass>ri:user</objectClass>
>          <attribute>
>             <c:ref>ri:sAMAccountName</c:ref>
>             <displayName>Account name</displayName>
>             <tolerant>true</tolerant>
>             <exclusiveStrong>false</exclusiveStrong>
>             <inbound>
>                <authoritative>false</authoritative>
>                <exclusive>true</exclusive>
>                <strength>normal</strength>
>                <source>
>                   <name>dn</name>
>                   <c:path>$shadow/attributes/distinguishedName</c:path>
>                </source>
>                <target>
>                   <c:path>$user/name</c:path>
>                </target>
>                <condition>
>                   <script
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>                           xsi:type="c:ScriptExpressionEvaluatorType">
>                      <code>
>         log.info("Attribute dn value: {}", dn.dump());
>         log.info("Attribute input value: {}", input.dump());
>         if (!basic.isEmpty(dn)){
>           return dn.contains('OU=Users');
>         }
>         return false;
>                      </code>
>                   </script>
>                </condition>
>             </inbound>
>          </attribute>
>
> Getting error (seems both dn and input variables are not defined):
>
> Cannot invoke method hashCode() on null object in condition in mapping
> in inbound expression for
> {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}sAMAccountName
> in resource:2a59c3d6-9d65-4284-980a-3bb8404126b3(Active Directory
> CORP)({.../common/common-3}input=null; dn=null; ) in condition in
> mapping in inbound expression for
> {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}sAMAccountName
> in resource:2a59c3d6-9d65-4284-980a-3bb8404126b3(Active Directory
> CORP)
>
> What source and target paths needs to used in this case?
>
> Peter
> _______________________________________________
> 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 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
>



More information about the midPoint mailing list