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:andreapatrice...@apache.org]
Gesendet: Montag, 24. Juli 2017 11:33
An: user@syncope.apache.org
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:andrea.patrice...@tirasa.net]
Gesendet: Freitag, 21. Juli 2017 15:35
An: user@syncope.apache.org<mailto:user@syncope.apache.org>
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:andrea.patrice...@tirasa.net]
Gesendet: Freitag, 21. Juli 2017 12:29
An: user@syncope.apache.org<mailto:user@syncope.apache.org>
Betreff