[midPoint] Import users from AD
Peter Viskup
skupko.sk at gmail.com
Wed May 23 13:16:55 CEST 2018
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
More information about the midPoint
mailing list