[midPoint] Import users from AD

Ivan Noris ivan.noris at evolveum.com
Wed May 23 13:28:27 CEST 2018


I tend to believe the condition should return the opposite.

The condition is true -> object will be corelated and possibly synchronized.

The condition is false -> object is not processed by this correlation.

Your "CN=00:1f:29:35:fc:f4,OU=VL40,OU=Network
Clients,OU=Bratislava,OU=SK,OU=COMP,DC=comp,DC=corp" is not matching
"...OU=Users,...".

Your condition returns "if DN does NOT match". I believe you want the
opposite.

Regards,

Ivan


On 23.05.2018 13:16, Peter Viskup wrote:
> New users created in Midpoint.
> Following executed actions were logged:
>
> User     Add     Import     196     User 00:1f:29:35:fc:f4 (00_1f_29_35_fc_f4)
> Shadow     Modify     Import     196     Shadow
> CN=00:1f:29:35:fc:f4,OU=VL40,OU=Network
> Clients,OU=Bratislava,OU=SK,OU=COMP,DC=comp,DC=corp (ACCOUNT - corp -
> user)
>
> Goal is to import AD users into Midpoint.
>
> Peter
>
> On Wed, May 23, 2018 at 12:10 PM, Ivan Noris <ivan.noris at evolveum.com> wrote:
>> Hi Peter,
>>
>> what do you mean by "are imported"?
>>
>> Accounts are matched and linked to existing users, or even new users are
>> created?
>>
>> Or you just see the accounts in Resource - Accounts page? (That's
>> expected, shadows will be created by midPoint, but they should not be
>> further processed because of the condition.)
>>
>> Best regards,
>>
>> Ivan
>>
>>
>> On 23.05.2018 11:00, Peter Viskup wrote:
>>> With following objectSynchronization definition also objects with dn
>>> attribute not matching filterstr are imported.
>>> Is there missing anything? Or the unmatched situation configuration is
>>> not correct?
>>>
>>>       <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>
>>>          <condition>
>>>            <script>
>>>          <code>
>>>              filterstr = '(?i).*,OU=Users,OU=[\\S
>>> ]+,OU=[A-Z]{2},OU=COMP,DC=comp,DC=corp'
>>>          matchre = ~filterstr
>>>              !(basic.getAttributeValue(shadow, "dn") ==~ matchre)
>>>          </code>
>>>        </script>
>>>      </condition>
>>>          <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>
>>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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




More information about the midPoint mailing list