ejabberd - Comments for "Ejabberd tries authenticate user from host, which is not allowed to connect on certain port."

Local Admin after enabling LDAP - ejabberd

mrojas73 — Sun, 22 Feb 2009 15:37:35 +0000

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.

badlop wrote:

mrojas73 wrote:

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 was admin@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.

admin account = Jabber account + admin privilege

mfoss — Thu, 19 Feb 2009 23:12:17 +0000

mrojas73 wrote:

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.

So, create the correct account in LDAP and use its credentials to login in Web Admin.

Builtin Admin Question

mrojas73 — Thu, 19 Feb 2009 22:14:37 +0000

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.

Thank you very much! This is

ask0n — Thu, 19 Feb 2009 18:24:15 +0000

Thank you very much!
This is absolutely right solution - no extra LDAP queries for not allowed hosts.

Try those access options

mfoss — Wed, 18 Feb 2009 18:58:40 +0000

ask0n wrote:

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}]}.