Hello,
I'm have several hosts on my ejabberd 2.0.3 server:
{hosts, ["host1.lan", "host2.lan"]}.
host2.lan uses LDAP authentification on AD, so I want allow connection for host2.lan only with ssl, bacause I don't need passwords in plain text on my LAN and NTLM does not supported yet.
host1.lan uses internal ejabbed authentication.
Ejabberd listens for c2s connections on 5222 and 5223(SSL) ports:
{5222, ejabberd_c2s, [{access, c2s_host1}, {max_stanza_size, 65536}, {shaper, c2s_shaper}]},
{5223, ejabberd_c2s, [
{certfile, "/opt/ejabberd-2.0.3/conf/server.pem"}, tls,
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536}
]},
I have created acl, that describes host1.lan:
{acl, host1, {server, "host1.lan"}}.
And access rule:
{access, c2s_host1, [{deny, blocked},
{allow, host1}]}.
Now, when I'm trying to connect to 5222 port (without SSL) with
Maybe I'm trying to use wrong method for my task but, I think connection should be aborted immedeatly after this stage:
=INFO REPORT==== 16-Feb-2009::16:42:42 === I(<0.280.0>:ejabberd_listener:116) : (#Port<0.417>) Accepted connection {{192,168,yy,yy},4277} -> {{192,168,xx,xx},5222} =INFO REPORT==== 16-Feb-2009::16:42:42 === D(<0.428.0>:ejabberd_receiver:306) : Received XML on stream = "<?xml version='1.0' encoding='UTF-8'?> <stream:stream to='host2.lan' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' version='1.0'>"
because server configured to accept connection on 5222 ports ONLY for host1.lan, but connection were made with host2.lan.
Is it correct?
Try those access options
And access rule:
{access, c2s_host1, [{deny, blocked}, {allow, host1}]}.
The rules in that Access option don't cover all the possible cases. For example, what to do with a JID that is not 'blocked', not 'host1'? It is better to add an 'all' rule at the end of each Access option, to ensure you cover all the possible cases.
I think this example will do what you want
{hosts, ["host1.lan", "host2.lan"]}.
{listen,
[
{5222, ejabberd_c2s, [
{certfile, "/etc/ejabberd/ssl.pem"}, starttls,
{access, c2s_5222},
{shaper, c2s_shaper},
{max_stanza_size, 65536}
]},
{5223, ejabberd_c2s, [
{certfile, "/etc/ejabberd/ssl.pem"}, tls,
{access, c2s_5223},
{shaper, c2s_shaper},
{max_stanza_size, 65536}
]},
...
]}.
{acl, host1, {server, "host1.lan"}}.
{acl, host2, {server, "host2.lan"}}.
%% Only users of host1 can connect to 5222:
{access, c2s_5222, [{allow, host1}, {deny, all}]}.
%% Port 5223 can be used by users of host1 and host2:
{access, c2s_5223, [{allow, host1}, {allow, host2}, {deny, all}]}.
Thank you very much! This is
Thank you very much!
This is absolutely right solution - no extra LDAP queries for not allowed hosts.
Builtin Admin Question
Hi,
I enabled LDAP in my new installation and I can connect using accounts from Active Directory but can't login to the admin portal any more using admin@servername.
Is there a setting that needs to be added to the configuration to re-enable the built-in account?
Thank you.
admin account = Jabber account + admin privilege
Hi,
I enabled LDAP in my new installation and I can connect using accounts from Active Directory but can't login to the admin portal any more using admin@servername.
Is there a setting that needs to be added to the configuration to re-enable the built-in account?
Thank you.
You didn't get a concept right: an admin account in ejabberd is just a normal Jabber account that you grand administrative privilege in ejabberd.cfg.
If your old account with admin rights wasadmin@example.org , and you changed auth_method from internal to ldap, now the admin privilege is still granted to the account admin@example.org , even if it does not exist yet.
So, create the correct account in LDAP and use its credentials to login in Web Admin.
Local Admin after enabling LDAP - ejabberd
FIXED,
1. Install ejabberd
2. Enable ldap as per documentation
3. Create an account in active directory that matches the account you specified when installing ejabberd
4. Make sure the account is in your ldpa_base OU, otherwise you will be struggling for hours like me.
I hope this helps some one.
Marco.
Hi,
I enabled LDAP in my new installation and I can connect using accounts from Active Directory but can't login to the admin portal any more using admin@servername.
Is there a setting that needs to be added to the configuration to re-enable the built-in account?
Thank you.
You didn't get a concept right: an admin account in ejabberd is just a normal Jabber account that you grand administrative privilege in ejabberd.cfg.
If your old account with admin rights wasadmin@example.org , and you changed auth_method from internal to ldap, now the admin privilege is still granted to the account admin@example.org , even if it does not exist yet.
So, create the correct account in LDAP and use its credentials to login in Web Admin.
badlop,
Thank you very much for taking the time to reply,
I understand what you said, but even after creating the admin account in Active Directory I am not able to login to the GUI.
So, decided to create a new account in AD called ejabberd with domain admin rights just in case. Reinstalled ejabberd and use account ejabberd during installation, to make sure everything worked I loged in before making changes to the system. Everything worked great so. I enabled LDAP by following the documentation. I don't get any errors in the logs but I can't authenticate to the admin page using ejabberd anymore.
Here is how my ldap is configured:
%%{auth_method, internal}.
{auth_method, ldap}.
{ldap_servers, ["domain.controler.name"]}.
{ldap_uids, [{"sAMAccountName"}]}.
{ldap_base, "ou=users,dc=domain,dc=local"}.
{ldap_rootdn, "cn=Administrator,cn=users,dc=domain,dc=local"}.
{ldap_password, "********"}.
I am thinking I need to add something to the acl area to allow the local admin access to web admin page, but I am not sure.
Any help would be appreciated.
Thank you.