Hi Andrea, Your proposed solutions are greatly appreciated. Here are my comments:
1. I created a JIRA account to file an improvement request. Unfortunately, I seem to lack the right to create an improvement for the "LDAP bundle" component. The only components I can create issues for are COMMONS, REST & OFFICE365. Am I doing something wrong? 2. I not sure, if I understood you correctly. Are you saying, there is no chance LDAPMembershipPropagationAction will work out of the box? Or that you aren't you sure if it will work and it would be worth setting this up and try it out? If it's the second case, I would try it you. Regards, Martin Von: Andrea Patricelli [mailto:[email protected]] Gesendet: Montag, 24. Juli 2017 11:33 An: [email protected] Betreff: Re: AW: AW: Configuration of LDAP Identity Store Hi Martin, I perfectly understand your situation. Please see my responses inline. Il 22/07/2017 00:53, Böhmer, Martin ha scritto: Yes, I have set a group mapping. It's kinda simple: Type User Object Class __GROUP__ Mapping name Int: name ext: cn Remote key: yes Object Link 'cn=' + name + ',ou=groups,dc=example,dc=com' I had a look at the working example you provided. Using "cn" as the uidAttribute and in the DN for both users and groups worked fine in my test installation. But, this is only going to work in case I can influence the way the DNs are structured, so I am able to harmonise user and group DNs. True for my test environment, but it is not going to work with our production LDAP. On the production LDAP server, user DNs are structured "uid=..." and group DNs "cn=...". As a result, the "cn" attribute for users is not a unique identifier, as two different persons can have the same "cn" in our environment (they will get different uids and email addresses, etc). There is no way I can change/harmonise the structure of the DNs (for various reasons). Setting the uidAttriute to "cn" proved not work with our production LDAP server - even though the Object Links of the mappings reflect the differences of the DNs (see above and below). I do not understand why the uidAttribute of the connector config influences the remote key generation as the remote key could be generated only by just evaluating the different ObjectLink JEXL expressions... You are right, uidAttribute is only used to retrieve the entity from the LDAP server, i.e. the connector will search entities by uidAttribute (cn, uid, etc.). For this reason you see the user correctly propagated to LDAP, but not correctly linked on Syncope. So, any ideas on how to get the sync work with the different DNs? I see two solutions: 1. Implement an improvement on ConnID LDAP connector in order to manage two (or more) different uidAttributes (at least one for USER and another for GROUP), as done for Active Directory connector. You could open an issue (improvement) at [1]. 2. Define two different resources, one for USER and the other for GROUP, and set uidAttribute as Override while configuring the connector. With this solution you'll be able to define for each resource your specific uidAttribute. Solution 2 unfortunately has a drawback: LDAPMembershipPropagationAction could not work anymore and probably needs to be reviewed in order to work with entities related to two different resources. HTH, Andrea [1] https://connid.atlassian.net/projects/BASE/issues/BASE-56?filter=allopenissues Regards, Martin Von: Andrea Patricelli [mailto:[email protected]] Gesendet: Freitag, 21. Juli 2017 15:35 An: [email protected]<mailto:[email protected]> Betreff: Re: AW: Configuration of LDAP Identity Store Have you set a mapping for GROUP? Could you share it? Pay attention to the object link for groups. It should be something like this: 'cn=' + name + ',ou=groups,dc=sample,dc=com' If it is correct (as I thisnk) try to use as uidAttribute an attribute that both USER and GROUP have, and is mapped to any of Syncope attributes. cn for example. You have a working example at [1] (Apache DS, resource-ldap). Best regards, Andrea [1] http://syncope-vm.apache.org:9080/syncope-console Il 21/07/2017 13:15, Böhmer, Martin ha scritto: Hi Andrea, Thank you for the quick reply! I changed the uidAttribute as you suggested and sync works for users. However, now I have the very same problem with groups whose remote IDs happen to be empty. So, when I change the uidAttribute to "uid", will the same connector also work for groups? Or do I need to create a second connector for synchronizing groups? I am asking, because groups have the attribute "cn" in their dn instead of "uid" (see below). Regards, Martin Von: Andrea Patricelli [mailto:[email protected]] Gesendet: Freitag, 21. Juli 2017 12:29 An: [email protected]<mailto:[email protected]> Betreff: Re: Configuration of LDAP Identity Store Hi Martin, try to change, in connector configuration, the uidAttribute value to uid instead of "entryUUID". BTW if this does not work could you attach core-connid.log file? HTH, Andrea Il 21/07/2017 12:00, Böhmer, Martin ha scritto: HI, I cannot get the configuration of my LDAP Identity Store right. What I want is a synchronization of user, groups and group memberships, meaning that everything change in Syncope is propagated to LDAP and vice-versa. With my current configuration below, I am able to pull users from LDAP (pull task) and propagate new users to LDAP when created in Syncope. What is not working is the synchronization of users existing in both systems. Syncope claims about a missing remote key. This is particularly strange when creating a user in Syncope. On the result screen of the user creation, the remote key is correctly display. When I close that screen and open the "Manage resources" dialog for that user, the remote key is gone and thus propagation of updates to LDAP fails. Any hints would be greatly appreciated! Regards, Martin I'm using OpenLDAP. The tree looks like this dc=example,dc=com · ou=people o uid=johndoe o ... · ou=groups o cn=testgroup Here is the configuration of the LDAP connector (properties not listed were not touched = default value) Bundle net.tirasa.connid.bundles.ldap Host localhost TCP Port 389 Principal cn=syncope,dc=exmaple,dc=com Password ****** Base Contexts dc=exmaple,dc=com Password Attribute userPassword Account Object Classes top, person, organizationalPerson, inetOrgPerson Account User Name Attributes uid, cn Group Object Classes top, groupOfuniqueNames Group Name Attributes cn Group Member Attribute uniqueMember Maintain LDAP Group Membership [(Haken)] Password Hash Algorithm SSHA VLV Sort Attribute uid Uid Attribute entryUUID Read Schema [(Haken)] Base Contexts to Synchronize (leer) Object Classes to Synchronize inetOrgPerson, groupOfUniqueNames Attributes to Synchronize (leer) Remove Log Entry Object Class from Filter [(Haken)] Enable Password Synchronization [(Fehler)] Status management class net.tirasa.connid.bundles.ldap.commons.AttributeStatusManagement Capabilities (all selected) And this is the configuration of my LDAP resource: Propagation Actions LDAPPAsswordPropagationAction LDAPMembershipPropagationAction Override Capabilities? [(Fehler)] Account Policy (none) Password Policy (none) Pull Policy (none)) Finally, the mapping configuration Type User Object Class __ACCOUNT__ Mapping username Int: username ext: uid Remote key: yes Mapping email Int: email Ext: mail Mapping password Int: password Ext: userPassword Password: yes Object Link 'uid=' + username + ',ou=people,dc=example,dc=com' -- Dott. Andrea Patricelli Tel. +39 3204524292 Developer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member -- Dott. Andrea Patricelli Tel. +39 3204524292 Developer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member -- Dott. Andrea Patricelli Tel. +39 3204524292 Developer @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member
