Le 2/20/13 11:26 AM, Francesco Chicchiriccò a écrit :
> On 19/02/2013 14:13, Emmanuel Lécharny wrote:
>> Don't use uniqueMemeber. Never. Nine. Niet. Nix.
>>
>> http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387
>>
>> This is far from what you expect it to be, and you'll get hard time
>> with
Patch submitted for review here:
https://issues.apache.org/jira/browse/SYNCOPE-320
Colm.
On Mon, Feb 18, 2013 at 5:14 PM, Francesco Chicchiriccò wrote:
> On 18/02/2013 16:08, Colm O hEigeartaigh wrote:
>
>> [...]
>>
>>
>> LDAPMembershipPropagationActio**ns has "ldapGroups" as the group member
On 19/02/2013 14:13, Emmanuel Lécharny wrote:
Don't use uniqueMemeber. Never. Nine. Niet. Nix.
http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387
This is far from what you expect it to be, and you'll get hard time with some
Windows identifier having a # in their DN.
Hi Emmanuel,
what'
Le 2/18/13 4:08 PM, Colm O hEigeartaigh a écrit :
>
>>> attribute name, whereas LDAPMembershipSyncActions has "uniquemember". Is
>>> there a reason why it is different in both cases? Shouldn't they also
>>> check
>>> the value of the "groupMemberAttribute" property of the LDAP Connector?
>>
> Could
On 18/02/2013 16:08, Colm O hEigeartaigh wrote:
[...]
LDAPMembershipPropagationActions has "ldapGroups" as the group member attribute name,
whereas LDAPMembershipSyncActions has "uniquemember". Is
there a reason why it is different in both cases? Shouldn't they also
check
the value of the "gro
Hi Francesco,
This derives from UserTO.username and RoleTO.name, as per bean property
> resolution: to turn the latter into rolename we should change the property
> name and getter / setter on RoleTO.
Ok thanks. I'm fine with leaving it as it is - I just wanted to know why
the difference betwee
On 15/02/2013 16:48, Colm O hEigeartaigh wrote:
Hi all (Francesco),
I've been experimenting with propagating/synchronizing roles from an LDAP
backend on trunk...here are some questions:
1) When specifying the "Account Id", where does the "name" come from? For
example, for user mapping it's "use
>
> 4) Role membership is working fine for propagation (create a new role +
> propagate it, create a new user with that role + propagate it, and the new
> role in the backend has the correct "member" entry). However,
> synchronization doesn't work. If I then synchronize by running the task
> again
Hi all (Francesco),
I've been experimenting with propagating/synchronizing roles from an LDAP
backend on trunk...here are some questions:
1) When specifying the "Account Id", where does the "name" come from? For
example, for user mapping it's "username", for the role mapping it's
"name", which is
