[ejabberd] New node?!

Konstantin Khomoutov flatworm at users.sourceforge.net
Fri Dec 11 19:20:42 MSK 2009


On Fri, 11 Dec 2009 13:11:29 -0200
Márcio Luciano Donada <mdonada at auroraalimentos.com.br> wrote:

>> It seems like you're confusing Erlang nodes (parts of ejabberd cluster)
>> with XMPP hosts (or domains) ejabberd serves.
>> Can you reformulate your question?
> sorry for the confusion, come on. Currently I have two domain to access,
> both are reading the same base User (LDAP), but in the second domain, I
> just set up some users may have access to authenticate to this domain.

Well, off the top of my head, I see several possible ways to implement this:

1) (The simplest one.) Create a same-named special group in each LDAP
   domain, of which users granted access to your XMPP server should be
   members of. Then, in the first domain, all users should be the members
   of this group, and in the second -- only those which are granted access
   to XMPP.
   To enforce checking of group membership, your ldap_filter specification
   should include checking of some appropriate attribute(s);
   for Microsoft AD this should be "memberOf" and the resulting
   ldap_filter string should be something like this:
   {ldap_filter, "(memberOf=CN=XMPP Users,DC=yourdomain,DC=local)"}.

   A modification to this solution could be creating just one special
   group for XMPP users -- for the users of the second domain only,
   and complicating the LDAP filter by providing an alteration
   (using the "|" compound operator) which would match either any user
   from the first domain or members of that specific group.

2) Specify LDAP authentication setting separately for each domain
   you serve. This could be done using the host_config clauses
   in the configuration file. In each clause you could specify
   ldap_filter setting matching the needs of its domain so that
   for the first domain it would match all users and for the second
   only users in a specific group (see (1)).
   See the "3.1.2 Virtual Hosting" section in the Installation and
   Operation Guide for more info.

3) Manage controlling access of users to the server in the server's
   config:
   a) Create a special access rule for the c2s listener, say, using
      {access, c2s, [{allow, c2s_dom1}, {allow, c2s_dom2}, {deny, all}]}.
   b) Create ACLs used in that access rule, like this:
      {acl, c2s_dom1, {server, "domain1.local"}}.
      {acl, c2s_dom2, {user, "bob", "domain2.local"}}.
      {acl, c2s_dom2, {user, "alice", "domain2.local"}}.
   c) Assign the access rule created at step (1) to the c2s listener.
   This way, all users in the "domain1.local" domain will be allowed
   to work with the server, as well as users "bob" and "alice" from
   the "domain2.local" domain.
   See the sections "3.1.5 Access Rules" and "3.1.3 Listening Ports"
   in the Guide.


More information about the ejabberd mailing list