On 28 June 2016 12:08:24 CEST, Jonas Israelsson 
<jonas.israels...@elementary.se> wrote:
>
>
>On 24/06/16 14:05, Francesco Chicchiriccò wrote:
>> On 24/06/2016 14:00, Francesco Chicchiriccò wrote:
>>> On 24/06/2016 13:58, Jonas Israelsson wrote:
>>>>
>>>> Running 2.0.0-M3 and have hooked up a connector to my openldap
>server.
>>>>>>
>>>>>> First sync, no problem all users are placed in the local storage.
>
>>>>>> Second sync however, even though the sync is marked as successful
>
>>>>>> I see from the logs syncope are trying to reinsert all entrys to 
>>>>>> the local storage and fail due to key violation. I have set the 
>>>>>> matching rule to update, and use the uid as remote key, mapped to
>
>>>>>> the local username field.
>>>>>>
>>>>>> Can I create this behaviour by misconfiguration, or do we have a 
>>>>>> bug here ?
>>>>>
>>>>> It is quite common to fall into such issues when configuring an 
>>>>> LDAP resource; please take this (quite old, but still applying) 
>>>>> post of mine as reference:
>>>>>
>>>>> http://blog.tirasa.net/unlock-full-ldap-features-in.html
>>>>>
>>>>> Please let me know if that improves the situation.
>>>> That blog post explains how to setup an ldap-connector, under the 
>>>> impression I'm beyond that point. If I miss the obvious may I
>please 
>>>> ask you to elaborate ?
>>>> I have no problem (via the connector) getting the data from my 
>>>> directory service. My problem is I fail to convince syncope not to 
>>>> add already synced users a new ones.
>>>
>>> The post explains how to correctly setup the connector AND the 
>>> resource mapping so that you can avoid the problem you have above 
>>> (plus some additional things, BTW).
>>
>> In particular, I would check the value provided for 'Uid Attribute'
>in 
>> the connector configuration - which is safe to set to 'cn' when 
>> managing both users and groups.
>> Please check all other parameters as well.
>While I have got this somewhat working, it does not work as I'd like it
>
>to. The problem (with key violation) occurs when leaving 'Uid
>Attribute' 
>to it's default value entryUUID. Not sure I have fully understood the 
>meaning of the 'Uid Attribute' but if it's meant to create a local 
>unique identifier mapped to the remote entry, the entryUUID would in my
>
>humble opinion be the best candidate. By the way, if 'Uid Attribute' is
>
>meant to be used for this correlation, of what usage is then the remote
>
>key on the field mapping ?
>
>When not using entryUUID I'm not quite sure how syncope should be 
>configured to be compatible with a directory service  layout using 
>different rdn such as uid for users and cn for groups. I though I could
>
>work around this by creating two resources with different 'uid 
>attribute'. However with this approach I found no way on how to
>populate 
>the groups with members.
>
>So to sum things up.
>
>1) Is the entryUUID as 'Uid Attribute' by design not supposed to work
>in 
>syncope ?
>2) If so, is there a way to join data from different resources (user 
>from one with groups from another) 

I believe a bit if theory about how ConnId works and how Syncope relies on it 
may help, and it would also be useful to me to write it down, as part of the 
ongoing effort to produce the reference guide.

I should be able to reply properly in the coming days, please stay tuned.

Regards.

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC,
CXF Committer, OpenJPA Committer
http://home.apache.org/~ilgrosso/

Reply via email to