[midPoint] Import users from AD
Ivan Noris
ivan.noris at evolveum.com
Fri May 18 16:36:07 CEST 2018
I have also updated our wiki:
https://wiki.evolveum.com/pages/viewpage.action?pageId=22741393
I think it is also somewhere else (and definitely in samples), but it's
good to have it also on Active Directory Connector page.
Best regards,
Ivan
On 18.05.2018 16:17, Peter Viskup wrote:
> 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
>>
> _______________________________________________
> 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