[midPoint] Read-Only LDAP-Ressouce? Only pull data from LDAP resource?
Oliver Schonefeld
schonefeld at ids-mannheim.de
Fri Sep 11 21:17:55 CEST 2020
Hi All,
I've found a solution to my problem. Here for the archives:
I only had an <objectClass> for the object type.
However the LDAP object have more auxilary classes.
On solution is to define the appropiate auxiliary object classes using
<auxiliaryObjectClass>
Since the data in the LDAP server is quite messy and object classes are
used inconsistenly I told midpint to handle them read only using:
<auxiliaryObjectClassMappings>
<tolerant>true</tolerant>
</auxiliaryObjectClassMappings>
in the object type definition.
More information can be found at
https://wiki.evolveum.com/display/midPoint/Auxiliary+Object+Classes
Best regards
Oliver
Am 11.09.2020 um 20:05 schrieb Oliver Schonefeld via midPoint:
> Hi Ethan,
>
> Am 11.09.2020 um 15:56 schrieb Ethan Kromhout via midPoint:
>> I think I remember something like this from a similar configuration I
>> was working on recently. The attributes appear to be posix related, in
>> schema you import from OpenLDAP, are you getting posixGroup and
>> posixAccount attributes?
>
> It's a custom schema based on inetOrgPerson with mixed in posix related
> attributes and other attributes. As well das custom defined attributes.
>
> But I just want to pull some data from the LDAP server and don't care
> about most of the attributes.
>
> I'd like to tell midpoint, to just read some stuff but don't care
> otherwise about the data in the directory.
>
> Best
> Oliver
>
>
>
>> On 9/11/20 8:10 AM, Oliver Schonefeld via midPoint wrote:
>>> Hello,
>>>
>>> I'm new to midpoint and am still learning, so please bear with me.
>>>
>>> For my evaluation of midpoint, I started to setup a fresh copy of
>>> Midpoint 4.1 with Postgres.
>>>
>>> I've manged to connect to our HR system by using an CSV resource and
>>> data is imported and synchronized as expected.
>>>
>>> Now, for migration purposes, I'd like to import some information from a
>>> legacy (Open)LDAP server. I'm only interested to enrich my accounts in
>>> midpoint with a few attributes from LDAP (e.g. mail and uid). However I
>>> don't want midpoint to push any changes to the legacy LDAP server;
>>> midpoint should only read the attributes I'm interested in and update
>>> the accounts in midpoint.
>>>
>>> I've setup a LDAP resource and I am able to connect to the LDAP server.
>>> The Account, I use to connect to the LDAP server, has no write
>>> permissions, so I went ahead and overrode the capabilities of the
>>> resource using:
>>> <capabilities>
>>> <configured>
>>> <cap:create>
>>> <cap:enabled>false</cap:enabled>
>>> </cap:create>
>>> <cap:update>
>>> <cap:enabled>false</cap:enabled>
>>> </cap:update>
>>> <cap:delete>
>>> <cap:enabled>false</cap:enabled>
>>> </cap:delete>
>>> </configured>
>>> </capabilities>
>>>
>>>
>>> Now, when I try to import data from the LDAP server to midpoint, I get
>>> the following error:
>>> Operation not supported for
>>> shadow:e7a471e5-531e-479b-8257-14112ab83b20($REDACTED$) in
>>> resource:873f6012-bac3-4b2c-9d2d-bb886b9c2213(Legacy IDS-LDAP) as
>>> UpdateCapabilityType is missing
>>>
>>>
>>> When I remove the capability override, midpoint throws the following
>>> exception:
>>> org.identityconnectors.framework.common.exceptions.PermissionDeniedException(Error
>>>
>>> modifying LDAP entry $REDACTED$:
>>> [remove:idsWiki=TRUE,remove:idsMailRoutingAddress=$REDACTED$@mailbox.ids-mannheim.de,remove:idsPosix=TRUE,remove:idsMail=TRUE,remove:idsDisplayPub=TRUE,remove:idsVpn=TRUE,remove:objectClass=idsServices,remove:vacationStart=binary
>>>
>>> value 10
>>> bytes,remove:gidNumber=50,remove:idsDisplayWeb=TRUE,remove:vacationEnd=binary
>>>
>>> value 10
>>> bytes,remove:loginShell=/sbin/nologin,remove:vacationInfo=binary value
>>> 533
>>> bytes,remove:homeDirectory=$REDACTED$,remove:vacationActive=FALSE,remove:uidNumber=$REDACTED$,remove:idsAD=TRUE,]:
>>>
>>> insufficientAccessRights: (50))
>>>
>>> My synchronization reactions are configured as follows:
>>> <reaction>
>>> <situation>linked</situation>
>>> <synchronize>true</synchronize>
>>> </reaction>
>>> <reaction>
>>> <situation>unlinked</situation>
>>> <action>
>>>
>>> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</handlerUri>
>>>
>>> </action>
>>> </reaction>
>>> <!--
>>> <reaction>
>>> <situation>unmatched</situation>
>>> <action>
>>>
>>> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#addFocus</handlerUri>
>>>
>>> </action>
>>> </reaction>
>>> -->
>>> <reaction>
>>> <situation>deleted</situation>
>>> <action>
>>>
>>> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#deleteShadow</handlerUri>
>>>
>>> </action>
>>> </reaction>
>>>
>>> I have only inbound mapping definitions for the attributes I am
>>> interested in. There are no outbound definitions.
>>>
>>> So midpoint tries to synchronize the information and remove some
>>> attributes on the objects in the LDAP server. However, I only want to
>>> pull some information from the LDAP server and never write to it.
>>>
>>> What am I missing or doing wrong?
>>>
>>>
>>> Thank you and best regards,
>>> Oliver
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> https://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> https://lists.evolveum.com/mailman/listinfo/midpoint
>>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
>
--
Oliver Schonefeld
Leibniz-Institut für Deutsche Sprache, Informationstechnik (IT)
R5, 6-13, D-68161 Mannheim
+49-(0)621-1581-168 | http://www.ids-mannheim.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5381 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20200911/13f6e156/attachment.bin>
More information about the midPoint
mailing list