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,
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 some
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 you explain the
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 between
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
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 a bit
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 (with
