[ejabberd] Hosts, LDAP, multiple domains

Konstantin Khomoutov flatworm at users.sourceforge.net
Wed Aug 18 14:04:57 MSD 2010


On Wed, Aug 18, 2010 at 11:25:13AM +0300, Take wrote:

> I've been trying to figure out an problem (or merely an missing feature)
> with our environment. Our users are in LDAP and authentication works
> just fine.
> 
> We're using iredmail for user management and our users are on ldap like
> this:
> mail=john.doe at example.com,ou=Users,domainName=example.com,dc=ourhost,dc=foo
> 
> Now, if I put example.com on {hosts, ["localhost"]}. -line John Doe can
> login an use jabber just fine. But if I forget to add the domain in
> configuration John can't access ejabberd.
> 
> So the actual question is: Is there any way I could read allowed domains
> directly from LDAP? I'd be quite happy even if I could assign an
> wildcard to hosts -line.
XMPP domains served by an ejabberd instance (that's what the "hosts"
option actually defines) do not have to correlate one-to-one with LDAP
domains or whatever. Basically, you use the ldap_uids option to define
how (parts of) XMPP logins are mapped to LDAP attributes.
For instance, we use Windows AD as our LDAP backend, and I have these
lines in the config file:

{host_config, "007spb.ru", [
        {auth_method, ldap},
        {ldap_servers, ["domain.local"]},
        {ldap_encrypt, none},
        {ldap_port, 3268},
        {ldap_base, "dc=domain,dc=local"},
        {ldap_rootdn, "saslauthd at domain.local"},
        {ldap_password, "secret"},
        {ldap_uids, [{"userPrincipalName", "%u at domain.local"}]},
        {ldap_filter, "(objectCategory=Person)"}
]}.

Here, "007spb.ru" is the XMPP domain (where users have JIDs like
foo at 007spb.ru), and "domain.local" is the Windows domain, in which these
same users have logins like domain\foo (and their Kerberos principal
names are like foo at domain.local). You're, of course, should not blindly
copy this as your LDAP schema is most probably different, and you should
possibly use the "mail" attribute instead (which we do not have).

As you can guess, the %u placeholder in ldap_uids is replaced with the
user part of the JID when ejabberd searches for the user in LDAP, so, in
my case, when a user tries to authenticate as foo at 007spb.ru, ejabberd
binds to LDAP and searches for the user who has the attribute
"userPrincipalName" having value "foo at domain.local".

The details on the ldap_uids option are in the ejabberd guide.



More information about the ejabberd mailing list