[ejabberd] shared roster ldap and search permissions error
andre at rodier.me
Sun May 13 19:31:52 MSK 2018
On 13/05/18 16:55, Dominik George wrote:
>> Here my roster configuration:
> First of all, it looks syntactically incorrect, and I wonder why your
> ejabberd even starts… every setting should be on a separate line.
It is the case.
> Also, please do imemdiately change your LDAP password, in case you didn't
> replace it with another random string in your mail…
Thanks for the advice, its random generated on each deployment on a VM.
> You do not need the LDAP server configuration there, it uses the global
> configuration (which I understand you have in a working state).
> Now to several options you seem to have misunderstood:
>>> ldap_base: "ou=users, dc=homebox,dc=space"
> Leave this out (to use the global base) or set it to the base of the *groups*, not the users.
OK, I suppose the groups is queried first, then the users that are
members of the groups in another query? I am using posixGroup schema,
> Again, this filter should find the *groups*.
OK, I will test this.
>>> ldap_groupattr: "ou" ldap_memberattr: "cn"
> I doubt that. If you are using posixGroup or groupOfNames, groupattr is cn
> in both cases, and memberattr is either memberUid or member.
>>> ldap_memberattr_format: "cn=%u,ou=users, dc=homebox,dc=space"
I tried a few things, perhaps I mistake something. My current goal is on
this page: https://ejabberd-msrl.alioth.debian.org/doc/0.5.3/msrl.html#htoc3
> So, taking that into account, the memberattr seems to be member for you.
Now, I am not sure to understand.
>>> ldap_filter: "(objectClass=inetOrgPerson)"
> I am not sure what you intend here.
> Here's my config, tailored to your information:
> ldap_rfilter: "(&(objectClass=posixGroup)(member=cn=%u,ou=users,dc=homebox,dc=space))"
> This finds all groups a user is a member of.
> ldap_gfilter: "(&(objectClass=posixGroup)(cn=%g))"
> This finds a group by its name.
> ldap_ufilter: "(&(objectClass=posixAccount)(cn=%u,ou=users,dc=homebox,dc=space))"
> This finds a specific user by their name.
> ldap_filter: "(cn=*)"
> This finds all groups.
> ldap_groupattr: "cn"
> This defines the attribute the group name is stored in.
> ldap_userdesc: "displayName"
> This is the field the human-readable name of the user is stored in.
> ldap_useruid: "cn"
> This is the field that holds the username.
> But, I doubt that this is correct, and I think that there is a
> misunderstanding about your LDAP structure on a very basic level. At least,
> the fields you intend to use are very uncommon. The username is normally
> stored in the uid field, while cn normally holds the friendly name…
Perhaps my configuration is wrong, but Yes, I am using the uid for the
username, and the cn for the friendly name.
> You might want to read up on your LDAP schema again and then double-check
> your assumptions.
> ejabberd mailing list
> ejabberd at jabber.ru
More information about the ejabberd