Configuration of LDAP Identity Store

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Configuration of LDAP Identity Store

Böhmer, Martin

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’

               

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration of LDAP Identity Store

andrea patricelli

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Configuration of LDAP Identity Store

Böhmer, Martin

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:[hidden email]]
Gesendet: Freitag, 21. Juli 2017 12:29
An: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Configuration of LDAP Identity Store

andrea patricelli
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 [[hidden email]]
Gesendet: Freitag, 21. Juli 2017 12:29
An: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: AW: Configuration of LDAP Identity Store

Böhmer, Martin

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…

 

So, any ideas on how to get the sync work with the different DNs?

 

Regards,

 

Martin

 

Von: Andrea Patricelli [mailto:[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: AW: Configuration of LDAP Identity Store

Andrea Patricelli-2

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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: AW: AW: Configuration of LDAP Identity Store

Böhmer, Martin

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:[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: AW: AW: Configuration of LDAP Identity Store

andrea patricelli

Hi Martin,


Il 25/07/2017 14:12, Böhmer, Martin ha scritto:

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?

No. Sorry I wasn't aware of it. I've opened [1] for you ;)

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.

I'm quite sure that the propagation action will not work. I experienced the same issue little time ago. You should "adapt" it to work out of the box, in order to do this you can try without any modification and see what is its behavior in order to modify it.

 

Regards,

 

Martin

Best regards,
Andrea

[1] https://connid.atlassian.net/browse/LDAP-25

 

Von: Andrea Patricelli [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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

-- 
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: AW: AW: Configuration of LDAP Identity Store

Andrea Patricelli-2

Hi Martin,

This email only top notify to you that the improvement that you need has already been developed and will be available with LDAP Connector 1.5.2 release. The issue is [1].
I came to know that there was already an issue today, sorry for the inconvenience ;)

Best regards,
Andrea

[1] https://connid.atlassian.net/browse/LDAP-23

Il 25/07/2017 14:41, Andrea Patricelli ha scritto:

Hi Martin,


Il 25/07/2017 14:12, Böhmer, Martin ha scritto:

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?

No. Sorry I wasn't aware of it. I've opened [1] for you ;)

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.

I'm quite sure that the propagation action will not work. I experienced the same issue little time ago. You should "adapt" it to work out of the box, in order to do this you can try without any modification and see what is its behavior in order to modify it.

 

Regards,

 

Martin

Best regards,
Andrea

[1] https://connid.atlassian.net/browse/LDAP-25

 

Von: Andrea Patricelli [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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

-- 
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration of LDAP Identity Store

ilgrosso
Administrator
In reply to this post by Böhmer, Martin
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 [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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’

-- 
Francesco Chicchiriccò

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

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Configuration of LDAP Identity Store

Böhmer, Martin

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.

 

Regards,

 

Martin

 

Von: Francesco Chicchiriccò [mailto:[hidden email]]
Gesendet: Donnerstag, 27. Juli 2017 12:34
An: [hidden email]
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 [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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’

-- 
Francesco Chicchiriccò
 
Tirasa - Open Source Excellence
http://www.tirasa.net/
 
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration of LDAP Identity Store

ilgrosso
Administrator
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ò [[hidden email]]
Gesendet: Donnerstag, 27. Juli 2017 12:34
An: [hidden email]
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 [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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’

-- 
Francesco Chicchiriccò
 
Tirasa - Open Source Excellence
http://www.tirasa.net/
 
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


-- 
Francesco Chicchiriccò

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

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Configuration of LDAP Identity Store

Böhmer, Martin

Hi Francesco,

 

Thanks for the update. I’m excited to try out 2.0.5-SNAPSHOT.

 

Just to make sure I understood your approach correctly: You said earlier, using the 1.5.2-SNAPSHOT version of the ConnID LDAP Bundle might be a workaround too (see below). But as far as I understood your solution to SYNCOPE-1182, it is going work with the ConnID LDAP Bundle 1.5.1 release currently referenced by the pom.xml in the 2_0_X branch!? So no need to worry about the ConnID version, I am right?

 

Reagrds,

 

Martin

 

Von: Francesco Chicchiriccò [mailto:[hidden email]]
Gesendet: Dienstag, 1. August 2017 15:45
An: [hidden email]
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ò [[hidden email]]
Gesendet: Donnerstag, 27. Juli 2017 12:34
An: [hidden email]
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 [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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’

-- 
Francesco Chicchiriccò
 
Tirasa - Open Source Excellence
http://www.tirasa.net/
 
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

 

-- 
Francesco Chicchiriccò
 
Tirasa - Open Source Excellence
http://www.tirasa.net/
 
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration of LDAP Identity Store

ilgrosso
Administrator
On 01/08/2017 18:27, Böhmer, Martin wrote:

Hi Francesco,

 

Thanks for the update. I’m excited to try out 2.0.5-SNAPSHOT.


You can start right away, actually: could you please remember me which distribution are you using? Standalone, deb, Maven project...

Just to make sure I understood your approach correctly: You said earlier, using the 1.5.2-SNAPSHOT version of the ConnID LDAP Bundle might be a workaround too (see below). But as far as I understood your solution to SYNCOPE-1182, it is going work with the ConnID LDAP Bundle 1.5.1 release currently referenced by the pom.xml in the 2_0_X branch!? So no need to worry about the ConnID version, I am right?


Correct.

Regards.

Von: Francesco Chicchiriccò [[hidden email]]
Gesendet: Dienstag, 1. August 2017 15:45
An: [hidden email]
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ò [[hidden email]]
Gesendet: Donnerstag, 27. Juli 2017 12:34
An: [hidden email]
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 [[hidden email]]
Ge
sendet: Montag, 24. Juli 2017 11:33
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 15:35
An: [hidden email]
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 [[hidden email]]
Gesendet: Freitag, 21.
Juli 2017 12:29
An:
[hidden email]
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’

-- 
Francesco Chicchiriccò

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

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Loading...