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
*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’/
--
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
