*Von:*Francesco Chicchiriccò [mailto:ilgro...@apache.org]
*Gesendet:* Dienstag, 1. August 2017 15:45
*An:* user@syncope.apache.org
*Betreff:* Re: Configuration of LDAP Identity Store
On 28/07/2017 09:15, Böhmer, Martin wrote:
Hi Francesco,
What you propose sounds good to me from my external view not being
able to follow all the technical details.
Looking forward to the implemented solution.
FYI: https://issues.apache.org/jira/browse/SYNCOPE-1182
The implementation is now available with latest 2.0.5-SNAPSHOT (which
should be available within hours).
Regards.
*Von:*Francesco Chicchiriccò [mailto:ilgro...@apache.org]
*Gesendet:* Donnerstag, 27. Juli 2017 12:34
*An:* user@syncope.apache.org <mailto:user@syncope.apache.org>
*Betreff:* Re: Configuration of LDAP Identity Store
Hi Martin and Andrea,
sorry if I come late to the party.
First of all, I confirm that Andrea's approach is the correct one,
at this moment: the way how LDAPMembershipsPropagationActions is
architected requires that the same Resource is used for both Users
and Groups, and the configuration available in the test data for
ApacheDS works as long as uid and cn contain exactly the same value.
Hence, the suggestion to try out the LDAP connector 1.5.2-SNAPSHOT
(which can be downloaded from [0]) is the most logical, currently.
The issue originally described below is somehow related to some
thoughts I am elaborating about the usage that Syncope makes of
ConnId APIs, and I believe there is room for improvement.
I plan to write down a full proposal, but here's the raw idea.
For several operations, but in particular *before* and *after*
executing a Propagation Task, Syncope queries the External
Resource to see if a matching item is found, and it does that via
ConnId's GetApiOp [1].
Such operation is implemented at Framework level, e.g. before
reaching out any effective Connector, via a plain search [2] where
the key is the special __UID__ attribute and the value is the one
passed as argument, alongside with ObjectClass.
Using GetApiOp used to make entirely sense in the old days of
ConnId 1.3 and Syncope 1.1, when the Mapping Item identified as
"AccountId" (now Remote Key) was forced to blank the external
attribute name (see [3]): in such cases, in fact, __UID__ was used
as external attribute.
ConnId 1.4 slightly changed the way how the __UID__ attribute is
managed: as a result, since Syncope 1.2, it is mandatory to
specify an external attribute name for the Remote Key (see [4] in
Syncope 2.0).
To give an idea, the sample from [3] would result in querying the
External Resource for "__UID__ == 'ilgrosso'", while the sample
from [4] *should* result in "uid == 'ilgrosso'" but will instead
produce the same query as in the past.
The problem here is that what actually __UID__ means is left to
any Connector's implementation: LDAP configures that via the
UidAttribute property (and GidAttribute in 1.5.2-SNAPSHOT), AD
does something similar, others do differently.
What I see here is that from one side the Remote Key is defined in
Syncope at high level (e.g. as part of the Resource configuration,
in the Mapping), while the raw __UID__ is still used under the
hoods in some cases (before executing a Propagation Task, as said
above, for example), hence it is the low level configuration (not
Resource's but Connector's) that comes into play.
My proposal is to simply get rid of GetApiOp and replace its usage
in Syncope with search, using as key the External attribute name
defined in the mapping, rather than __UID__.
This should solve your issue (and others) at a glance, as Users
will be looked up by uid, Groups by cn and Realms by ou (if your
Mappings were set in these ways).
Not sure if this clarifies, but I will make some work around such
concepts hopefully soon.
Regards.
[0]
https://oss.sonatype.org/content/repositories/snapshots/net/tirasa/connid/bundles/net.tirasa.connid.bundles.ldap/1.5.2-SNAPSHOT/net.tirasa.connid.bundles.ldap-1.5.2-20170607.094522-5.jar
[1]
https://github.com/Tirasa/ConnId/blob/master/java/connector-framework/src/main/java/org/identityconnectors/framework/api/operations/GetApiOp.java
[2]
https://github.com/Tirasa/ConnId/blob/master/java/connector-framework-internal/src/main/java/org/identityconnectors/framework/impl/api/local/operations/GetImpl.java
[3] https://pasteboard.co/GCRf497.png
[4] https://pasteboard.co/GCRixXp.png
On 25/07/2017 14:12, Böhmer, Martin wrote:
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]
*Ge**sendet:*Montag, 24. Juli 2017 11:33
*An:* user@syncope.apache.org <mailto: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:* 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
ouid=johndoe
o…
·ou=groups
ocn=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’/
